search

OpenMobileAlliance / OMA_LwM2M_for_Developers

OMA LightweightM2M public resources.
http://openmobilealliance.github.io/OMA_LwM2M_for_Developers/
Other
239 stars 52 forks source link

Cleanup LWM2M and DTLS roles #206

Closed boaks closed 7 years ago

boaks commented 7 years ago

OMA-TS-LightweightM2M-V1_0-20170208-A, 7.1.6 specifies the roles for LWM2M and DTLS.

7.1.8

The "Public Key or Identity" Resource MUST be used to store the raw public key of the DTLS client.

I think, this should be LWM2M client, not DTLS? If so, the "DTLS" role should be replaced (cleaned up) in some more places in 7.1.8 and 7.1.9. into "LWM2M" role.

hannestschofenig commented 7 years ago

The reason why we talk about DTLS client and server roles (instead of LwM2M client and server roles) is due to the desire to support the client-initiated as well as the server-initiated bootstrapping mode.

Here is the relevant text:

" The client-server roles of DTLS, which indicate who initiates the DTLS handshake, are independent from the client-server relationship of LwM2M. In client-initiated bootstrapping the LwM2M Client is also the DTLS client and the LwM2M Bootstrap Server acts as the DTLS server. For server-initiated bootstrapping, however, the roles are reversed: the LwM2M Client acts in the role of a DTLS server and the LwM2M Bootstrap Server is the DTLS client. "

boaks commented 7 years ago

First at all, I appreciate section 7.1.6. But I think, the roles classifier in 7.1.8 and 7.1.9 are wrong and should use LWM2M instead of DTLS.

This mode requires the following resources of the Security Object defined in Appendix E.1 to be populated: • The “Security Mode” Resource MUST contain the value 1. • The "Public Key or Identity" Resource MUST be used to store the raw public key of the DTLS client. • The "Secret Key" Resource MUST be used to store the private key of the DTLS client. • The “Server Public Key” Resource MUST be used to store the raw public key of the DTLS server.

So far, the security object contains the credentials a LWM2M client / device uses for DTLS. So, if the LWM2M client / device acts as DTLS server, it would require a private key for the DTLS server, right? But according the text, the security object contains the private key for the DTLS client. So I'm not sure, where a LWM2M client, acting as DTLS server, should get the "DTLS server private key". If the roles would have been qualified with LWM2M, the LWM2M client would just take the private key of the LWM2M client as "private key" even when acting as DTLS server.

hannestschofenig commented 7 years ago

This issue will get discussed again in LwM2M v1.1 since the feature of running the DTLS server on the IoT device itself has not been utilized by most OMA members. If there are companies and individuals who had implemented this feature it would be good to hear their perspective.

boaks commented 7 years ago

So thumbs up for remove the DTLS role exchange!

Hopefully, the OMA device management working group also changes the "server initiate bootstrap", so that this could be used complying the standard DTLS roles.

Please go for the solution in #179, "server initiate bootstrap" should be just a trigger for the "client initiate bootstrap"

hannestschofenig commented 7 years ago

The plan is to get rid of the server-initiated bootstrap in LwM2M v1.1 and to instead replace it with a trigger for the client initiated bootstrap instead.

To see the work in progress work on this issue you have to be an OMA member otherwise you have to wait till the release of v1.1 in Feb.2018.