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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/