OSCORE Profile of ACE v2

An OSCORE profile of ACE is defined in . That profiles describes how to set up OSCORE between nodes, while the OSCORE Sender and Recipient Identifiers, i.e. the identifiers of the OSCORE keying material, are assigned by the Authorization Server. This has some limitations, especially if the OSCORE profile is used in conjuction with other mechamisms that also derive identifiers, in which case there needs to be a mechanism in place to avoid collisions. This document describes a new OSCORE profile that builds on , and adds a mechanism for negotiating identifiers between Client and Resource Server.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in , such as Authorization Server (AS) and Resource Server (RS). Readers are expected to be familiar with the terms and concepts described in , especially on the use of Sender, Recipient and Context Identifiers.

TODO: introduce OSCORE Sender and Recipient Identifiers and how they are used in OSCORE. The OSCORE profile defined in specifies that the AS assigns and sends the OSCORE Sender and Recipient Identifiers to both Client and RS, together with the rest of the input material to derive the complete OSCORE Security Context. That is done by including these identifiers in the Access Token and Access Information response to the Client. The access token containing these identifiers is also forwarded to the RS by the Client. This works with a number of requirements: the OSCORE profile states that if other authentication mechanisms are used to set up OSCORE between the same client and RS, that do not rely on an AS assigning identifiers, collisions may happen and need to be mitigated. Such mitigation mechanisms also need to be used if a different AS (which does not synchronize identifiers with the first AS) or authentication protocol is used to set up OSCORE between the same RS and other clients. A mitigation example would be to use distinct namespaces of context identifiers for different authentication mechanisms or authentication servers. Another solution would be to use longer random identifiers. A third possible solution, acceptable if collisions are not expected to be numerous, would be to rely on trial and error of security contexts when receiving a message. These solutions have the drawback of requiring either some sort of agreement between different authentication mechanisms using disjoint namespaces for the identifiers, and/or longer identifiers to be used, which leads to larger message sizes, or additional processing on the RS. This document specifies an OSCORE profile that adds a mechanism to assign identifiers on top of the current OSCORE profile, and that allows to set up identifiers without collisions, even when other authentication mechanisms or non-syncrhonized AS are used. What specified in applies to this profile as well, with the modifications reported in the following sections. Although defining a separate profile, the reader is advised that the needs to be read side by side with this specification, to understand it.

This section defines the additions to Section 2 of . Once the client has retrieved the access token, and generated the nonce N1, the Client also generates a Recipient Identifier ID1 for use with the keying material associated to the RS. The client posts the token, N1 and its Recipient ID to the RS using the authz-info endpoint and mechanisms specified in section 5.8 of and Content-Format = application/ace+cbor. If the access token is valid, the RS replies to this request with a 2.01 (Created) response with Content-Format = application/ace+cbor, which contains a nonce N2 and a newly generated Recipient Identifier ID2 for use with the keying material associated to the Client in a CBOR map. Moreover, the server concatenates the input salt, N1, and N2 to obtain the Master Salt of the OSCORE Security Context (see section 3 of ). The RS then derives the complete Security Context associated with the received token from the Master Salt, the Recipient ID generated by the Client (set as its OSCORE Sender Id), the Recipient ID generated by itself (set as its OSCORE Recipient Id), plus the parameters received in the access token from the AS, following section 3.2 of . In a similar way, after receiving the nonce N2, the client concatenates the input salt, N1 and N2 to obtain the Master Salt of the OSCORE Security Context. The client then derives the complete Security Context from the Master Salt, the Recipient ID generated by the RS (set as its OSCORE Sender Id), the Recipient ID generated by itself (set as its OSCORE Recipient Id), plus the parameters received from the AS. After the whole message exchange has taken place, the client can contact the AS to request an update of its access rights, sending a similar request to the token endpoint that also includes an identifier so that the AS can find the correct OSCORE security material it has previously shared with the Client. This specific identifier, encoded as a byte string, is set by the AS to be unique in the sets of its OSCORE Security Contexts, and is not used as input material to derive the full OSCORE Security Context.

| | | | | <---------------------------- Access Token ----- | | + Access Information | | ---- POST /authz-info ---> | | | (access_token, N1, Id1) | | | | | | <- 2.01 Created (N2, Id2)- | | | | | /Sec Context /Sec Context | Derivation/ Derivation/ | | | | | ---- OSCORE Request -----> | | | | | | /proof-of-possession | | Sec Context storage/ | | | | | <--- OSCORE Response ----- | | | | | /proof-of-possession | | Sec Context storage/ | | | | | | ---- OSCORE Request -----> | | | ... | | ]]>

The following subsections apply modifications to what specified in Section 3 of .

If the client wants to update its access rights without changing an existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object. The req_cnf MUST include a kid field carrying a CBOR byte string containing the OSCORE_Input_Material Identifier (assigned as discussed in ). An example of an update of access rights request, with payload in CBOR diagnostic notation without the tag and value abbreviations is reported in .

The AS can signal that the use of OSCORE is REQUIRED for a specific access token by including the “profile” parameter with the value “coap_oscore_2” in the access token response. The AS MUST send the following data: a master secret an identifier of the OSCORE_Input_Material The AS MUST NOT include clientId or serverId, in the OSCORE_Input_Material, neither in the ‘cnf’ nor in the claims sets associated with the access token. The identifier of the OSCORE_Input_Material MUST be communicated as the ‘id’ field in the ‘osc’ field in the ‘cnf’ parameter of the access token response (and therefore included in the claims associated with the access token). We don’t assume in this document that a resource is associated to one single AS, since the AS is not tasked with enforcing uniqueness of identifiers for each client requesting a particular resource to a RS. This profile can also be used together with other authentication mechanisms such as EDHOC, see . shows an example of an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability.

shows an example CWT Claims Set, including the relevant OSCORE parameters in the ‘cnf’ claim, in CBOR diagnostic notation without tag and value abbreviations.

The same CWT Claims Set as in , using the value abbreviations defined in and and encoded in CBOR is shown in . The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the ‘#’ sign on the second column, for easiness of readability.

If the client has requested an update to its access rights using the same OSCORE_Input_Material, which is valid and authorized, the AS MUST omit the ‘cnf’ parameter in the response, and MUST carry the OSCORE_Input_Material Identifier in the ‘kid’ field in the ‘cnf’ parameter of the token. This identifier needs to be included in the token in order for the RS to identify the correct OSCORE Input Material. shows an example of such an AS response, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability.

shows an example CWT Claims Set, containing the necessary OSCORE parameters in the ‘cnf’ claim for update of access rights, in CBOR diagnostic notation without tag and value abbreviations.

The following parameter is added to the OSCORE_Input_Material object defined in Section 3.2.1 of .

This parameter identifies the OSCORE_Input_Material and is encoded as a byte string. In JSON, the "id" value is a Base64 encoded byte string. In CBOR, the "id" type is byte string, and has label 8.

Additionally to what specified in Section 4 of , the client also generates an identifier id1, unique in the sets of its own Recipient Ids, and posts it together with the token and nonce N1 to the RS. The RS also generates an identifier id2, unique in the sets of its own Recipient Ids, and uses it together with the rest of the input material to derive a security context. Both the nonces and identifiers are encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is used.

Additionally to what specified in Section 4.1 of , the following applies. The client generates its own Recipient Id for the OSCORE Security Context that it is establishing with the RS. By generating its own Recipient Id, the client makes sure that it does not collide with any of its Recipient Identifiers. The client posts it to the RS together with what is described in Section 4.1 of : the client includes the Recipient Id in the POST to authz-info request, as an ace_client_recipientid parameter, registered in and . When receiving the POST to authz-info request including the ace_client_recipientid parameter, the RS MUST set its own Sender Identifier to the value of the ace_client_recipientid. If the ace_client_recipientid parameter is not included in the request, the RS MUST stop processing the request and interrupt the Ace exchange, and MAY reply with a 4.00 (Bad Request) error message. If the access token received contains either the clientId or serverId parameters, the server SHOULD stop processing the message, and MAY reply with a 4.00 (Bad Request) error message. shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for readability.

This parameter MUST be sent from the client to the RS, together with the access token and the nonce, if the ace profile used is coap_oscore_2. The parameter is encoded as a byte string for CBOR-based interactions, and as a string (Base64 encoded binary) for JSON-based interactions. This parameter is registered in and .

Additionally to what specified in Section 4.2 of , the following applies. The RS generates its own Recipient Id for the OSCORE Security Context that it is establishing with the client. By generating its own Recipient Id, the RS makes sure that it does not collide with any of its Recipient Identifiers. The RS MUST ensure that id2 is different from the ace_client_recipientid. The RS sends it to the Client together with what is described in Section 4.2 of : the RS includes the Recipient Id in the 2.01 (Created) response, as a ace_server_recipientid parameter, as registered in and . When receiving the response including the ace_server_recipientid parameter, the Client MUST set its own Sender Identifier to the value of the ace_server_recipientid and discard any ClientId present in the access token. If the ace_server_recipientid parameter is not included in the response, the client MUST stop processing the response and interrupt the Ace exchange. shows an example of the response sent from the RS to the client, with payload in CBOR diagnostic notation without the tag and value abbreviations.

This parameter MUST be sent from the RS to the client, together with the access token and nonce, if the ace profile used is coap_oscore_2. The parameter is encoded as a byte string for CBOR-based interactions, and as a string (Base64 encoded binary) for JSON-based interactions. This parameter is registered in Section and .

Differently than what defined in Section 4.3 of , the client and RS do not set the Sender ID and Recipient ID from the parameters received from the AS in Section 3.2. Instead, the client MUST set the Sender ID from the ace_server_recipientid received in , and the Recipient ID from its own generated ace_client_recipientid. Conversely, the server MUST set the Sender ID from the ace_client_recipientid received in , and the Recipient ID from its own generated ace_server_recipientid.

TODO TBD: How do this profile and the v1 OSCORE profile work together? can the AS send a v1 profile + token and the c and RS try to run a v2? how does c react if it tries to run v2 and get reverted to v1? How do the 2 profiles work together?

TODO

This document has the following actions for IANA.

The following registration is done for the ACE Profile Registry following the procedure specified in section 8.8 of : Name: coap_oscore_2 Description: Profile for using OSCORE to secure communication between constrained nodes using the Authentication and Authorization for Constrained Environments framework. CBOR Value: TBD (value between 1 and 255) Reference: [[This specification]]

The following registrations are done for the OAuth ParametersRegistry following the procedure specified in section 11.2 of : Parameter name: ace_client_recipientid Parameter usage location: client request Change Controller: IESG Specification Document(s): [[This specification]] Parameter name: ace_server_recipientid Parameter usage location: token response Change Controller: IESG Specification Document(s): [[This specification]]

The following registrations are done for the OAuth Parameters CBOR Mappings Registry following the procedure specified in section 8.9 of :

The following registration is done for the ACE Profile Registry following the procedure specified in section 9.4 of : This registry will be populated by the values in . The specification column for all of these entries will be this document.

This document was started from comments and discussion with the following individuals: John Mattsson, Jim Schaad, Göran Selander.