Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
updated by
- rfc-9430 — Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)
Extracted elements (29)
Curve25519 is mandated in addition to secp256r1 because newer ECC curves are considered more efficient and less prone to implementation errors than NIST curves; this is a non-obvious mandatory addition given that RFC 7252 only requires secp256r1.
Short-lived access tokens in PSK mode are intentionally used to approximate forward-secrecy properties of ephemeral Diffie-Hellman; for longer-lived tokens, DHE cipher suites (TLS_DHE_PSK_* or TLS_ECDHE_PSK_*) should be used instead.
DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3, the access token is placed in the identity field of a PSKIdentity within the PreSharedKeyExtension of the ClientHello instead.
Any request received on a DTLS channel tied to an access token MUST be checked against the authorization rules; expired tokens MUST be removed, and unauthorized requests MUST be rejected with a 4.01 response.
DTLS MUST be used in a mode that provides replay protection.
If a resource server receives a ClientKeyExchange message with a psk_identity length greater than zero, it MUST parse the contents as a CBOR data structure; if it does not yield a valid access token, the server aborts the DTLS handshake with an illegal_parameter alert.
If the access token carries a symmetric key, the access token MUST be encrypted using a COSE_Encrypt0 structure, and the authorization server MUST use the keying material shared with the resource server to encrypt the token.
Implementations supporting RPK mode MUST support cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and MUST implement support for curve25519.
In PSK mode, a client MUST support the cipher suite TLS_PSK_WITH_AES_128_CCM_8.
In RPK mode, the client MUST add a req_cnf object carrying either its raw public key or a unique identifier for a public key in the token request to the authorization server.
The authorization server MUST check if the client is associated with the RPK in the req_cnf parameter before issuing an access token, and the access token MUST be bound to the RPK of the client via the cnf claim.
The authorization server MUST return the rs_cnf parameter unless it is certain the client already knows the resource server's public key, and MUST ascertain that the RPK in rs_cnf belongs to the intended resource server.
The client MUST securely have obtained keying material to communicate with the authorization server, and MUST verify that the authorization server is authorized to provide access tokens for the resource server.
The resource server MUST check if the access token is still valid, if the resource server is the intended audience, and if the token was issued by an authorized authorization server. A resource server MUST have the capacity to store one access token for every proof-of-possession key of every authorized client.
The resource server MUST delete access tokens that are no longer valid and MUST terminate existing DTLS associations after the last associated access token has expired.
The resource server MUST NOT accept an incoming CoAP request as authorized unless: the message was received on a secure channel established per this document, the authorization information is valid, the request is destined for the resource server, the resource URI is covered, and the request method is authorized.
The token request for a dynamic update MUST specify the key identifier (kid) of the PoP key used for the existing DTLS channel; the authorization server MUST verify the kid is valid and MUST include it in the new access token.
When the client uses asymmetric proof-of-possession keys, the client MUST upload the access token to the authz-info resource on the resource server before starting the DTLS handshake.
Unprotected responses to unauthorized requests may disclose information about the resource server or its relationship with the client; responses should include as little information as possible. Unprotected requests may reveal client identity and resource access patterns, so clients SHOULD NOT send confidential data in unprotected requests.
Dynamic update of authorization information allows a client to upload a new access token to the authz-info resource without re-establishing the DTLS session, provided the new token is bound to the same keying material as the existing DTLS channel.
In PSK mode, the access token may be transferred via the psk_identity field of the DTLS ClientKeyExchange message instead of uploading it to the authz-info endpoint beforehand. For DTLS 1.3, the token is placed in the identity field of a PSKIdentity within the PreSharedKeyExtension of the ClientHello.
The coap_dtls profile supports two key modes: Raw Public Key (RPK) mode using asymmetric keys per RFC 7250, and Pre-Shared Key (PSK) mode using symmetric keys per RFC 4279. Both use CoAP over DTLS 1.2 or later for communication between the client and resource server.
The HKDF-based key derivation for PSK mode uses OKM = HKDF(salt='', IKM=key_derivation_key, info=CBOR([type='ACE-CoAP-DTLS-key-derivation', L, access_token]), L) where L is the symmetric key size in bytes and access_token is treated as opaque.
A new entry 'coap_dtls' (CBOR value: 1) has been registered in the IANA 'ACE Profiles' registry. It describes a profile for delegating client authentication and authorization for constrained environments using DTLS.
Constrained devices using DTLS are vulnerable to DoS attacks during the handshake and at the unprotected authz-info endpoint. Adversaries can fill up the resource server's storage with valid intercepted access tokens; the resource server should set a time boundary to delete unused tokens.
In RPK mode, clients must not be able to request access tokens for arbitrary public keys without proving possession of the corresponding private key; failing to enforce this enables identity misbinding attacks where the token is usable by an unintended entity.
Multiple access tokens for a single client should be avoided. Dynamic update via access token upload can be compromised by packet delay or reordering, making it impossible to guarantee that reduced permissions take effect before the original token expires.
Session resumption should only be used with reasonably short-lived PoP keys; long-lived keying material combined with resumption can undermine forward secrecy and allows clients to resume without re-proving PoP key possession. Servers wanting to rekey SHOULD periodically force a full handshake.
The psk_identity field in PSK mode carries a CBOR-serialized cnf structure containing a COSE_Key with kid and symmetric key type. The example encoding for a single kid is: A1 08 A1 01 A2 01 04 02 48 3D 02 78 33 FC 62 67 CE.