Identifier Negotiation for the OSCORE Profile of ACE

In the OSCORE profile, the client and resource server receive the OSCORE Sender and Recipient Identifiers from the AS. This has some limitations, especially if the OSCORE profile is used in conjuction with other mechamisms that also derive identifiers, in which case either collisions would happen, or longer identifiers need to be used as a result. This document describes a way to negotiate the identifiers so that collisions does not happen even if other authentication mechanisms are used.

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 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.

| | | | | <---------------------------- Access Token ----- | | + Access Information | | ---- POST /authz-info ---> | | | (access_token, N1) | | | | | | <--- 2.01 Created (N2) --- | | | | | /Sec Context /Sec Context | Derivation/ Derivation/ | | | | | ---- OSCORE Request -----> | | | | | | /proof-of-possession | | Sec Context storage/ | | | | | <--- OSCORE Response ----- | | | | | /proof-of-possession | | Sec Context storage/ | | | | | | ---- OSCORE Request -----> | | | ... | | ]]> 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 mechanism also need to be used if a different AS (not sinchronized 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 longer identifiers to be used in general, which leads to larger message sizes, or additional processing on the RS. This document specifies a different mechanism to assign identifiers that works 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.

This section details the message exchange.

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 other Recipient Identifiers stored in memory. The client posts it together with what is described in Section 4.1 of . The Client includes the Recipient Id in the POST to authz-info request, as a ace_client_recipientid parameter, as 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 and discard any ServerId present in the access token.

The RS generates its own Recipient Id for the OSCORE Security Context that it is establishing with the client. The Recipient Id MUST be different than the ace_client_recipientid received from the client. By generating its own Recipient Id, the RS makes sure that it does not collide with any other Recipient Identifiers stored in memory. 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 parameeter, 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 RS does not support this specification, and the client sends its Recipient Id in the ace_client_recipientid, the server will not recognize the parameter and either respond with an error response or discard the parameter. If the RS replies with an error response or if the RS replies with a 2.01 (Created) not including the ace_server_recipientid parameter the Client MUST assume the server uses the identifiers in the token and do the same. TODO: so it is possible for anybody in the middle to revert back to OSCORE profile, without this addition, and therefore create collisions without identifiers.

TODO

This document has the following actions for IANA.

The following registrations are done for the OAuth ParametersRegistry following the procedure specified in section 11.2 of : o Parameter name: ace_client_recipientid o Parameter usage location: client-rs request o Change Controller: IESG o Specification Document(s): [[This specification]] o Parameter name: ace_server_recipientid o Parameter usage location: rs-client response o Change Controller: IESG o 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 :

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