OSCORE store for holding security material

[rikard-sics]

As discussed during the process of adding OSCORE support to Leshan it would be good to have a "OSCORE store", similar to the DTLS store, for holding OSCORE security information.

To start the discussion, here's a quote proposed from @sbernard31 from an earlier PR related to OSCORE. #857

Maybe some hints for this discussion. I think maybe we could inspired our-self of DTLS+PSK.

I will come back with further comments on considerations in a follow up post.

[rikard-sics]

As we discussed the OscoreStore can be modeled on the PSKStore, but is there some class in Leshan itself which has similar properties (persistent, shared between cluster environments) which I could use as inspiration to see how these properties can be achieved?

The way I could imagine for the OscoreStore to function is as kind of a layer between the OSCORE Object and the creation of the OSCORE Context. So it would be something like:

OSCORE Object or Local configuration -> OscoreStore -> Oscore Context.

Meaning the information from the OSCORE Object received on the Client (or the local configuration input in the GUI/CLI on the Client/Server/Bootstrap server) will be input into the OscoreStore , then the information from the OscoreStore is used when building the actual OSCORE Context.

[sbernard31]

As we discussed the OscoreStore can be modeled on the PSKStore, but is there some class in Leshan itself which has similar properties (persistent, shared between cluster environments) which I could use as inspiration to see how these properties can be achieved?

You can have a look at SecurityStore, LwM2mPskStore, InMemorySecurityStore, RedisSecurityStore.

I'm back on Tuesday and can give you more information if needed when I'll be back.

[rikard-sics]

You can have a look at SecurityStore, LwM2mPskStore, InMemorySecurityStore, RedisSecurityStore.

I'm back on Tuesday and can give you more information if needed when I'll be back.

Thank you for the feedback. I will start having a look at those classes.

[Michal-Wadowski]

I created draft #1175 to show my proposition

[sbernard31]

About the proposition, I feel this is not exactly the idea.

I will try to better explain what I have in mind.

First we should keep in mind that Leshan should be as much as possible independent to californium and californium is just a possible implementation.

As explained at #920 (comment), I guess there is 2 kind of OSCORE data, the one which should be persisted (and will be provided by a user) and the context/temporary one which can be recreated with some exchange between client and server.

I feel its pretty much similar as PSK with DTLS.
A user set the identity and the key. this information will/can be persisted.
Then an handshake is done using this persisted/configured data to create some context/temporary DTLS connection.

Even If I'm not so sure I guess for OSCORE this could be the same idea.
So at californium side we need an interface (OscoreStore) which is responsible to get (persisted/set by user) data and so californium will use it to create the temporary OSCORE context. (maybe not the good name but you see the idea)
And so user can provide their own implementtation of this OscoreStore.
(So we need to modify californium API first)

At Leshan side, the SecurityStore is where you can find information about how a client should connect to the server. (this is LWM2M concept) So here you says for example that a device should connect using oscore with given senderId and recipientId (and maybe more. we need to clarify what we put here)

Then we create an OscoreStore which internally hold the Leshan SecurityStore and search in it to find OSCORE persisted data. (like https://github.com/eclipse/leshan/blob/leshan-2.0.0-M5/leshan-server-cf/src/main/java/org/eclipse/leshan/server/californium/LwM2mPskStore.java)

The question is : Does this idea makes sense at OSCORE point of view ? (@rikard-sics)

[sbernard31]

About

modifying californium API first

I rethink about this and maybe this is possible to experiment a kind of OscoreStore in directly in Leshan playing with a OSCoreCtxDB interface.
Then once we have a clear idea, we push it in californium ? (this will avoid us to deal with different californium version)

[rikard-sics]

I rethink about this and maybe this is possible to experiment a kind of OscoreStore in directly in Leshan playing with a OSCoreCtxDB interface. Then once we have a clear idea, we push it in californium ? (this will avoid us to deal with different californium version)

Yes, I think that plan makes sense. Then we can see what can of solution fits best for Leshan, and based on that merged our solution into Californium after it is confirmed to work well and fit with Leshan.

[sbernard31]

@rikard-sics do you start to work on this ?
When looking at implementing the Oscore support at server demo side, I quickly face some issues where I finally need some code modification around this. 😬
This is just to ensure we didn't work on the same thing at same time ?

[rikard-sics]

@rikard-sics do you start to work on this ?
When looking at implementing the Oscore support at server demo side, I quickly face some issues where I finally need some code modification around this. grimacing
This is just to ensure we didn't work on the same thing at same time ?

Yes, I will get started on this. Let us synchronize on what code modifications you need and I can try to adapt things accordingly.

[sbernard31]

I created #1208.
I hope this should be enough to code the server demo part on it.
@rikard-sics, you should have a look and if it's OK for you. I can integrate it in oscore branch and you should base your OSCORE store work on it too. :)

[sbernard31]

@rikard-sics, I created #1212 to clarify ideas I tried to explain here. Let me know if this is clearer now ? and if you think this is the right direction ? 🙏

[rikard-sics]

@rikard-sics, I created #1212 to clarify ideas I tried to explain here. Let me know if this is clearer now ? and if you think this is the right direction ? pray

Thanks sounds great. I will check #1212 and write a comment there.

[sbernard31]

(you should probably check #1208 first)

[rikard-sics]

(you should probably check #1208 first)

Noted, then I will check that PR first. Let me get back to you tomorrow.

[sbernard31]

@rikard-sics with #1208 and #1212.
I think we have a first satifying version of a kind of OSCORE store.

Please tell me if you want to review those 2 PRs more deeper.

Next step I have in mind :

• rebase oscore branch on master.
• integrate those 2 PRs ☝️ in oscore branch.
• do a full check of // TODO OSCORE in the code and fix what we need in a minimal viable feature.
• do a clear list of possible modification of californium API.
• then maybe work on demo.

I think the most important missing point is the OSCORE context lifetime question. (#1212 (comment))
But maybe we should create a dedicated issue for this ?

[rikard-sics]

@rikard-sics with #1208 and #1212. I think we have a first satifying version of a kind of OSCORE store.

Please tell me if you want to review those 2 PRs more deeper.

Next step I have in mind :

* rebase `oscore` branch on `master`.

* integrate those 2 PRs point_up  in `oscore` branch.

* do a full check of `// TODO OSCORE` in the code and fix what we need in a minimal viable feature.

* do a clear list of possible modification of californium API.

* then maybe work on demo.

Sounds very good! I have tried to keep up with those PRs and the discussion, so I don't see a need for me to do any deeper review before you proceed with the steps in your plan.

Let us discuss more about the list of changes needed in Californium when that step is reached. I have tried to keep track of the things that came up during our discussions.

I think the most important missing point is the OSCORE context lifetime question. (#1212 (comment))
But maybe we should create a dedicated issue for this ?

I wrote a reply regarding the lifetime point in that thread. If you wish to break it out into a separate issue we could continue the discussion in there.

[sbernard31]

(I need to work on a 1.4.0 release, then I start to apply this plan)

[sbernard31]

Next step I have in mind :

• rebase oscore branch on master.
• integrate those 2 PRs ☝️ in oscore branch.
• do a full check of // TODO OSCORE in the code and fix what we need in a minimal viable feature.
• do a clear list of possible modification of californium API.
• then maybe work on demo.

Unless I missed something all of this are done now.

@rikard-sics, I don't know what could be next steps ? 🤔

I think we could consider to integrate all those changes on oscore branch ?
But before you should probably review/appoved/test/play with the opened PR about OSCORE.

Then we should decide what is missing before we put in master ?
Then we should decide what is missing before for minimal viable feature ?
Then we should test and finalize the minimal-viable feature.

I'm not sure what I can do more for now, if you have some idea let me know ?

[sbernard31]

I think this is implemented and integrated in master (#1277)

Mssing work should be listed in #1231.

So I close this issue. (@rikard-sics feel free to reopen if needed)