UDP Channel Security

The UDP channel security for [COAP] is defined by the Datagram Transport Layer Security (DTLS) [RFC6347], which is the equivalent of TLS v1.2 [RFC5246] for HTTP and utilizes a subset of the Cipher Suites defined in TLS. (Refers to TLS Cipher Suite registry http://www.iana.org/assignments/tls-parameters/tls-parameters.xml)

The DTLS binding for CoAP is defined in Section 9 of [CoAP]. DTLS is a long-lived session based security solution for UDP. It provides a secure handshake with session key generation, mutual authentication, data integrity and confidentiality.

Since the LWM2M protocol utilizes DTLS for authentication, data integrity and confidentiality purposes, the LWM2M Client and LWM2M Server SHOULD keep a DTLS session in use for as long a period as can be safely achieved without risking compromise to the session keys and counters. If a session persists across sleep cycles, encrypted and integrity-protected storage SHOULD be used for the session keys and counters.

Note that the Client-Server relationship of DTLS (i.e., who initiated the handshake) is separate from the Client-Server relationship of LWM2M.

Considering that any device with a LWM2M Client can be managed by any LWM2M Server and LWM2M Bootstrap Server the choice of Cipher Suites is not limited to the list defined in Section 9 of [CoAP]. Due the sensitive nature of Bootstrap Information, a particular care has to be taken to ensure protection of that data inducing constraints and dependencies within LWM2M Client/ Bootstrap Server relationship according to the adopted security mode.

Concerning Bootstrap from Smartcard, the same care has to be taken and a secure channel between the Smartcard and the LWM2M Device SHOULD be established as described in Appendix G in reference to _[_GLOBALPLATFORM 3], [GP SCP03].

The keying material used to secure the exchange of information using DTLS session is obtained using one of the bootstrap modes defined in Section 5.1.2 Bootstrap Modes. The formats of the keying material carried in the LWM2M Security Object Instances are defined in Appendix E.1.1.

The Resources (i.e., “Security Mode”, “Public Key or Identity” , “Server Public Key or Identity” and “Secret Key”) in the LWM2M Security Object that are associated with the keying material are used either

  1. for providing UDP channel security in “Client Registration”, “Device Management & Service Enablement”, and “Information Reporting” Interfaces if the LWM2M Security Object Instance relates to a LWM2M Server, or,
  2. for providing channel security in Bootstrap Interface if the LWM2M Security Object instance relates to a LWM2M Bootstrap Server.

LWM2M Clients MUST either be directly provisioned for use with a target LWM2M Server (Manufacturer Pre-configuration bootstrap mode) or else be provisioned for secure bootstrapping with an LWM2M Bootstrap Server. Any LWM2M Client which supports Client or Server initiated bootstrap mode MUST support at least one of the following secure methods:

  1. Bootstrapping with a strong (high-entropy) pre-shared secret, as described in 7.1.1. The cipher-suites defined in this section MUST NOT be used with only a low-entropy pre-shared secret.
  2. Bootstrapping with a temporary, low-entropy pre-shared secret (such as a PIN, password and private serial number) using the cipher-suite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, as defined in RFC5489.
  3. Bootstrapping with a public key or certificate-based method (as described in 7.1.2 and 7.1.3). The LWM2M Client MUST use a unique key-pair, one which is unique to each LWM2M Client.

For full interoperability, a LWM2M Bootstrap Server MUST support all of these methods.

NOTE: The above security methods can also be used by the LWM2M Bootstrap Server to provision KIc and KID for the SMS Secured Packet Structure mode (see Section 7.2.2 for SMS Secured Packet Structure mode).

Pre-Shared Keys

A LWM2M server MUST support the Pre-Shared Key mode of DTLS with the Cipher Suites below:

  • TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] as defined in Section 9.1.3.1 of [CoAP]
  • TLS_PSK_WITH_AES_128_CBC_SHA256 as defined in [RFC5487]

A LWM2M Client MUST support the Pre-Shared Key mode of DTLS with at least one of the Cipher Suites specified for the LWM2M Server. The LWM2M Client MUST use the value of the "Public Key or Identity" Resource for "PSK identity" in [RFC4279] and the value of "Secret Key" Resource for "PSK" in [RFC4279] as defined in Appendix E.1.

The LWM2M Client and LWM2M Server MAY support the use of other Cipher Suites.

For all Cipher Suites using AES in an LWM2M implementation, the hashing functions SHOULD be SHA256.

For all Cipher Suites using AES in an LWM2M implementation, the hashing functions MUST NOT be SHA-1, and MUST NOT be MD5, and MUST NOT be any other hashing function that is weaker than SHA-1 and MD5 or otherwise deprecated.

A LWM2M Client negotiates with the LWM2M Server the best method during the DTLS handshake for establishing the DTLS session.

This security mode is appropriate for LWM2M deployments where there is an existing trust relationship between the LWM2M Server and Client. The same PSKs and PSK IDs need to be generated, and installed on the Client and Server. When using a Bootstrap Server, this security mode requires a 3-way trust relationship between the Bootstrap Server, LWM2M Server(s) and LWM2M Client(s): namely Bootstrap Server got the secret key (PSK) from Server(s), and should also share a pre-provisioned secret with Client(s) for ensuring secure DTLS Bootstrap communication.

Using Smartcard PSK provisioning needs no pre-existing trust relationship between LWM2M Server(s) and LWM2M Client(s). The pre-established trust relationship is simply between the LWM2M Server(s) and the SmartCard(s).

Raw Public Key Certificates

If a LWM2M Server supports Raw Public Key Certificates it MUST support the Cipher Suites below:

  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as defined in Section 9.1.3.2 of [CoAP]
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in [RFC5289]

If a LWM2M Client supports Raw Public Key Certificates it MUST support at least one of the Cipher Suites supported by the LWM2M Server.

The LWM2M Client MUST use the value of the "Public Key or Identity" Resource for its Raw Public Key certificate and the value of "Secret Key" Resource for its Private Key as defined in Appendix E.1.

If the LWM2M Client and LWM2M Server supports Raw Public Key Certificates, they MAY support the use of other Cipher Suites.

If the LWM2M Client or LWM2M Server supports ECDHE and ECDSA for Raw Public Key Certificates, SHA-1 MUST NOT be used, and MD5 MUST NOT be used, and any other hashing function that is weaker than SHA-1 and MD5 or otherwise deprecated MUST NOT be used. The minimum key length MUST be at least 256 bits.

This security mode is appropriate for LWM2M deployments where there is an existing trust relationship between the LWM2M Server and Client. When using a Bootstrap Server, this security mode requires a 3-way trust relationship between the Bootstrap Server, LWM2M Server(s) and LWM2M Client(s): namely Bootstrap Server got the Client private key from Server(s), and should also share a pre-provisioned secret with Client(s) for ensuring secure DTLS Bootstrap communication.

The LWM2M Client MUST use the value of the "Public Key or Identity" Resource for its Raw Public Key certificate and the value of the "Secret Key" Resource for its Private Key as defined in Appendix E.1. The LWM2M Client MUST also use the "Server Public Key or Identity Resource" to determine the expected value of the LWM2M Server's raw public key, and MUST check that the raw public key presented by the LWM2M server exactly matches this stored public key.

Similarly, the LWM2M Server MUST store its own private and public keys, and MUST have a stored copy of the expected client public key. The server MUST check that the raw public key presented by the LWM2M client exactly matches this stored public key.

The server and client MUST use different key-pairs, and the LWM2M client MUST use a unique key-pair, one which is unique to each LWM2M client.

Using Smartcard RPK certificates provisioning needs no pre-existing trust relationship between LWM2M Server(s) and LWM2M Client(s). The pre-established trust relationship is simply between the LWM2M Server(s) and the SmartCard(s).

X.509 Certificates

The X.509 Certificate mode requires the use of X.509v3 Certificates [RFC5280].

Certificates used in LWM2M SHOULD be signed by a root certificate, either by a public root CA or a private root.

The LWM2M Client MUST either directly trust the server's X509 certificate or trust it indirectly by verifying it is correctly signed by a trusted CA.

In the case of direct trust, the LWM2M Client MUST have a copy of the expected LWM2M server certificate stored in the corresponding “Server Public Key or Identity Resource” and MUST check that the certificate presented by the LWM2M server exactly matches this stored certificate.

In the case of indirect trust, the LWM2M Client MUST have a copy of the expected CA certificate and expected LWM2M Server Subject and/or SubjectAltName names stored in the corresponding “Server Public Key or Identity Resource”. The LWM2M Client MUST check that the certificate presented by the LWM2M server is correctly signed by the expected CA, and that it contains the expected Subject and/or SubjectAltName infomation. A LWM2M Server Certificate SHOULD include Subject and/or SubjectAltName fields listing its known DNS names and IP addresses which are included in the LWM2M Server URI Resource of the LWM2M Security Object Instance. The LWM2M Server MAY use a wild card certificate for the DNS with the host represented as an and the rest of the domain fully qualified (e.g., .acme.com). A wildcard with only a top level domain is not permitted (e.g., *.com). The LWM2M Client MUST check that these fields of the Certificate match the URI used to register with the LWM2M Server.

Similarly, the LWM2M Server MUST either directly trust the LWM2M Client's X509 certificate or trust it indirectly by verifying it is correctly signed by a trusted CA certificate. In the case of direct trust, the server MUST store a copy of the expected LWM2M client certificate and MUST check that the certificate presented by the LWM2M client exactly matches this stored certificate. In the case of indirect trust, the server MUST store a copy of the expected CA certificate and expected LWM2M Client Subject and/or SubjectAltName names. The server MUST check that the certificate presented by the LWM2M Client is correctly signed by the expected CA certificate, is within its stated validity period, and contains the expected Subject and/or SubjectAltName information. A LWM2M Client Certificate MUST include the Endpoint Name parameter used to register the device in the Subject Common Name (CN) field of the Certificate. Upon registration, the LWM2M Server MUST check that this CN field matches the Endpoint Name parameter of the registration message during authentication and MUST respond “4.00 Bad Request” to the LWM2M Client if these fields do not match.

If a LWM2M server supports X.509 Certificate mode it MUST support the Cipher Suites below:

  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as defined in Section 9.1.3.3 of [CoAP].
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in [RFC5289]

If a LWM2M Client supports X.509 Certificate mode it MUST support at least one of the Cipher Suites supported by the LWM2M Server. The LWM2M Client MUST use the value of the "Public Key or Identity" Resource for its X.509 certificate and the value of "Secret Key" Resource for its Private Key as defined in Appendix E.1.

If the LWM2M Client and LWM2M Server supports X.509 Certificate mode, they MAY support the use of other Cipher Suites.

If the LWM2M Client or LWM2M Server supports ECDHE and ECDSA for X.509 Certificate mode, SHA-1 MUST NOT be used, and MD5 MUST NOT be used, and any other hashing function that is weaker than SHA-1 and MD5 or otherwise deprecated MUST NOT be used. The minimum key length MUST be at least 256 bits.

This security mode does not require a pre-existing trust relationship (if all entities used X.509 certificate security mode) between the LWM2M Client and LWM2M Server, nor between a LWM2M Bootstrap Server and a LWM2M Client. However, in the case of indirect trust, all entities need a trust relationship with the CA(s) that issued the certificates used in LWM2M Servers and Clients.

Using Smartcard with certificates provisioning needs no pre-existing trust relationship between LWM2M Server(s) and LWM2M Client(s). The pre-established trust relationship is simply between the LWM2M Server(s) and the SmartCard(s).

A LWM2M Client SHOULD wait until it has accurate absolute time before contacting the LWM2M Server or LWM2M Bootstrap Server. If the LWM2M Client uses direct trust, and has no accurate absolute time, it MUST ignore those components of the LWM2M Server or LWM2M Bootstrap Server certificate that involve absolute time, e.g. not-valid-before and not-valid-after certificate restrictions. If the LWM2M Client uses indirect trust, and has no accurate absolute time, it MUST otherwise establish that the LWM2M Server or LWM2M Bootstrap Server certificate is within its validity period. For example, the LWM2M Client MAY just know the date (or year), and the server certificate MAY have a long validity period, extending well before and after the expected time period needed to bootstrap the device.

“NoSec” mode

It is highly recommended to always use LWM2M with one of the security mechanisms described above. However, there are few scenarios and use cases where security is provided by lower layers. For example LWM2M devices in a controlled environment behind a gateway, or, tests focussing first on other functions before performing end-to-end tests including security.

results matching ""

    No results matching ""