Closed kiranpradeep closed 8 years ago
We discussed this topic at the OMA interim meeting in Paris and we came up with the following conclusion. We believe that the action by the LWM2M server in this case are policy dependent. This means an implementation may require the DTLS security context to be torn down when the long-term credentials are changed. Another implementation may allow the existing security context to be kept alive and to make use of the newly configured credential only once a new connection is established.
Thanks. Will the above be written to the spec or it will continue to be unmentioned ? If yes, shall I keep issue open till it is written ?
Do you think it was confusing to state it? Because if it's not written, it's clear it's up to the implementation to handle PSK lifecycle. I think it could be closed without spec changes.
If someone have the same question in the future they can refer to this discussion.
I added some text to Section 7 to capture this issue. Here is the text I suggest to add:
" Security credential dynamically provisioned to the LWM2M client and the LWM2M server MAY change at any time, even during the lifetime of an ongoing DTLS session. Since the DTLS protocol verifies the credentials only at the beginning of the session establishment (unless the re-negotiation feature is used) it is possible that a change in credential (for example, credentials for the use of a PSK-based ciphersuite) occurs after a DTLS handshake has already been completed and the DTLS session setup is already finalized. Hence, from a DTLS protocol point of view such a change is not recognized and the already established record layer security associations are in use. It is a policy decision for a client as well as a server implementation to tear down an already existing session when the credentials change. Such a decision will depend on various factors, such as the application domain in which LWM2M is used. The LWM2M specification does not mandate a specific behavior in such a case since DTLS allows both communication parties to tear down an established DTLS session for any number of reasons. "
Here is my proposed CR: http://member.openmobilealliance.org/ftp/Public_documents/DM/LightweightM2M/2016/OMA-DM-LightweightM2M-2016-0120-CR_credential_lifecycle_clarification.zip
Does this work for you?
@jvermillard I could be easily wrong in the following. I see it as a limitation to LwM2M spec caused by how DTLS works. For some one who doesn't know DTLS handshakes, could see it like " the logon password has changed and if the user had logged in earlier, he/she can still login with the old password ". In that case, I feel it is better the exception being made to account for DTLS handshakes is in spec.
It appears currently the specification doesn't specify behavior for the below case. Please consider specifying the behavior in the below.