secret key updation in server ( identity unchanged ) has no effect on update registration

[kiranpradeep]

I tried below.

1. Start device management(DM) server
2. Start Leshan client which connects using PSK
3. In DM Server UI( at http://leshan.eclipse.org/#/security ), edit secret key alone for the client endpoint. I leave the identity changed.
4. Client's update registration continues to succeed

Shouldn't the update registration have failed once secret was changed ?

[boaks]

As far as I understand, the secret key is only used during the DTLS handshake. So, with an already established DTLS session, there will be no new handshake on "update registration" and therefore the new secret key is not accessed.

[kiranpradeep]

Does that mean - "it is not a bug" ? I felt end user will expect the update registration to fail.

[boaks]

I would just say, the LWM2M TS doesn't explizitly define the behaviour. Therefore it's rather unclear, if this should be considered as bug or not.
My answer should just give some information about the dependencies and why it behaves currently like that.

[sbernard31]

@boaks is right. Currently Leshan server does not close DTLS session when credentials is changed. So, as long as the DTLS session is alive the device will be able to communicate with the server.

The LWM2M TS is not clear about that. So we should probably ask this at OMA.

About the DTLS session lifetime, the TLS RFC say that :
"An upper limit of 24 hours is suggested for session ID lifetimes"

With the currently DTLS implementation (Scandium) used in Leshan, session can live forever (If device talk at least every 36 hours). I suppose Session lifetime expiration should be handled/configurable at Scandium level.

[kiranpradeep]

Have added a query at OMA(1). Note: currently in Leshan server, if both PSK identity and key is changed, the update registration fails as expected.

[boaks]

Note: currently in Leshan server, if both PSK identity and key is changed, the update registration fails as expected.

:-). For each registration / registration update message, the "exchanged" security info is checked. DTLS/PSK exchanges only the PSK identity (and for sure not the PSK secret key). So changing the identity results in failing of the check, but changing the PSK (currently) only affects the handshake.

[sophokles73]

@kiranpradeep

With the currently DTLS implementation (Scandium) used in Leshan, session can live forever (If device talk at least every 36 hours). I suppose Session lifetime expiration should be handled/configurable at Scandium level.

maybe you want to create an issue for this in Californium?

[kiranpradeep]

@sophokles73 I once did that( link ). Should it be reopened ? Or should the query be presented differently.

[sbernard31]

Sry, this was a bit confusing but scandium#24 is about time of inactivity.
What I talked in this is issue is more about a maximum session lifetime.

[kiranpradeep]

OMA replied(1) - it is up to the implementation to decide. If Leshan chose to not expire session on secret key change, shouldn't Leshan have consistent behavior across changes to identity and secret key ?. Currently identity change breaks the session and secret key change keeps the session as before.

[sbernard31]

@kiranpradeep, #818 should provide a new behavior closer to your expectation.

[sbernard31]

I close this one as #818 should cover the need.