9. Securing CoAP
This section defines the DTLS binding for CoAP.
During the provisioning phase, a CoAP device is provided with the security information that it needs to operate, including keying materials and access control lists. This specification defines the configuration for the RawPublicKey mode in Section 9.1.3.2.1. At the end of the provisioning phase, the device will be in one of the four security modes and will have the information for that mode as described below. The NoSec and RawPublicKey modes are mandatory to implement for this specification.
NoSec: There is no protocol-level security (DTLS is disabled). Alternative techniques to provide lower-layer security SHOULD be used when appropriate. The use of IPsec is discussed in [IPsec-CoAP]. Certain link layers in use with constrained nodes also provide link-layer security, which may be appropriate with proper key management.
PreSharedKey: DTLS is enabled, there is a list of pre-shared keys [RFC4279], and each key includes a list of which nodes it can be used to communicate with as described in Section 9.1.3.1. At the extreme, there can be one key for each node this CoAP node needs to communicate with (1:1 node/key ratio). Conversely, if more than two entities share a specific pre-shared key, this key only enables the entities to authenticate as a member of that group and not as a specific peer.
RawPublicKey: DTLS is enabled and the device has an asymmetric key pair without a certificate (a raw public key) that is validated using an out-of-band mechanism [RFC7250] as described in Section 9.1.3.2. The device also has an identity calculated from the public key and a list of identities of the nodes it can communicate with.
Certificate: DTLS is enabled and the device has an asymmetric key pair with an X.509 certificate [RFC5280] that binds it to its subject and is signed by some common trust root as described in Section 9.1.3.3. The device also has a list of root trust anchors that can be used for validating a certificate.
In the "NoSec" mode, the system simply sends the packets over normal UDP over IP. This is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes; see Section 11.5 for additional complexities in this approach.
The other three security modes use DTLS and are indicated by the "coaps" scheme and DTLS-secured CoAP default port. The result is a security association that can be used for authentication (within the limits of the security model) and, based on this authentication, authorizing the communication partner. CoAP itself does not provide protocol primitives for authentication or authorization; where this is required, it can be provided by communication security (i.e., IPsec or DTLS) or object security (within the payload). Devices that require authorization for some operations are expected to require one of these two forms of security. Necessarily, where communication security is used with a proxy, this only works when that proxy is part of the trust relationships. CoAP does not provide a way to forward different levels of authorization that clients may have with an intermediary to further intermediaries or origin servers -- this is a problem shared with HTTP, where it is customary to have the first intermediary perform all authorization.
9.1. DTLS-Secured CoAP
Just as HTTP is secured using Transport Layer Security (TLS) over TCP, CoAP is secured using Datagram TLS (DTLS) [RFC6347] over UDP (see Figure 13). This section defines the CoAP binding to DTLS, along with the minimal mandatory-to-implement configurations appropriate for constrained environments. The binding is defined by a series of deltas to unicast CoAP. In effect, DTLS is TLS with additional features to deal with the unreliable nature of the UDP transport.
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
Figure 13: Abstract Layering of DTLS-Secured CoAP
In some constrained nodes (limited flash and/or RAM) and networks (limited bandwidth or high scalability requirements), and depending on the particular cipher suite in use, not all modes of DTLS will be applicable. Some DTLS cipher suites can add significant implementation complexity as well as some initial handshake overhead that is required for setting up the security association. Once the initial handshake is completed, DTLS adds a limited per-datagram overhead of approximately 13 bytes, not including any initialization vector/nonce (e.g., 8 bytes for TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), integrity check value (e.g., 8 bytes for TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), and padding required by the cipher suite. Whether a given mode of DTLS is applicable for use with a CoAP-based application should be carefully weighed considering the specific cipher suite that may be applicable, whether session maintenance makes it compatible with application flows, and whether there are sufficient resources on the constrained nodes and for the added network overhead. (For some modes of using DTLS, this specification identifies mandatory-to-implement cipher suites; this is an implementation requirement to maximize interoperability in cases where these cipher suites are indeed appropriate. The specific security policy of an application may determine the actual set of cipher suites that can be used.) DTLS is not applicable to group keying (multicast communication); however, it may be a component of a future group key management protocol.
9.1.1. Endpoint Identity
The "coaps" scheme is based on the "coap" scheme, and the security considerations in Section 11.1 of [RFC3986] also apply. The security provided by the "coaps" scheme is at the IP layer (IPsec) or the transport layer (DTLS); as a result, intermediaries can open and close "coaps" messages, while still being able to check the correctness of any application-layer integrity checks. This is of particular importance for HTTP/CoAP cross-protocol proxies (see Section 10). Also, group keys may be used to provide confidentiality for multicast communications, but cannot be used to validate origin (Section 11.3).
9.1.2. Security Modes
The four security modes described at the start of Section 9 are implemented using DTLS or no security at the CoAP protocol level. The implementation requirements (mandatory to implement, etc.) can be found in Section 9.1.6.
9.1.3. Pre-Shared Keys
9.1.3.1. PSK Mode
DTLS supports the use of pre-shared keys (PSKs). DTLS with pre-shared keys as described in [RFC4279] enables authentication and confidentiality. The PSK modes specified in [RFC4279] are supported by DTLS-enabled CoAP nodes that implement this mode.
TLS_PSK_WITH_AES_128_CCM_8, as profiled for use in CoAP in [RFC7251], is the mandatory-to-implement cipher suite for CoAP nodes that implement this mode.
Some deployments may need to use certificates, raw public keys, or other authentication methods instead of PSK. If a CoAP implementation wants to be useful in the widest range of deployments, it should support all four of the defined security modes.
9.1.3.2. RawPublicKey Mode
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, as profiled in [RFC7251], is the mandatory-to-implement cipher suite for CoAP nodes that implement this mode. Implementations in this mode MUST use [RFC7250] to send and receive raw public keys.
9.1.3.2.1. Provisioning
The RawPublicKey mode needs appropriate provisioning of device keying material (asymmetric keys, trust anchor material).
An implementation can choose to determine the keying material using an out-of-band fashion, via so-called implicit provisioning.
Alternatively, in addition to implicit provisioning, an implementation MAY support the use of in-band provisioning protocols based on the raw public key. Note that a full in-band provisioning protocol can only be built on top of a bootstrapping protocol.
9.1.3.3. Certificate Mode
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, as profiled in [RFC7251], is the mandatory-to-implement cipher suite for CoAP nodes that implement this mode. Implementations in this mode MUST support [RFC5280].
Certificates, and the structure of certificate chains, are as specified in [RFC5280]. The URI-ID identifier type from Section 6.4.3 of [RFC6125] MUST be supported.
9.1.4. Server Name Indication
Constrained servers will often not have a way to easily identify which URI (or more generally which security context) is of interest to the client. Implementations may find it particularly helpful to use the Server Name Indication extension to DTLS/TLS [RFC6066] to help identify the security context for processing the incoming request.
9.1.5. New Associations
Each endpoint selects the security parameters used, including the cipher suite, in accordance with the application and system requirements. When a client opens a new session with a server, it requests that session be associated with the security parameters required by the server. Cipher suites that are mandatory to implement are defined in the sections for each mode of DTLS operation (Sections 9.1.3.1, 9.1.3.2, and 9.1.3.3). These MTI cipher suites might not be the right choice for every application or deployment: it is possible to disable them and use different cipher suites that might be more appropriate.
9.1.6. DTLS Version
Implementations in "PreSharedKey", "RawPublicKey", and "Certificate" mode MUST support and SHOULD prefer to use DTLS version 1.2 [RFC6347]. If an implementation detects that a peer implementation is only capable of DTLS version 1.0, it MAY use DTLS 1.0 for interoperability. DTLS 1.0 SHOULD NOT be used with DTLS-secured group communication.
9.1.7. DTLS Connection Management
As long as the DTLS handshake has not completed, a node SHOULD wait for the handshake to complete before sending a request. However, if the handshake fails, the security handshake should be considered failed. Some more details on connection management are needed here, but this is deferred for a later version of the specification.