Proposition of OSCore Store #1175
Conversation
Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
This commit adds early support for using OSCORE to communicate between a Leshan client and server. The server can register and perform its request towards the server using OSCORE. Likewise the server can perform requests to the client using OSCORE. The web interface of the server has been extended to allow adding clients that use OSCORE for security including their OSCORE security context information. On the client side further work is needed to allow setting OSCORE security context information on it. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
…eation Code to implement the points listed here: eclipse-leshan#718 (comment) The OSCORE object is generated and filled in the Leshan client demo. It will then be used to create a ServerInfo object using the ServersInfoExtractor. Next the ServerInfo is used in the CaliforniumEndpointsManager to generate endpoints towards servers that OSCORE should be used with. See also issue regarding OSCORE client integration: eclipse-leshan#726 Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
An identity string based on OSCORE parameters is now set for connected clients that use OSCORE. The identity string contains the OSCORE Sender and Recipient ID the client and server are using. These parameters can be retrieved from the source EndpointContext. The identity for OSCORE is also set as a SecurityInfo based on the OSCORE context configured on the server to use with a specific client. The identity of a connected client and the configured SecurityInfo are then matched in the SecurityChecker. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
This commit adds support for the client communicating to the bootstrap server using OSCORE. The bootstrap server web UI has been extended to accept settings for OSCORE. Some modifications were also done on the client to support it bootstrapping using OSCORE. It supports OSCORE settings as command line parameters since before. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
The possibility to input an ID Context for OSCORE on the client-demo, bsserver-demo and server demo has now been removed. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
This commit enables the client to receive OSCORE security context information from the bootstrap server during the bootstrapping process. The bootstrap server web UI was updated to accept settings for OSCORE under the LWM2M Server tab. Some changes were done in the client side code to support this functionality. Finally, an OSCORE server identity is now generated and set. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
This commit adds support for running the Appendix B.2 procedure from the OSCORE RFC, which securely re-generates OSCORE Security Context information. The LWM2M client can now run this procedure towards the LWM2M server or LWM2M bootstrap server. See https://tools.ietf.org/html/rfc8613#appendix-B.2 It is specified in the LWM2M 1.1 Transport Bindings document section 5.5.3 that Appendix B.2 of OSCORE should be used. Using the procedure in Appendix B.2 will derive 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 every time the client connects the first time using OSCORE to a LWM2M Server or LWM2M Bootstrap server, Appendix B.2 will be run. Furthermore, 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. Signed-off-by: Rikard Höglund <rikard.hoglund@ri.se>
|
Note that I changed FileSecurityStore from instead extending of InMemorySecurityStore to composite with EditableSecurityStore. It allows me to inject OSCoreSecurityStore as a middleware. I also have a question: do we need separate OSCore Security Store? Or maybe it should be integral part of InMemorySecurityStore/FileSecurityStore/RedisSecurityStore because it will be always OSCore support (it's not just an option). Another question: what name we should use for classes? OSCoreXXX or OscoreXXX? Because in project we have mix of these names we should take one strategy name. Similar problem is with other classes like LwM2mXXX/Lwm2mXXX |
Michal-Wadowski
force-pushed
the
opl/oscore_store1
branch
from
3a040af to
a892ea3
Compare
|
(I begin by the easy question)
I don't like so much the
I have no strong opinion. The "real" way to write oscore should be OSCORE (https://datatracker.ietf.org/doc/html/rfc8613) |
There are LwM2MResourceTest and Lwm2mEndpointContextMatcher which doesn't fit into pattern. But most of classes are LwM2mXXX indeed. I just noticed Lwm2mEndpointContextMatcher class by accident but I didn't noticed that is rare case. |
|
@Michal-Wadowski, I think we can close this one ? About the LwM2mXXX/Lwm2mXXX wording, please do not hesitate to create a dedicated issue where you list the problematic name. |
|
I close it as Oscore Store is now implemented with #1212. Some of your ideas was reused (like OscoreIdentity) @Michal-Wadowski thx for that 🙏 |
Example implementation of OSCore Store to debate on