Add redis support to OSCORE #1186
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Rikard Höglund <[email protected]>
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 <[email protected]>
…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 <[email protected]>
Signed-off-by: Rikard Höglund <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
|
I didn't look at the code but not sure having this kind of git tree is a good idea ?
Is there any reason about this ? |
|
I'm not sure working on RedisSecurityStore is a good idea while we don't define a clear API :
|
Do you mean about merging opl/oscore_work ? I borrowed some code from opl/oscore_work (which wasn't be intended to be pushed as PR) and looks what it looks like. If it would be finally squashed it shouldn't be a problem I think.
You're right. But in current PR I mostly fixed the redis tests which are broken in PR #1180. |
|
Regarding plan at #725 (comment)
Yep but maybe #1180 (comment), Is enough in a first time ? What do you think ? |
I fixed the tests because I didn't think we can add |
sbernard31
force-pushed
the
oscore
branch
2 times, most recently
from
bff9d3e
to
278c160
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I added redis serializer/deserializer to allow use OSCORE.