The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework
Extracted elements (30)
Nonces N1 and N2 are exchanged and incorporated into the Master Salt so that reposting the same (non-expired) access token always produces a different OSCORE security context. Without this, a rebooted node reusing an old token would risk AEAD nonce/key reuse, breaking both confidentiality and integrity.
Proof-of-possession is not achieved through a dedicated protocol element but implicitly: both parties verify they hold the same shared secret by successfully completing OSCORE request/response exchanges. Mutual authentication is only complete after the client verifies an OSCORE response from the RS.
Although this profile specifies CoAP as the C-RS communication protocol, OSCORE can also secure HTTP and CoAP/HTTP combinations; an analogous ACE profile using HTTP instead of CoAP could be specified following the same structure.
Both client and RS MUST set the Master Salt to the concatenation salt | N1 | N2 (CBOR byte strings in order). In JSON mode, each component is prefixed by its 1-byte size before base64 encoding.
If ace_client_recipientid equals ace_server_recipientid, the client MUST stop the exchange and MUST NOT derive the security context, since Sender and Recipient Keys would be equal. The client MAY restart the exchange.
The access token request and response between the client and AS MUST be confidentiality protected and ensure authenticity. OSCORE is RECOMMENDED for this communication, but TLS or DTLS MAY alternatively be used.
The AS MUST send a different OSCORE_Input_Material (and therefore different access tokens) to different authorized clients so that the RS can differentiate between them.
The client MUST generate a nonce value N1 that is very unlikely to have been previously used with the same input keying material. A 64-bit random number is RECOMMENDED. The client MUST store N1 until the RS response is received or the token expires.
The client MUST wrap the access token, N1, and ID1 in a CBOR map when posting to the authz-info endpoint, using Content-Format application/ace+cbor. The nonce1 and ace_client_recipientid parameters carry N1 and ID1 respectively.
The OSCORE Master Secret MUST be encrypted by the AS so that only the RS can decrypt it. Use of a CWT protected with COSE_Encrypt/COSE_Encrypt0 is RECOMMENDED.
The RS MUST generate a nonce N2 unlikely to have been previously used with the same keying material, and MUST ensure ID2 differs from the value received in ace_client_recipientid. N2 and ID2 MUST be sent in the 2.01 Created response payload as a CBOR map.
The RS MUST NOT use the security context after the related token has expired and MUST respond with an unprotected 4.01 (Unauthorized) error to requests corresponding to a security context with an expired token.
To update access rights using the same OSCORE security context, the client MUST include a req_cnf object with the kid field carrying the OSCORE Input Material identifier in its POST to the token endpoint. The AS MUST verify that the received kid identifies a PoP key previously issued to that client.
When a client requests an access rights update, the request to authz-info MUST be protected using the existing OSCORE security context, and MUST contain only the access_token field — no nonce or identifier is sent.
OSCORE Recipient IDs (negotiated between client and RS) are privacy-sensitive per RFC 8613 Section 12.8 and could reveal information about the client or enable correlation of requests from a single client.
The access token and the nonces N1/N2 are sent in the clear to the authz-info endpoint. A client reusing the same token across multiple RSs or locations risks being tracked by the token's value. Random nonces are preferred over counters to avoid leaking state information.
The ace_client_recipientid parameter carries the client's chosen OSCORE Recipient ID (ID1) in the POST to authz-info; ace_server_recipientid carries the RS's chosen Recipient ID (ID2) in the 2.01 Created response. These become the Sender/Recipient IDs in the derived OSCORE security context.
The coap_oscore ACE profile (CBOR value 2) signals that OSCORE MUST be used towards all RSs for which the access token is valid. The AS includes this in the ace_profile parameter of the token response.
The nonce1 parameter carries the client-generated nonce N1 in the POST to authz-info; nonce2 carries the RS-generated nonce N2 in the 2.01 Created response. Both are encoded as CBOR byte strings (or base64 strings in JSON interactions).
The OSCORE_Input_Material is a CBOR map (or JSON object) conveying the input for deriving an OSCORE security context. It carries optional fields: id (label 0), version (1), ms (2), hkdf (3), alg (4), salt (5), and contextId (6). All parameters are optional.
IANA created the 'OSCORE Security Context Parameters' registry with columns Name, CBOR Label, CBOR Type, Registry, Description, Reference. Labels -256 to 255 and length-1 strings require Standards Track; -65536 to -257 / 256 to 65535 / length-2 strings require Specification Required; larger values use Expert Review; < -65536 is Private Use.
The 'ACE Profiles' registry is updated with entry coap_oscore (CBOR value 2), referencing RFC 9203. The 'OAuth Parameters' registry gains nonce1, nonce2, ace_client_recipientid, and ace_server_recipientid. The 'OAuth Parameters CBOR Mappings' registry gains corresponding entries with keys 40, 42, 43, 44.
The 'CWT Confirmation Methods' registry gains the 'osc' entry (Confirmation Key 4, type map) carrying OSCORE_Input_Material for per-message security with implicit key confirmation. The 'JWT Confirmation Methods' registry gains a matching 'osc' entry.
Nonces N1 and N2 MUST NOT be reused with the same input keying material even after reboots. Random 64-bit nonces are RECOMMENDED; a counter-based nonce is susceptible to on-path attackers replaying a client message to force reuse of an old AEAD (nonce, key) pair.
OSCORE is designed for point-to-point communication; this profile MUST NOT be used for point-to-multipoint scenarios (e.g., multicast, publish-subscribe), as doing so weakens OSCORE's security assurances.
Sharing a single OSCORE Input Material across multiple RSs allows those RSs to impersonate the client to one another and impersonate each other's RS to the client. Similarly, sharing a Master Secret across multiple clients enables client impersonation attacks.
The OSCORE security context lifecycle: ACTIVE (after derivation) → DISCARDED. Client triggers: sequence number space exhausted, token expires/invalidates, repeated 4.01 responses with same context, or new nonce received when reposting a non-expired token. RS triggers: sequence number space exhausted, token expires, or client successfully replaces context via authz-info.
In CBOR mode, the Master Salt is the concatenation of the CBOR-encoded input salt, nonce1, and nonce2 byte strings (each with CBOR length prefix). In JSON mode, each component is prefixed by its 1-byte size then the whole is base64-encoded; maximum component size is 255 bytes.
OAuth Parameters CBOR mappings: nonce1 maps to key 40 (bstr), nonce2 to key 42 (bstr), ace_client_recipientid to key 43 (bstr), ace_server_recipientid to key 44 (bstr).
The CBOR OSCORE_Input_Material uses CDDL: map keys are integers 0–6 for id (bstr), version (int), ms (bstr), hkdf (tstr/int), alg (tstr/int), salt (bstr), contextId (bstr). Additional key/value pairs of type (int/tstr => any) are allowed for extensibility.