OSCORE Context lifetime.

[sbernard31]

This issue aims to discuss about Oscore Context lifetime.

In a general way but also mainly what should be targeted for a minimal viable feature.

Here is some information about that : https://github.com/eclipse/leshan/pull/1212#issuecomment-1074932429.

At Leshan side, there is 2 ideas :

1. Remove the context when an OSCORE security info is removed from SecurityStore. That means we should be able to remove context by Recipient ID).
2. Remove context on device Deregistration. (here we probably also need to be able to remove context by Recipient ID)

About 2), This will be a pretty much different behavior than with DTLS because currently DTLS connection lifetime is not related to LWM2M registration lifetime. So don't know if we should do the same for OSCORE (I mean not linked registraiton lifetime to OSCORE context lifetime ?)

Maybe more at californium side but : Even with this cleaning mechanism, I have some concern about not limiting the size of the OscoreCtxtDB or the lifetime of Context itself. @rikard-sics do you think this is justified concerns ? do you think this should be part of the minimal viable feature ? or it's OK to live without it for now ?

[rikard-sics]

Let me add my post from the other issue here too so the discussion is collected:

Yeah, currently there is no specific lifetime of an OSCORE context. The only limit applied is that when the sender sequence number reaches its max value, then the context must not be used further. https://datatracker.ietf.org/doc/html/rfc8613#section-7.2.1

In the OSCORE ACE profile, if the Token associated to the context expires the context should no longer be used: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-19#section-6

We are also working on a new draft Key Update for OSCORE (KUDOS) that is mainly about an alternative to the OSCORE appendix B.2 procedure, but it also introduces an explicit expiration parameter for OSCORE contexts: https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-key-update-01#section-2.2.1

When it is desirable, contexts can be removed from the DB using removeContext(OSCoreCtx ctx)*. This could be done due to memory restrictions, or if a client has deregistered or been removed by the user in the server UI. If the client wishes to register then a new context will be derived for it (plus running of Appendix B.2).

[rikard-sics]

At Leshan side, there is 2 ideas: 1. Remove the context when an OSCORE security info is removed from SecurityStore. That means we should be able to remove context by Recipient ID). 2. Remove context on device Deregistration. (here we probably also need to be able to remove context by Recipient ID)

One idea could then be to add a method for deleting a context based on its RID (and ID Context). Or rely on the current way which would be to first retrieve the context and the delete it using removeContext(OSCoreCtx ctx).

[rikard-sics]

About 2), This will be a pretty much different behavior than with DTLS because currently DTLS connection lifetime is not related to LWM2M registration lifetime. So don't know if we should do the same for OSCORE (I mean not linked registraiton lifetime to OSCORE context lifetime ?)

I think the OSCORE context can't really be deleted before the registration lifetime is over, since in such case there would be no context to continue the communication with. To trigger Appendix B.2. for deriving a new context, an existing shared context between the peers is needed. So one way is to make it so that when the context lifetime expires the devices run the Appendix B.2. procedure and then transition to using the new context (one downside is that observations are lost). (I suppose then it would be like the old context is deleted, and a new one takes over).

[sbernard31]

I think the OSCORE context can't really be deleted before the registration lifetime is over, since in such case there would be no context to continue the communication with.

But remove the context from the map, does not mean we can not create a new context on demand from OscoreParameter storing in OscoreStore.

one downside is that observations are lost.

I didn't know that ? Is it an OSCORE RFC limitation, a LWM2M limitation or just a current implementation limitation ?

[rikard-sics]

Maybe more at californium side but : Even with this cleaning mechanism, I have some concern about not limiting the size of the OscoreCtxtDB or the lifetime of Context itself. @rikard-sics do you think this is justified concerns ? do you think this should be part of the minimal viable feature ? or it's OK to live without it for now ?

If there would be a lifetime, what do you think it should consist of? Number of messages sent, or simply time? As I mentioned above, one way is to regularly run the Appendix B.2. procedure and thus derive a new context to continue the communication with. Although, for a minimal viable feature (considering it experimental) I think it is okay to live with contexts with no life time.

As for the maximum size of the OscoreCtxDB that should be fairly simply to do by adding a new constructor that can that an integer defining the upper limit of concurrent contexts. So that may be more simple to add already.

[rikard-sics]

But remove the context from the map, does not me when can not create a new context on demand from OscoreParameter storing in OscoreStore.

Yes, that would be possible. But would that not use the exact same security material, thus resulting in the same sender and recipient keys (meaning nonce and key reuse)? (Unless Appendix B.2. is used with this new context.)

[sbernard31]

@rikard-sics I started to implement some of this at #1232

[rikard-sics]

I didn't know that ? Is it an OSCORE RFC limitation, a LWM2M limitation or just a current implementation limitation ?

It is not very explicitly stated in the OSCORE RFC except for a note in the related Appendix B.1 procedure: https://datatracker.ietf.org/doc/html/rfc8613#appendix-B.1.3

During the work on the KUDOS draft for the proposed new OSCORE context rederivation method we spent a lot of time thinking about this. Fundamentally the problem is that if you keep observations after the current Appendix B.2 has executed you may end up in a situation where an OSCORE protected response message cryptographically matches 2 different requests. It would go something like this:

1. The client starts an observation Obs1 by sending a request Req1 with Partial IV = X
2. The two peers run Appendix B.2, and resets their Sender Sequence Number (SSN) to 0.
3. Later on, while Obs1 is still ongoing, the client sends a new request Req2 also with Partial IV = X. This is not necessarily an observation request.
4. A notification sent by the server for Obs1 or a response to Req2 would both cryptographically match against both Req1 and Req2.