Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Since LWM2M v1.1.x, Client Endpoint Name is optional for Register and Bootstrap request #1457

Closed
sbernard31 opened this issue Jun 13, 2023 · 3 comments
Labels
core Impact core of Leshan new feature New feature from LWM2M specification

Comments

@sbernard31 sbernard31 added new feature New feature from LWM2M specification core Impact core of Leshan labels Jun 13, 2023
@sbernard31
Copy link
Contributor Author

@sbernard31
Copy link
Contributor Author

All I found about this in the specification :

LWM2M-v1.1.1@core§6.1.7.1. Bootstrap-Request Operation says :

This parameter is optional if it is equal to the identifier in the security protocol and deployment is such that the security protocol identifier is always available for the server

LWM2M-v1.1.1@core§7.3. Identifiers says :

Identifies the LwM2M Client on one LwM2M Server (including LwM2M Bootstrap-Server).
This parameter is optional and provided to the LwM2M Server during Registration, also provided to LwM2M Bootstrap-Server when executing the Bootstrap procedure. It MUST be provided when the security protocol does not provide an authenticated identifier or this information is not available for the server.
The Endpoint Client Name is a string. Recommended URI and URN formats are documented in Section Endpoint Client Name.

LWM2M-v1.1.1@transport§5.2.6. Endpoint Client Name says :

This specification recommends, but does not mandate, transmission of the endpoint client name in the Bootstrap-Request and in the Register message. Since the endpoint client name is not authenticated at the application layer the LwM2M Server MUST compare the received endpoint client name identifier with the identifier used at the TLS/DTLS handshake. This comparison may either be an equality match or may involve a dedicated lookup table to ensure that LwM2M Clients cannot intentionally or due to misconfiguration impersonate other LwM2M Clients. The LwM2M Server MUST respond with a "4.00 Bad Request" to the LwM2M Client if these fields do not match.

LWM2M-v1.1.1@transport§5.5.5. Endpoint Client Name says :

The same verification of Endpoint Client Name in the Bootstrap-Request and in the Register messages as described in 5.2.6. Endpoint Client Name applies also to OSCORE. However, when using OSCORE, the Endpoint Client Name MAY be authenticated at the application layer, by setting the "OSCORE Sender ID" Resource value (see 5.5.7.1. OSCORE Related Resources) to the Endpoint Client Name.

If the OSCORE Sender ID is not set to Endpoint Client Name, then the LwM2M Server MUST compare the received Endpoint Client Name identifier with the OSCORE Sender ID of the LwM2M Client. This comparison may either be an equality match or may involve a dedicated lookup table to ensure that LwM2M Clients cannot intentionally or due to misconfiguration impersonate other LwM2M Clients. The LwM2M Server MUST respond with a "4.00 Bad Request" to the LwM2M Client if these fields do not match.

My understanding is :

When endpoint Name is absent from Register or Bootstrap request, the transport identifier can be used as endpoint name.
I tries to guess what does it means for each transport :

  • no_sec : can not be used, as there is no transport identifier.
  • ✔️ psk over (D)TLS : psk identity can be considered as endpoint name.
  • rpk over (D)TLS : no idea what could be used as endpoint name, so I guess this can not work.
  • ✔️ x509 over (D)TLS : CN from certificate can be considered as endpoint name.
  • ✔️ oscore : sender ID can be considered as endpoint name. (I guess this is also true when it used over (D)TLS)

What I could imagine user asked :

Automatically find endpoint name from SecurityStore with something like SecurityStore.getByIdentity() ? so maybe better to have a way customize default behavior (as usual 😅)

How we can implement it in Leshan ?:

A solution could be to have a EndpointNameProvider interface with a DefaultEndpointNameProvider implementation with behavior described above ☝️.

public interface EndpointNameProvider {
   String getEndpointName(LwM2mIdentity identity);
}

@sbernard31
Copy link
Contributor Author

This is now implemented (see #1652) and integrated in master. (Should be available in 2.0.0-M17

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Impact core of Leshan new feature New feature from LWM2M specification
Projects
None yet
Development

No branches or pull requests

1 participant