draft-ietf-oauth-mtls-13.txt   draft-ietf-oauth-mtls-14.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: August 29, 2019 Yubico Expires: October 13, 2019 Yubico
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES.com AG YES.com AG
February 25, 2019 April 11, 2019
OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound
Access Tokens Access Tokens
draft-ietf-oauth-mtls-13 draft-ietf-oauth-mtls-14
Abstract Abstract
This document describes OAuth client authentication and certificate- This document describes OAuth client authentication and certificate-
bound access tokens using mutual Transport Layer Security (TLS) bound access and refresh tokens using mutual Transport Layer Security
authentication with X.509 certificates. OAuth clients are provided a (TLS) authentication with X.509 certificates. OAuth clients are
mechanism for authentication to the authorization server using mutual provided a mechanism for authentication to the authorization server
TLS, based on either self-signed certificates or public key using mutual TLS, based on either self-signed certificates or public
infrastructure (PKI). OAuth authorization servers are provided a key infrastructure (PKI). OAuth authorization servers are provided a
mechanism for binding access tokens to a client's mutual TLS mechanism for binding access tokens to a client's mutual TLS
certificate, and OAuth protected resources are provided a method for certificate, and OAuth protected resources are provided a method for
ensuring that such an access token presented to it was issued to the ensuring that such an access token presented to it was issued to the
client presenting the token. client presenting the token.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 29, 2019. This Internet-Draft will expire on October 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation and Conventions . . . . . . . . . . 5 1.1. Requirements Notation and Conventions . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 5 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 5
2.1. PKI Mutual TLS Method . . . . . . . . . . . . . . . . . . 6 2.1. PKI Mutual TLS Method . . . . . . . . . . . . . . . . . . 6
2.1.1. PKI Method Metadata Value . . . . . . . . . . . . . . 6 2.1.1. PKI Method Metadata Value . . . . . . . . . . . . . . 6
2.1.2. Client Registration Metadata . . . . . . . . . . . . 6 2.1.2. Client Registration Metadata . . . . . . . . . . . . 7
2.2. Self-Signed Certificate Mutual TLS Method . . . . . . . . 7 2.2. Self-Signed Certificate Mutual TLS Method . . . . . . . . 7
2.2.1. Self-Signed Method Metadata Value . . . . . . . . . . 8 2.2.1. Self-Signed Method Metadata Value . . . . . . . . . . 8
2.2.2. Client Registration Metadata . . . . . . . . . . . . 8 2.2.2. Client Registration Metadata . . . . . . . . . . . . 8
3. Mutual TLS Client Certificate Bound Access Tokens . . . . . . 8 3. Mutual TLS Client Certificate-Bound Access Tokens . . . . . . 8
3.1. JWT Certificate Thumbprint Confirmation Method . . . . . 9 3.1. JWT Certificate Thumbprint Confirmation Method . . . . . 9
3.2. Confirmation Method for Token Introspection . . . . . . . 10 3.2. Confirmation Method for Token Introspection . . . . . . . 10
3.3. Authorization Server Metadata . . . . . . . . . . . . . . 11 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 11
3.4. Client Registration Metadata . . . . . . . . . . . . . . 11 3.4. Client Registration Metadata . . . . . . . . . . . . . . 11
4. Public Clients and Certificate Bound Tokens . . . . . . . . . 11 4. Public Clients and Certificate-Bound Tokens . . . . . . . . . 11
5. Metadata for Mutual TLS Endpoint Aliases . . . . . . . . . . 12 5. Metadata for Mutual TLS Endpoint Aliases . . . . . . . . . . 12
6. Implementation Considerations . . . . . . . . . . . . . . . . 13 6. Implementation Considerations . . . . . . . . . . . . . . . . 13
6.1. Authorization Server . . . . . . . . . . . . . . . . . . 14 6.1. Authorization Server . . . . . . . . . . . . . . . . . . 14
6.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 14 6.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 14
6.3. Certificate Expiration and Bound Access Tokens . . . . . 15 6.3. Certificate Expiration and Bound Access Tokens . . . . . 15
6.4. Implicit Grant Unsupported . . . . . . . . . . . . . . . 15 6.4. Implicit Grant Unsupported . . . . . . . . . . . . . . . 15
6.5. TLS Termination . . . . . . . . . . . . . . . . . . . . . 15 6.5. TLS Termination . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Certificate Thumbprint Binding . . . . . . . . . . . . . 15 7.1. Certificate-Bound Refresh Tokens . . . . . . . . . . . . 15
7.2. TLS Versions and Best Practices . . . . . . . . . . . . . 16 7.2. Certificate Thumbprint Binding . . . . . . . . . . . . . 16
7.3. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 16 7.3. TLS Versions and Best Practices . . . . . . . . . . . . . 16
7.4. X.509 Certificate Parsing and Validation Complexity . . . 16 7.4. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 16
7.5. X.509 Certificate Parsing and Validation Complexity . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. JWT Confirmation Methods Registration . . . . . . . . . . 17 9.1. JWT Confirmation Methods Registration . . . . . . . . . . 17
9.2. Authorization Server Metadata Registration . . . . . . . 17 9.2. Authorization Server Metadata Registration . . . . . . . 18
9.3. Token Endpoint Authentication Method Registration . . . . 18 9.3. Token Endpoint Authentication Method Registration . . . . 18
9.4. Token Introspection Response Registration . . . . . . . . 18 9.4. Token Introspection Response Registration . . . . . . . . 18
9.5. Dynamic Client Registration Metadata Registration . . . . 19 9.5. Dynamic Client Registration Metadata Registration . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Example "cnf" Claim, Certificate and JWK . . . . . . 22 Appendix A. Example "cnf" Claim, Certificate and JWK . . . . . . 23
Appendix B. Relationship to Token Binding . . . . . . . . . . . 23 Appendix B. Relationship to Token Binding . . . . . . . . . . . 24
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix D. Document(s) History . . . . . . . . . . . . . . . . 24 Appendix D. Document(s) History . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The OAuth 2.0 Authorization Framework [RFC6749] enables third-party The OAuth 2.0 Authorization Framework [RFC6749] enables third-party
client applications to obtain delegated access to protected client applications to obtain delegated access to protected
resources. In the prototypical abstract OAuth flow, illustrated in resources. In the prototypical abstract OAuth flow, illustrated in
Figure 1, the client obtains an access token from an entity known as Figure 1, the client obtains an access token from an entity known as
an authorization server and then uses that token when accessing an authorization server and then uses that token when accessing
protected resources, such as HTTPS APIs. protected resources, such as HTTPS APIs.
skipping to change at page 6, line 15 skipping to change at page 6, line 17
configuration using the client identifier and check the certificate configuration using the client identifier and check the certificate
presented in the TLS Handshake against the expected credentials for presented in the TLS Handshake against the expected credentials for
that client. The authorization server MUST enforce the binding that client. The authorization server MUST enforce the binding
between client and certificate as described in either Section 2.1 or between client and certificate as described in either Section 2.1 or
Section 2.2 below. Section 2.2 below.
2.1. PKI Mutual TLS Method 2.1. PKI Mutual TLS Method
The PKI (public key infrastructure) method of mutual TLS OAuth client The PKI (public key infrastructure) method of mutual TLS OAuth client
authentication adheres to the way in which X.509 certificates are authentication adheres to the way in which X.509 certificates are
traditionally used for authentication. It relies on a subject traditionally used for authentication. It relies on a validated
distinguished name (DN) or a subject alternative name (SAN) and certificate chain [RFC5280] and a single subject distinguished name
validated certificate chain [RFC5280] to authenticate the client. (DN) or a single subject alternative name (SAN) to authenticate the
The TLS handshake is utilized to validate the client's possession of client. Only one subject name value of any type is used for each
the private key corresponding to the public key in the certificate client. The TLS handshake is utilized to validate the client's
and to validate the corresponding certificate chain. The client is possession of the private key corresponding to the public key in the
successfully authenticated if the subject information in the certificate and to validate the corresponding certificate chain. The
certificate matches the expected subject configured or registered for client is successfully authenticated if the subject information in
that particular client (note that a predictable treatment of DN the certificate matches the single expected subject configured or
values, such as the distinguishedNameMatch rule from [RFC4517], is registered for that particular client (note that a predictable
needed in comparing the certificate's subject DN to the client's treatment of DN values, such as the distinguishedNameMatch rule from
registered DN). Revocation checking is possible with the PKI method [RFC4517], is needed in comparing the certificate's subject DN to the
but if and how to check a certificate's revocation status is a client's registered DN). Revocation checking is possible with the
deployment decision at the discretion of the authorization server. PKI method but if and how to check a certificate's revocation status
Clients can rotate their X.509 certificates without the need to is a deployment decision at the discretion of the authorization
modify the respective authentication data at the authorization server server. Clients can rotate their X.509 certificates without the need
by obtaining a new certificate with the same subject from a trusted to modify the respective authentication data at the authorization
certificate authority (CA). server by obtaining a new certificate with the same subject from a
trusted certificate authority (CA).
2.1.1. PKI Method Metadata Value 2.1.1. PKI Method Metadata Value
For the PKI method of mutual TLS client authentication, this For the PKI method of mutual TLS client authentication, this
specification defines and registers the following authentication specification defines and registers the following authentication
method metadata value into the "OAuth Token Endpoint Authentication method metadata value into the "OAuth Token Endpoint Authentication
Methods" registry [IANA.OAuth.Parameters]. Methods" registry [IANA.OAuth.Parameters].
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 8, line 39 skipping to change at page 8, line 46
"jwks_uri" parameter is a URL that references a client's JWK Set. A "jwks_uri" parameter is a URL that references a client's JWK Set. A
certificate is represented with the "x5c" parameter of an individual certificate is represented with the "x5c" parameter of an individual
JWK within the set. Note that the members of the JWK representing JWK within the set. Note that the members of the JWK representing
the public key (e.g. "n" and "e" for RSA, "x" and "y" for EC) are the public key (e.g. "n" and "e" for RSA, "x" and "y" for EC) are
required parameters per [RFC7518] so will be present even though they required parameters per [RFC7518] so will be present even though they
are not utilized in this context. Also note that that sec 4.7 of are not utilized in this context. Also note that that sec 4.7 of
[RFC7517] requires that the key in the first certificate of the "x5c" [RFC7517] requires that the key in the first certificate of the "x5c"
parameter match the public key represented by those other members of parameter match the public key represented by those other members of
the JWK. the JWK.
3. Mutual TLS Client Certificate Bound Access Tokens 3. Mutual TLS Client Certificate-Bound Access Tokens
When mutual TLS is used by the client on the connection to the token When mutual TLS is used by the client on the connection to the token
endpoint, the authorization server is able to bind the issued access endpoint, the authorization server is able to bind the issued access
token to the client certificate. Such a binding is accomplished by token to the client certificate. Such a binding is accomplished by
associating the certificate with the token in a way that can be associating the certificate with the token in a way that can be
accessed by the protected resource, such as embedding the certificate accessed by the protected resource, such as embedding the certificate
hash in the issued access token directly, using the syntax described hash in the issued access token directly, using the syntax described
in Section 3.1, or through token introspection as described in in Section 3.1, or through token introspection as described in
Section 3.2. Binding the access token to the client certificate in Section 3.2. Binding the access token to the client certificate in
that fashion has the benefit of decoupling that binding from the that fashion has the benefit of decoupling that binding from the
skipping to change at page 11, line 19 skipping to change at page 11, line 19
"active": true, "active": true,
"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":{
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
} }
} }
Figure 3: Example Introspection Response for a Certificate Bound Figure 3: Example Introspection Response for a Certificate-Bound
Access Token Access Token
3.3. Authorization Server Metadata 3.3. Authorization Server Metadata
This document introduces the following new authorization server This document introduces the following new authorization server
metadata parameter to signal the server's capability to issue metadata parameter to signal the server's capability to issue
certificate bound access tokens: certificate bound access tokens:
tls_client_certificate_bound_access_tokens tls_client_certificate_bound_access_tokens
OPTIONAL. Boolean value indicating server support for mutual TLS OPTIONAL. Boolean value indicating server support for mutual TLS
skipping to change at page 11, line 43 skipping to change at page 11, line 43
3.4. Client Registration Metadata 3.4. Client Registration Metadata
The following new client metadata parameter is introduced to convey The following new client metadata parameter is introduced to convey
the client's intention to use certificate bound access tokens: the client's intention to use certificate bound access tokens:
tls_client_certificate_bound_access_tokens tls_client_certificate_bound_access_tokens
OPTIONAL. Boolean value used to indicate the client's intention OPTIONAL. Boolean value used to indicate the client's intention
to use mutual TLS client certificate-bound access tokens. If to use mutual TLS client certificate-bound access tokens. If
omitted, the default value is "false". omitted, the default value is "false".
4. Public Clients and Certificate Bound Tokens 4. Public Clients and Certificate-Bound Tokens
Mutual TLS OAuth client authentication and certificate-bound access Mutual TLS OAuth client authentication and certificate-bound access
tokens can be used independently of each other. Use of certificate- tokens can be used independently of each other. Use of certificate-
bound access tokens without mutual TLS OAuth client authentication, bound access tokens without mutual TLS OAuth client authentication,
for example, is possible in support of binding access tokens to a TLS for example, is possible in support of binding access tokens to a TLS
client certificate for public clients (those without authentication client certificate for public clients (those without authentication
credentials associated with the "client_id"). The authorization credentials associated with the "client_id"). The authorization
server would configure the TLS stack in the same manner as for the 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 Self-Signed Certificate method such that it does not verify that the
certificate presented by the client during the handshake is signed by certificate presented by the client during the handshake is signed by
skipping to change at page 15, line 43 skipping to change at page 15, line 43
6.5. TLS Termination 6.5. TLS Termination
An authorization server or resource server MAY choose to terminate An authorization server or resource server MAY choose to terminate
TLS connections at a load balancer, reverse proxy, or other network TLS connections at a load balancer, reverse proxy, or other network
intermediary. How the client certificate metadata is securely intermediary. How the client certificate metadata is securely
communicated between the intermediary and the application server in communicated between the intermediary and the application server in
this case is out of scope of this specification. this case is out of scope of this specification.
7. Security Considerations 7. Security Considerations
7.1. Certificate Thumbprint Binding 7.1. Certificate-Bound Refresh Tokens
The OAuth 2.0 Authorization Framework [RFC6749] requires that an
authorization server bind refresh tokens to the client to which they
where issued and that confidential clients (those having established
authentication credentials with the authorization server)
authenticate to the AS when presenting a refresh token. As a result,
refresh tokens are indirectly certificate-bound when issued to
clients utilizing the "tls_client_auth" or
"self_signed_tls_client_auth" methods of client authentication.
Section 4 describes certificate-bound refresh tokens issued to public
clients (those without authentication credentials associated with the
"client_id").
7.2. Certificate Thumbprint Binding
The binding between the certificate and access token specified in The binding between the certificate and access token specified in
Section 3.1 uses a cryptographic hash of the certificate. It relies Section 3.1 uses a cryptographic hash of the certificate. It relies
on the hash function having sufficient preimage and second-preimage on the hash function having sufficient preimage and second-preimage
resistance so as to make it computationally infeasible to find or resistance so as to make it computationally infeasible to find or
create another certificate that produces to the same hash output create another certificate that produces to the same hash output
value. The SHA-256 hash function was used because it meets the value. The SHA-256 hash function was used because it meets the
aforementioned requirement while being widely available. If, in the aforementioned requirement while being widely available. If, in the
future, certificate thumbprints need to be computed using hash future, certificate thumbprints need to be computed using hash
function(s) other than SHA-256, it is suggested that additional function(s) other than SHA-256, it is suggested that additional
related JWT confirmation methods members be defined for that purpose related JWT confirmation methods members be defined for that purpose
and registered in the the IANA "JWT Confirmation Methods" registry and registered in the the IANA "JWT Confirmation Methods" registry
[IANA.JWT.Claims] for JWT "cnf" member values. [IANA.JWT.Claims] for JWT "cnf" member values.
7.2. TLS Versions and Best Practices 7.3. TLS Versions and Best Practices
In the abstract this document is applicable with any TLS version In the abstract this document is applicable with any TLS version
supporting certificate-based client authentication. Both TLS 1.3 supporting certificate-based client authentication. Both TLS 1.3
[RFC8446] and TLS 1.2 [RFC5246] are cited herein because, at the time [RFC8446] and TLS 1.2 [RFC5246] are cited herein because, at the time
of writing, 1.3 is the newest version while 1.2 is the most widely of writing, 1.3 is the newest version while 1.2 is the most widely
deployed. General implementation and security considerations for deployed. General implementation and security considerations for
TLS, including version recommendations, can be found in [BCP195]. TLS, including version recommendations, can be found in [BCP195].
7.3. X.509 Certificate Spoofing 7.4. X.509 Certificate Spoofing
If the PKI method of client authentication is used, an attacker could If the PKI method of client authentication is used, an attacker could
try to impersonate a client using a certificate with the same subject try to impersonate a client using a certificate with the same subject
(DN or SAN) but issued by a different CA, which the authorization (DN or SAN) but issued by a different CA, which the authorization
server trusts. To cope with that threat, the authorization server server trusts. To cope with that threat, the authorization server
SHOULD only accept as trust anchors a limited number of CAs whose SHOULD only accept as trust anchors a limited number of CAs whose
certificate issuance policy meets its security requirements. There certificate issuance policy meets its security requirements. There
is an assumption then that the client and server agree on the set of is an assumption then that the client and server agree on the set of
trust anchors that the server uses to create and validate the trust anchors that the server uses to create and validate the
certificate chain. Without this assumption the use of a subject to certificate chain. Without this assumption the use of a subject to
identify the client certificate would open the server up to identify the client certificate would open the server up to
certificate spoofing attacks. certificate spoofing attacks.
7.4. X.509 Certificate Parsing and Validation Complexity 7.5. X.509 Certificate Parsing and Validation Complexity
Parsing and validation of X.509 certificates and certificate chains Parsing and validation of X.509 certificates and certificate chains
is complex and implementation mistakes have previously exposed is complex and implementation mistakes have previously exposed
security vulnerabilities. Complexities of validation include (but security vulnerabilities. Complexities of validation include (but
are not limited to) [CX5P] [DCW] [RFC5280]: are not limited to) [CX5P] [DCW] [RFC5280]:
o checking of Basic Constraints, basic and extended Key Usage o checking of Basic Constraints, basic and extended Key Usage
constraints, validity periods, and critical extensions; constraints, validity periods, and critical extensions;
o handling of null-terminator bytes and non-canonical string o handling of null-terminator bytes and non-canonical string
skipping to change at page 24, line 15 skipping to change at page 24, line 32
Token Binding uses bare keys that are generated on the client, which Token Binding uses bare keys that are generated on the client, which
avoids many of the difficulties of creating, distributing, and avoids many of the difficulties of creating, distributing, and
managing certificates used in this specification. However, at the managing certificates used in this specification. However, at the
time of writing, Token Binding is fairly new and there is relatively time of writing, Token Binding is fairly new and there is relatively
little support for it in available application development platforms little support for it in available application development platforms
and tooling. Until better support for the underlying core Token and tooling. Until better support for the underlying core Token
Binding specifications exists, practical implementations of OAuth 2.0 Binding specifications exists, practical implementations of OAuth 2.0
Token Binding are infeasible. Mutual TLS, on the other hand, has Token Binding are infeasible. Mutual TLS, on the other hand, has
been around for some time and enjoys widespread support in web been around for some time and enjoys widespread support in web
servers and development platforms. As a consequence, OAuth 2.0 servers and development platforms. As a consequence, OAuth 2.0
Mutual TLS Client Authentication and Certificate Bound Access Tokens Mutual TLS Client Authentication and Certificate-Bound Access Tokens
can be built and deployed now using existing platforms and tools. In can be built and deployed now using existing platforms and tools. In
the future, the two specifications are likely to be deployed in the future, the two specifications are likely to be deployed in
parallel for solving similar problems in different environments. parallel for solving similar problems in different environments.
Authorization servers may even support both specifications Authorization servers may even support both specifications
simultaneously using different proof-of-possession mechanisms for simultaneously using different proof-of-possession mechanisms for
tokens issued to different clients. tokens issued to different clients.
Appendix C. Acknowledgements Appendix C. 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, which predates this document. authentication implementation, which predates this document.
Experience and learning from that work informed some of the content Experience and learning from that work informed some of the content
of this document. of this document.
This specification was developed within the OAuth Working Group under This specification was developed within the OAuth Working Group under
the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
Eric Rescorla and Benjamin Kaduk serving as Security Area Directors. Eric Rescorla and Benjamin Kaduk serving as Security Area Directors.
Additionally, the following individuals contributed ideas, feedback, Additionally, the following individuals contributed ideas, feedback,
and wording that helped shape this specification: Sergey Beryozkin, and wording that helped shape this specification: Vittorio Bertocci,
Ralph Bragg, Sophie Bremer, Vladimir Dzhuvinov, Samuel Erdtman, Evan Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Vladimir Dzhuvinov,
Gilman, Leif Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Samuel Erdtman, Evan Gilman, Leif Johansson, Michael Jones, Phil
Takahiko Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Leonard, Kepeng Li,
Manger, Jim Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Neil Madden, James Manger, Jim Manico, Nov Matake, Sascha Preibisch,
Justin Richer, Filip Skokan, Dave Tonge, and Hannes Tschofenig. Eric Rescorla, Justin Richer, Filip Skokan, Dave Tonge, and Hannes
Tschofenig.
Appendix D. Document(s) History Appendix D. 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-14
o Editorial clarifications around there being only a single subject
registered/configured per client for the tls_client_auth method.
o Add a brief explanation about how, with tls_client_auth and
self_signed_tls_client_auth, refresh tokens are certificate-bound
indirectly via the client authentication.
o Add mention of refresh tokens in the abstract.
draft-ietf-oauth-mtls-13 draft-ietf-oauth-mtls-13
o Add an abstract protocol flow and diagram to serve as an overview o Add an abstract protocol flow and diagram to serve as an overview
of OAuth in general and baseline to describe the various ways in of OAuth in general and baseline to describe the various ways in
which the mechanisms defined herein are intended to be used. which the mechanisms defined herein are intended to be used.
o A little bit less of that German influence. o A little bit less of that German influence.
o Rework the TLS references a bit and, in the Terminology section, o Rework the TLS references a bit and, in the Terminology section,
clean up the description of what messages are sent and verified in clean up the description of what messages are sent and verified in
the handshake to do 'mutual TLS'. the handshake to do 'mutual TLS'.
o Move the explanation about "cnf" introspection registration into o Move the explanation about "cnf" introspection registration into
the IANA Considerations. the IANA Considerations.
o Add CIBA as an informational reference and additional example of o Add CIBA as an informational reference and additional example of
an OAuth extension that defines an endpoint that utilizes client an OAuth extension that defines an endpoint that utilizes client
authentication. authentication.
o Shorten a few of the section titles. o Shorten a few of the section titles.
o Add new client metadata values to allow for the use of a SAN in o Add new client metadata values to allow for the use of a SAN in
skipping to change at page 25, line 19 skipping to change at page 25, line 44
the IANA Considerations. the IANA Considerations.
o Add CIBA as an informational reference and additional example of o Add CIBA as an informational reference and additional example of
an OAuth extension that defines an endpoint that utilizes client an OAuth extension that defines an endpoint that utilizes client
authentication. authentication.
o Shorten a few of the section titles. o Shorten a few of the section titles.
o Add new client metadata values to allow for the use of a SAN in o Add new client metadata values to allow for the use of a SAN in
the PKI MTLS client authentication method. the PKI MTLS client authentication method.
o Add privacy considerations attempting to discuss the implications o Add privacy considerations attempting to discuss the implications
of the client cert being sent in the clear in TLS 1.2. of the client cert being sent in the clear in TLS 1.2.
o Changed the 'Certificate Bound Access Tokens Without Client o Changed the 'Certificate Bound Access Tokens Without Client
Authentication' section to 'Public Clients and Certificate Bound Authentication' section to 'Public Clients and Certificate-Bound
Tokens' and moved it up to be a top level section while adding Tokens' and moved it up to be a top level section while adding
discussion of binding refresh tokens for public clients. discussion of binding refresh tokens for public clients.
o Reword/restructure the main PKI method section somewhat to o Reword/restructure the main PKI method section somewhat to
(hopefully) improve readability. (hopefully) improve readability.
o Reword/restructure the Self-Signed method section a bit to o Reword/restructure the Self-Signed method section a bit to
(hopefully) make it more comprehensible. (hopefully) make it more comprehensible.
o Reword the AS and RS Implementation Considerations somewhat to o Reword the AS and RS Implementation Considerations somewhat to
(hopefully) improve readability. (hopefully) improve readability.
o Clarify that the protected protected resource obtains the client o Clarify that the protected resource obtains the client certificate
certificate used for mutual TLS from its TLS implementation layer. used for mutual TLS from its TLS implementation layer.
o Add Security Considerations section about the certificate o Add Security Considerations section about the certificate
thumbprint binding that includes the hash algorithm agility thumbprint binding that includes the hash algorithm agility
recommendation. recommendation.
o Add an "mtls_endpoint_aliases" AS metadata parameter that is a o Add an "mtls_endpoint_aliases" AS metadata parameter that is a
JSON object containing alternative authorization server endpoints, JSON object containing alternative authorization server endpoints,
which a client intending to do mutual TLS will use in preference which a client intending to do mutual TLS will use in preference
to the conventional endpoints. to the conventional endpoints.
o Minor editorial updates. o Minor editorial updates.
draft-ietf-oauth-mtls-12 draft-ietf-oauth-mtls-12
 End of changes. 27 change blocks. 
56 lines changed or deleted 82 lines changed or added

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