--- 1/draft-ietf-oauth-mtls-04.txt 2017-11-12 15:13:09.218248550 -0800 +++ 2/draft-ietf-oauth-mtls-05.txt 2017-11-12 15:13:09.258249508 -0800 @@ -1,23 +1,23 @@ OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley -Expires: April 14, 2018 Yubico +Expires: May 16, 2018 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES Europe AG - October 11, 2017 + November 12, 2017 Mutual TLS Profile for OAuth 2.0 - draft-ietf-oauth-mtls-04 + draft-ietf-oauth-mtls-05 Abstract This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for certificate bound sender constrained access tokens. Status of This Memo @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 14, 2018. + This Internet-Draft will expire on May 16, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -146,21 +146,21 @@ key to a server when negotiating a TLS session. In TLS 1.2 [RFC5246] this requires the client to send Client Certificate and Certificate Verify messages during the TLS handshake and for the server to verify these messages. 2. Mutual TLS for OAuth Client Authentication This section defines, as an extension of OAuth 2.0, Section 2.3 [RFC6749], two distinct methods of using mutual TLS X.509 client certificates as client credentials. The requirement of mutual TLS - for client authentications is determined by the authorization server + for client authentication is determined by the authorization server based on policy or configuration for the given client (regardless of whether the client was dynamically registered or statically configured or otherwise established). In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server MUST have been established or reestablished with mutual X.509 certificate authentication (i.e. the Client Certificate and Certificate Verify messages are sent during the TLS Handshake [RFC5246]). @@ -192,21 +192,21 @@ client to rotate its X.509 certificates without the need to modify its respective authentication data at the authorization server by obtaining a new certificate with the same subject DN from a trusted certificate authority (CA). 2.1.1. PKI Authentication Method Metadata Value The "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] contains values, each of which specify a method of authenticating a client to the authorization server. The - values are used to indicated supported and utilized client + values are used to indicate supported and utilized client authentication methods in authorization server metadata, such as OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the PKI method of mutual TLS client authentication, this specification defines and registers the following authentication method metadata value. tls_client_auth Indicates that client authentication to the authorization server @@ -222,43 +222,43 @@ tls_client_auth_subject_dn An [RFC4514] string representation of the expected subject distinguished name of the certificate the OAuth client will use in mutual TLS authentication. 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method This method of mutual TLS OAuth client authentication is intended to support client authentication using self-signed certificates. As - pre-requisite, the client registers a X.509 certificate or a trusted + pre-requisite, the client registers an X.509 certificate or a trusted source for its X.509 certificates (such as the "jwks_uri" as defined in [RFC7591]) with the authorization server. During authentication, TLS is utilized to validate the client's possession of the private key corresponding to the public key presented within the certificate in the respective TLS handshake. In contrast to the PKI method, the certificate chain is not validated in this case. The client is successfully authenticated, if the subject public key info of the - certificate matches the subject public key info of one the + certificate matches the subject public key info of one of the certificates configured or registered for that particular client. The Self-Signed Certificate method allows to use mutual TLS to authenticate clients without the need to maintain a PKI. When used in conjunction with a "jwks_uri" for the client, it also allows the client to rotate its X.509 certificates without the need to change - its respective authentication data directly with at the authorization + its respective authentication data directly with the authorization server. 2.2.1. Self-Signed Certificate Authentication Method Metadata Value The "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] contains values, each of which specify a method of authenticating a client to the authorization server. The - values are used to indicated supported and utilized client + values are used to indicate supported and utilized client authentication methods in authorization server metadata, such as OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0 Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the Self-Signed Certificate method of binding a certificate to a client using mutual TLS client authentication, this specification defines and registers the following authentication method metadata value. self_signed_tls_client_auth Indicates that client authentication to the authorization server @@ -301,32 +301,31 @@ not match, the resource access attempt MUST be rejected with an error per [RFC6750] using an HTTP 401 status code and the "invalid_token" error code. Metadata to convey server and client capabilities for mutual TLS sender constrained access tokens is defined in Section 3.3 and Section 3.4 respectively. 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT - When access tokens are represented as a JSON Web Tokens - (JWT)[RFC7519], the certificate hash information SHOULD be - represented using the "x5t#S256" confirmation method member defined - herein. + When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], + the certificate hash information SHOULD be represented using the + "x5t#S256" confirmation method member defined herein. To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method RFC 7800 [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash (a.k.a. thumbprint or digest) of the DER encoding of the X.509 certificate[RFC5280] (note that certificate thumbprints are also - sometimes also known as certificate fingerprints). + sometimes known as certificate fingerprints). The following is an example of a JWT payload containing an "x5t#S256" certificate thumbprint confirmation method. { "iss": "https://server.example.com", "sub": "ty.webb@example.com", "exp": 1493726400, "nbf": 1493722800, "cnf":{ @@ -449,38 +448,37 @@ purpose of client authentication, the resource server may completely rely on the authorization server. So there is no need to validate the trust chain of the client's certificate in any of the methods defined in this document. The resource server should therefore configure the TLS stack in a way that it does not verify whether the certificate presented by the client during the handshake is signed by a trusted CA certificate. 4.3. Sender Constrained Access Tokens Without Client Authentication - This document allows for the use of client authentication only or - client authentication in combination with sender constraint access - tokens. Use of mutual TLS sender constrained access tokens without - client authentication (e.g. to support binding access tokens to a TLS - client certificate for public clients) is also possible. The - authorization server would configure the TLS stack in the same manner - as for the Self-Signed Certificate method such that it does not - verify that the certificate presented by the client during the - handshake is signed by a trusted CA. Individual instances of a - public client would then create a self-signed certificate for mutual - TLS with the authorization server and resource server. The - authorization server would not authenticate the client at the OAuth - layer but would bind issued access tokens to the certificate, which - the client has proven possession of the corresponding private key. - The access token is then mutual TLS sender constrained and can only - be used by the client possessing the certificate and private key and - utilizing them to negotiate mutual TLS on connections to the resource - server. + This document allows use of client authentication only or client + authentication in combination with sender constraint access tokens. + Use of mutual TLS sender constrained access tokens without client + authentication (e.g. to support binding access tokens to a TLS client + certificate for public clients) is also possible. The authorization + server would configure the TLS stack in the same manner as for the + Self-Signed Certificate method such that it does not verify that the + certificate presented by the client during the handshake is signed by + a trusted CA. Individual instances of a public client would then + create a self-signed certificate for mutual TLS with the + authorization server and resource server. The authorization server + would not authenticate the client at the OAuth layer but would bind + issued access tokens to the certificate, which the client has proven + possession of the corresponding private key. The access token is + then mutual TLS sender constrained and can only be used by the client + possessing the certificate and private key and utilizing them to + negotiate mutual TLS on connections to the resource server. 4.4. Certificate Bound Access Tokens As described in Section 3, an access token is bound to a specific client certificate, which means that the same certificate must be used for mutual TLS on protected resource access. It also implies that access tokens are invalidated when a client updates the certificate, which can be handled similar to expired access tokens where the client requests a new access token (typically with a refresh token) and retries the protected resource request. @@ -557,22 +555,22 @@ subject distinguished name of the client certificate. o Change Controller: IESG o Specification Document(s): Section 2.1.2 of [[ this specification ]] 6. Security Considerations 6.1. TLS Versions and Best Practices TLS 1.2 [RFC5246] is cited in this document because, at the time of - writing, it is latest version that is widely deployed. However, this - document is applicable with other TLS versions supporting + writing, it is the latest version that is widely deployed. However, + this document is applicable with other TLS versions supporting certificate-based client authentication. Implementation security considerations for TLS, including version recommendations, can be found in Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. 6.2. X.509 Certificate Spoofing If the PKI method is used, an attacker could try to impersonate a client using a certificate for the same DN issued by another CA, which the authorization server trusts. To cope with that threat, the @@ -674,28 +672,33 @@ Appendix A. Acknowledgements Scott "not Tomlinson" Tomilson and Matt Peterson were involved in design and development work on a mutual TLS OAuth client authentication implementation that informed some of the content of this document. Additionally, the authors would like to thank the following people for their input and contributions to the specification: Sergey - Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Sean - Leonard, Kepeng Li, James Manger, Jim Manico, Nov Matake, Sascha - Preibisch, Justin Richer, Dave Tonge, and Hannes Tschofenig. + Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Takahiko + Kawasaki Sean Leonard, Kepeng Li, James Manger, Jim Manico, Nov + Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes + Tschofenig. Appendix B. Document(s) History [[ to be removed by the RFC Editor before publication as an RFC ]] + draft-ietf-oauth-mtls-05 + + o Editorial fixes + draft-ietf-oauth-mtls-04 o Change the name of the 'Public Key method' to the more accurate 'Self-Signed Certificate method' and also change the associated authentication method metadata value to "self_signed_tls_client_auth". o Removed the "tls_client_auth_root_dn" client metadata field as discussed in https://mailarchive.ietf.org/arch/msg/oauth/ swDV2y0be6o8czGKQi1eJV-g8qc o Update draft-ietf-oauth-discovery reference to -07