]> Siemens

hannes.tschofenig@gmx.net

Siemens

jan.herrmann@siemens.com

Intel Corperation

ned.smith@intel.com

Massachusetts Institute of Technology

hardjono@mit.edu

Security OAuth Internet-Draft The OAuth 2.0 Dynamic Client Registration specification described in RFC 7591 describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain information to interact with this authorization server, including an OAuth 2.0 client identifier. To offer proper security protection for this dynamic client registration some security credentials need to be available on the OAuth 2.0 client. For this purpose RFC 7591 relies on two mechanisms, a trust-on-first-use model and a model where the client is in possession of a software statement (a sort-of bearer token). This specification improves the security of the OAuth 2.0 Dynamic Client Registration specification by introducing the support of attestation.

Introduction The OAuth 2.0 Dynamic Client Registration specification described in RFC 7591 describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain information to interact with this authorization server, including an OAuth 2.0 client identifier. As part of the registration process, this specification also defines a mechanism for the client to present the authorization server with a set of metadata, such as a set of valid redirection URIs. To offer proper security protection for this dynamic client registration some security credentials need to be available on the OAuth 2.0 client. For this purpose RFC 7591 relies on two mechanisms, a trust-on-first-use model and a model where the client is in possession of a software statement (a sort-of bearer token). This specification improves the security of the OAuth 2.0 Dynamic Client Registration specification by introducing the support of attestation. shows the high-level communication pattern of the IETF RATS background check model where the attester transmits the evidence in the OAuth 2.0 Dynamic Client Registration to the authorization server. The authorization server thereby acts as a relying party and relays the evidence to the verifier. The verifier processes the received evidence and computes an attestation result, which is then processed by the authorization server. Note that the verifier is a logical role that may be included in an authorization server product. In this case the interaction between the relying party and the verifier is local.

|---' | Compare Attestation | OAuth 2.0 | Evidence | Relying | Result against | Client | in Dynamic | Party (AS) | policy '------------' Client Reg. '---------------' ]]>

As a design goal, the proposed extension is agnostic to the attestation technology being used. No new attestation technology (and evidence format in particular) is defined by this specification. Instead, this document focuses on conveying evidence to the authorization server during the process of dynamically registering a client. To prevent the replay of evidence, attestation technologies require some replay protection to be used. Nonce-based freshness is one approach supported by various attestation technologies. TPM v2.0 , for example, supports nonce-based replay protection. Hence, it is necessary to convey a nonce from the authorization server (which typically obtains it from the verifier) to the OAuth 2.0 Client. In we describe the protocol mechanism

Conventions and Definitions 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. This document re-uses the terms defined in RFC 9334 related to remote attestation. Readers of this document are assumed to be familiar with the following terms: evidence, claim, attestation result, attester, verifier, and relying party.

Extension This section defines the extensions needed to support the use of attestation. The abstract OAuth 2.0 client dynamic registration flow illustrated in describes the interaction between the client or developer and the endpoint defined in . This figure does not demonstrate error conditions.

| Client | | Client or | | Registration | | Developer |<-(D)- Client Information Response ---| Endpoint | | | or Client Error Response +---------------+ +-----------+ ]]>

This flow includes the following steps: (A) Optionally, but defined in this specification, the client is obtains evidence from an attester. The attester is typically a component on the device that consists of hardware and low-level software. The methodused by the OAuth 2.0 software to obtain evidence is specific to a given attestation technology and outside the scope for this specification. (B) Optionally, the client or developer is issued an initial access token or a software statement giving access to the client registration endpoint. The method by which the initial access token or the software statement are issued to the client or developer is out of scope for this specification. (C) The client or developer calls the client registration endpoint with the client's desired registration metadata, optionally including information from (A) or (B) if one is required by the authorization server. (D) The authorization server registers the client and returns: the client's registered metadata, a client identifier that is unique at the server, and a set of client credentials such as a client secret, if applicable for this client. This specification re-uses the client registration endpoint, as described in Section 3.1 of . Upon a successful registration request, the authorization server returns a client identifier for the client. The server responds with an HTTP 201 Created status code and a body of type "application/json" with content as described in Section 3.2.1 of . If evidence was used as part of the registration, its value MUST NOT be returned in the response along with other metadata to the OAuth 2.0 client. Evidence is only communicated from the OAuth 2.0 client to the authorization server - not vice versa. Upon an unsuccessful registration request, the authorization server responds with an error, as described in Section 3.2.2 of . This specification defines a new error message that is used when the authorization server challenges the OAuth 2.0 client for evidence using a fresh nonce. The nonce MUST be randomly generated with a length of 32 bytes or more (before base64 encoding the value). The error is defined as:

A new member is used in the response JSON object called "nonce". It contains the nonce value that will be used by the OAuth 2.0 client as input to the API call for requesting fresh evidence from the attester. Typically, the nonce value will be included (directly or indirectly) in the returned evidence. The verifier who provided the nonce to the authorization server MUST store the provided nonce for later comparison against the nonce included in the evidence. An OAuth 2.0 client that is configured to use attestation information with dynamic client registration MAY send a minimal registration request in the anticipation that an error response will follow. This error response will contain a nonce, which is then used to obtain fresh evidence from the attester. At a minimum the OAuth 2.0 client MUST convey the "client_name" but MAY also include any (likely stale) evidence available since it might provide the authorization server with information to distinguish clients with different capabilities, some of which may not offer any attestation capabilities. Once an error response with a nonce is available the OAuth 2.0 client MUST include the obtained evidence in the newly constructed full request. The following is a non-normative example of an error response containing a nonce (with line breaks within values for display purposes only):

To include evidence in a registration request the following OPTIONAL member is included in the JSON object:

[Editor's Note: The evidence structure may utilize the format defined in the RATS Conceptual Messages Wrapper specification , which allows to indicate type information as well.] In the following example, a request is sent containing attestation evidence and registering a JWK Set by value (with line breaks within values for display purposes only). Some registration parameters are conveyed in the evidence while some values specific to the client instance are conveyed as regular parameters.

Security Considerations It is up to the verifier and to the authorization server to place as much or as little trust in the evidence provided by the attester on the OAuth 2.0 client information as dictated by policies. This document defines the transport of evidence of different formats in the OAuth 2.0 Dynamic Client Registration protocol. Some of the attestation formats are based on standards while others are proprietary formats. A verifier will need to understand these formats for matching the received values against policies. Policies drive the processing of evidence at the verifier and other policies influence the decision making at the relying party when evaluating the attestation result. The relying party is ultimately responsible for making a decision of what attestation-related information it will accept. The presence of the evidence defined in this specification provide the authorizations server with additional assurance about attester (and indirectly about the OAuth 2.0 client). Policies used at the verifier and the authorization are implementation and configuration dependent and out of scope for this document. Whether to require the use of evidence in OAuth 2.0 Dynamic Client Registration is out-of-scope for this document. Evidence generated by the attestation generally needs to be fresh to provide value to the verifier since the configuration on the device may change over time. Section 10 of discusses different approaches for providing freshness, including a nonce-based approach, the use of timestamps and an epoch-based technique. The use of nonces requires an extra message exchange and the use of timestamps requires synchronized clocks. Epochs also require communication. This document offers a way to convey a nonce to the tester to allow evidence to be freshly generated. Different attestation technologies provide different security and privacy properties. Some evidence formats convey more information about the target environment while others offer less. Some evidence formats offer the security capabilities equivalent to a bearer tokens while others are semantically closer to proof-of-possession tokens. Implementers and operators need to make a conscious decision about the attestation technologies they want to support in their products.

IANA Considerations TBD.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Fraunhofer SIT Intel Linaro This document defines two encapsulation formats for RATS conceptual messages (i.e., evidence, attestation results, endorsements and reference values.) The first format uses a CBOR or JSON array with two mandatory members, one for the type, another for the value, and a third optional member complementing the type field that says which kind of conceptual message(s) are carried in the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. This document also defines a corresponding CBOR tag, as well as JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims. These allow embedding the wrapped conceptual messages into CBOR-based protocols and web tokens, respectively. Trusted Computing Group

Acknowledgements We would like to thank the OAuth working group for their feedback at the 117 meeting in San Francisco. We would also like to thank Ionut Mihalcea for his review.