OSCORE support in Leshan

This issue aims to centralize all about OSCORE integration in Leshan 2.0.0(LWM2M 1.1). Currently work is in progress leading by @rikard-sics, he also works on OSCORE integration in Californium.

See specification for more details :

• draft-ietf-core-object-security / oscore
• oscore in LWM2M 1.1
• end-to-end-security-for-the-internet-of-things page

The code will be available in a oscore branch, waiting we have a minimal viable feature which could be integrated in a 2.0.0 branch.

A minimal viable feature could be :

• OSCORE over coap at client side (see #726)
• OSCORE over coap at server side (see #727)

(Demo are not mandatory for a minimal viable feature but integration test should be there)

[rikard-sics]

@rikard-sics We didn’t get news from you since a long time. Hoping all is doing fine for you Are you still working on OSCORE ?

Hello. Yes I am indeed working on OSCORE. Currently I am working on implementing usage of the OSCORE Appendix B.2 procedure when OSCORE is used in Leshan. It is specified in the LWM2M 1.1 Transport Bindings document section 5.5.3 that Appendix B.2 of OSCORE should be used.

Basically Appendix B.2 derives a new OSCORE Security Context (with new Sender and Recipient keys). The benefit this has is that if a LWM2M client reboots and starts using the same Security Context that it was originally configured with, it will not be using the same Sender Key while starting over from sequence number 0 (thus having nonce and key reuse). But rather it will first run Appendix B.2 to generate a new Context (Sender and Recipient keys) with the LWM2M Server or LWM2M Bootstrap server. So essentially every time the client connects the first time using OSCORE to a LWM2M Server or LWM2M Bootstrap server, Appendix B.2 will be run. See https://tools.ietf.org/html/rfc8613#appendix-B.2

However, the core functionality for Appendix B.2 is implemented in Californium. While trying to make use of this in Leshan I realized there was an issue in the Californium code, in the specific case the client takes initiative to run Appendix B.2 but the server is then the first to actually send a request afterwards (as will happen when bootstrapping or registering). So basically I am now working on the Californium code to fix this issue (and some other things about Appendix B.2). My aim is to have a PR created for Californium in the coming week. Then I will move over to implement this in Leshan (perhaps I can have an intermediate solution until Californium releases a new version).

One nice benefit of having this Appendix B.2 functionality-wise is also that currently if the client is restarted but the server is not, the server will complain about replayed messages. But since Appendix B.2 refreshes the security contexts this problem will no longer exist.

[rikard-sics]

@rikard-sics, we don’t get so much news from you since a long time. I really hope you’re doing well. slightly_smiling_face

Yes, sorry for the period of silence. I have been busy mostly with other unrelated things. As for Californium I have prepared code for updating the Appendix B.2 functionality, after doing interop testing with another implementer. I intend to create a PR for that to Californium in the near future.

Currently I am working on wrapping up a paper, when that is done (a matter of weeks) I hope to have more time to get back to the work related to Leshan.