You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A LwM2M Client and LwM2M Server MUST be able to verify the freshness of certain LwM2M operations.
LwM2M operations may have freshness requirements that are not possible to guarantee by protecting individual messages such as with DTLS Record Layer or OSCORE. This is accentuated with unreliable transport. Since datagram transport does not provide reliable or in-order delivery of data, DTLS and OSCORE preserves this property. Although duplicate messages are rejected through the use of anti-replay mechanisms, unordered delivery is still allowed, e.g. using a sliding receive window. As a consequence maliciously delayed message are accepted as long as they fall within the window.
For example, a Write operation, maliciously blocked from reaching the LwM2M Client at one time, may under these circumstances be successfully injected at a later time, potentially overwriting a more recent Write operation.
Operations protected by a security protocol with keys derived from a TLS/DTLS handshake are at least as fresh as the handshake. However, frequent use of the handshake protocols may be prohibitive in constrained environments. In order to avoid unnecessary processing, a more lightweight solution to verify freshness is provided by the CoAP Echo Option, illustrated with the example above: The LwM2M Client, receiving a Write operation of uncertain freshness may respond with an error message containing an Echo option including a random nonce as value. The LwM2M Server receiving the error response to a valid Write operation retransmits the request with the Echo option and value included. The LwM2M Client receiving a request with an Echo option verifies that the nonce corresponds to a recent request, and only in that case performs the operation (for details, see Section 2 of [CoAP_ERT]).
Applications need to understand the freshness requirements of the operations both in LwM2M Client and LwM2M server. The LwM2M implementation SHOULD enable timely freshness verifications to be performed without unnecessary overhead. For interoperability both LwM2M Client and LwM2M Server SHOULD implement the CoAP Echo option.
The attack does not apply when a connection-oriented transport, like CoAP over TCP is used, or when a replay window size of 1 is selected with DTLS.
New OSCORE input parameters MAY be provisioned for use between endpoints having an existing OSCORE security context requiring the endpoints to derive new contexts. The Echo option MUST be used by the receiving endpoint when the OSCORE security context is used for the first time (e.g. Bootstrap-Request or Register) and SHOULD be used when the requested operation (e.g. Device Management Write) requires freshness that cannot be guaranteed by other means
If OSCORE is used to secure the Registration then the Echo Option MUST at least be used with the first operation.
What must we do in Leshan ?
This issue aims to discuss to know what should be done in Leshan regarding that part of the specification.
At first sight, It seems that one part is mainly a CoAP library feature which works transparently. I mean if one peer answers with Echo option, the other peer should repeat the request.
But this leads to the question who decide to ask for echoing a request. Should it be done transparently so application developer doesn't need to think too much about it ? If this is done transparently could it be done by LWM2M or CoAP stack ?
At least for OSCORE, there is more LWM2M specific work to do. 🤔
(But maybe for OSCORE we should use a dedicated issue)
Concerning java-coap :
❌ Last java-coap version (v6.16.1) doesn't seem to support it. (at least I find nothing about it)
✔️ Maintainers are interested to implement it. (open-coap/java-coap#65)
Compatibility with foreign peer which doesn't support it
(Note that a LWM2M server act as CoAP server and CoAP client and it's the same for a LWM2M client)
When a LWM2M peer acts as a CoAP server and want to use echooption , if the foreign peer doesn't support it, there is no way to communicate. So maybe a LWM2M server should be able to enable/disable echo option by client ? (idea was proposed at open-coap/java-coap#65 (comment))
The text was updated successfully, but these errors were encountered:
Specifications :
I recently see that the LWM2M specification (since v1.1.x) says :
At LWM2M-v1.1.1@transport§6.1. Features :
At LWM2M-v1.1.1@transport§5.7. Freshness :
The CoAP Echo Option is defined in RFC9175§ 2. Request Freshness and the Echo Option
Attack preventing by CoAP Echo Option are describe in :
Specific to OSCORE
At LWM2M-v1.1.1@transport§5.5.3. Bootstrapping
At LWM2M-v1.1.1@transport§6.4.2. Bootstrap Interface
At LWM2M-v1.1.1@transport§6.4.3. Registration Interface
What must we do in Leshan ?
This issue aims to discuss to know what should be done in Leshan regarding that part of the specification.
At first sight, It seems that one part is mainly a CoAP library feature which works transparently. I mean if one peer answers with Echo option, the other peer should repeat the request.
But this leads to the question who decide to ask for echoing a request. Should it be done transparently so application developer doesn't need to think too much about it ? If this is done transparently could it be done by LWM2M or CoAP stack ?
At least for OSCORE, there is more LWM2M specific work to do. 🤔
(But maybe for OSCORE we should use a dedicated issue)
What should be done at CoAP level ?
Some ideas at : open-coap/java-coap#65
Concerning
Californium
:❌ Last Californium version (v3.9.0) doesn't support it
❌ This is not planned to be added.
Concerning
java-coap
:❌ Last java-coap version (v6.16.1) doesn't seem to support it. (at least I find nothing about it)
✔️ Maintainers are interested to implement it. (open-coap/java-coap#65)
Compatibility with foreign peer which doesn't support it
(Note that a LWM2M server act as CoAP server and CoAP client and it's the same for a LWM2M client)
When a LWM2M peer acts as a CoAP server and want to use
echo
option , if the foreign peer doesn't support it, there is no way to communicate. So maybe a LWM2M server should be able to enable/disableecho
option by client ? (idea was proposed at open-coap/java-coap#65 (comment))The text was updated successfully, but these errors were encountered: