draft-ietf-oauth-mtls-05.txt   draft-ietf-oauth-mtls-06.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: May 16, 2018 Yubico Expires: July 19, 2018 Yubico
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES Europe AG YES Europe AG
November 12, 2017 January 15, 2018
Mutual TLS Profile for OAuth 2.0 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
draft-ietf-oauth-mtls-05 Tokens
draft-ietf-oauth-mtls-06
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 as a method for a
protected resource to ensure that an access token presented to it by
a given client was issued to that client by the authorization server.
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 May 16, 2018. This Internet-Draft will expire on July 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4 2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4
2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 4 2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 5
2.1.1. PKI Authentication Method Metadata Value . . . . . . 5 2.1.1. PKI Authentication Method Metadata Value . . . . . . 5
2.1.2. Client Registration Metadata . . . . . . . . . . . . 5 2.1.2. Client Registration Metadata . . . . . . . . . . . . 5
2.2. Self-Signed Certificate Mutual TLS OAuth Client 2.2. Self-Signed Certificate Mutual TLS OAuth Client
Authentication Method . . . . . . . . . . . . . . . . . . 5 Authentication Method . . . . . . . . . . . . . . . . . . 6
2.2.1. Self-Signed Certificate Authentication Method 2.2.1. Self-Signed Certificate Authentication Method
Metadata Value . . . . . . . . . . . . . . . . . . . 6 Metadata Value . . . . . . . . . . . . . . . . . . . 6
2.2.2. Client Registration Metadata . . . . . . . . . . . . 6 2.2.2. Client Registration Metadata . . . . . . . . . . . . 6
3. Mutual TLS Sender Constrained Resources Access . . . . . . . 6 3. Mutual TLS Sender Constrained Resources Access . . . . . . . 7
3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7 3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7
3.2. Confirmation Method for Token Introspection . . . . . . . 8 3.2. Confirmation Method for Token Introspection . . . . . . . 8
3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9 3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9
3.4. Client Registration Metadata . . . . . . . . . . . . . . 9 3.4. Client Registration Metadata . . . . . . . . . . . . . . 9
4. Implementation Considerations . . . . . . . . . . . . . . . . 10 4. Implementation Considerations . . . . . . . . . . . . . . . . 10
4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10 4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10
4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10 4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10
4.3. Sender Constrained Access Tokens Without Client 4.3. Sender Constrained Access Tokens Without Client
Authentication . . . . . . . . . . . . . . . . . . . . . 10 Authentication . . . . . . . . . . . . . . . . . . . . . 10
4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11 4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.5. Implicit Grant Unsupported . . . . . . . . . . . . . . . 11
5.1. JWT Confirmation Methods Registration . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.2. OAuth Authorization Server Metadata Registration . . . . 11 5.1. TLS Versions and Best Practices . . . . . . . . . . . . . 11
5.3. Token Endpoint Authentication Method Registration . . . . 12 5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12
5.4. OAuth Token Introspection Response Registration . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.5. OAuth Dynamic Client Registration Metadata Registration . 12 6.1. JWT Confirmation Methods Registration . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.2. OAuth Authorization Server Metadata Registration . . . . 12
6.1. TLS Versions and Best Practices . . . . . . . . . . . . . 13 6.3. Token Endpoint Authentication Method Registration . . . . 12
6.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 13 6.4. OAuth Token Introspection Response Registration . . . . . 13
6.5. OAuth Dynamic Client Registration Metadata Registration . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Relationship to Token Binding . . . . . . . . . . . 16
Appendix B. Document(s) History . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix C. Document(s) History . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
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
sender constrained access to OAuth protected resources. sender constrained access to OAuth protected resources.
The OAuth 2.0 Authorization Framework [RFC6749] defines a shared The OAuth 2.0 Authorization Framework [RFC6749] defines a shared
secret method of client authentication but also allows for the secret method of client authentication but also allows for the
skipping to change at page 6, line 37 skipping to change at page 6, line 51
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
will occur using mutual TLS with the client utilizing a self- will occur using mutual TLS with the client utilizing a self-
signed certificate. signed certificate.
2.2.2. Client Registration Metadata 2.2.2. Client Registration Metadata
For the Self-Signed Certificate method of binding a certificate to a For the Self-Signed Certificate method of binding a certificate to a
client using mutual TLS client authentication, the existing client using mutual TLS client authentication, the existing
"jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
convey client's certificates and public keys, where the X.509 convey the client's certificates and public keys, where the X.509
certificates are represented using the JSON Web Key (JWK) [RFC7517] certificates are represented using the JSON Web Key (JWK) [RFC7517]
"x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key "x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key
in the first certificate of the "x5c" parameter must match the public in the first certificate of the "x5c" parameter must match the public
key represented by other members of the JWK). key represented by other members of the JWK).
3. Mutual TLS Sender Constrained Resources Access 3. Mutual TLS Sender Constrained Resources Access
When mutual TLS is used at the token endpoint, the authorization When mutual TLS is used by the client on the connection to the token
server is able to bind the issued access token to the client endpoint, the authorization server is able to bind the issued access
certificate. Such a binding is accomplished by associating the token to the client certificate. Such a binding is accomplished by
certificate with the token in a way that can be accessed by the associating the certificate with the token in a way that can be
protected resource, such as embedding the certificate hash in the accessed by the protected resource, such as embedding the certificate
issued access token directly, using the syntax described in hash in the issued access token directly, using the syntax described
Section 3.1, or through token introspection as described in in Section 3.1, or through token introspection as described in
Section 3.2. Other methods of associating a certificate with an Section 3.2. Other methods of associating a certificate with an
access token are possible, per agreement by the authorization server access token are possible, per agreement by the authorization server
and the protected resource, but are beyond the scope of this and the protected resource, but are beyond the scope of this
specification. specification.
The client makes protected resource requests as described in The client makes protected resource requests as described in
[RFC6750], however, those requests MUST be made over a mutually [RFC6750], however, those requests MUST be made over a mutually
authenticated TLS connection using the same certificate that was used authenticated TLS connection using the same certificate that was used
for mutual TLS at the token endpoint. for mutual TLS at the token endpoint.
skipping to change at page 11, line 23 skipping to change at page 11, line 24
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.
5. IANA Considerations 4.5. Implicit Grant Unsupported
5.1. JWT Confirmation Methods Registration This document describes binding an access token to the client
certificate presented on the TLS connection from the client to the
authorization server's token endpoint, however, certificate binding
of access tokens issued directly from the authorization endpoint via
the implicit grant flow is explicitly out of scope. End users
interact directly with the authorization endpoint using a web browser
and the use of client certificates in user's browsers bring
operational and usability issues, which make it undesirable to
support certificate bound access tokens issued in the implicit grant
flow. Implementations wanting to employ certificate bound sender
constrained access tokens should utilize grant types that involve the
client making an access token request directly to the token endpoint
(e.g. the authorization code and refresh token grant types).
5. Security Considerations
5.1. TLS Versions and Best Practices
TLS 1.2 [RFC5246] is cited in this document because, at the time of
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].
5.2. X.509 Certificate Spoofing
If the PKI method of client authentication is used, an attacker could
try to impersonate a client using a certificate with the same subject
DN but issued by a different CA, which the authorization server
trusts. To cope with that threat, the authorization server should
only accept as trust anchors a limited number of CAs whose
certificate issuance policy meets its security requirements. There
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
certificate chain. Without this assumption the use of a Subject DN
to identify the client certificate would open the server up to
certificate spoofing attacks.
6. IANA Considerations
6.1. JWT Confirmation Methods Registration
This specification requests registration of the following value in This specification requests registration of the following value in
the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for
JWT "cnf" member values established by [RFC7800]. JWT "cnf" member values established by [RFC7800].
o Confirmation Method Value: "x5t#S256" o Confirmation Method Value: "x5t#S256"
o Confirmation Method Description: X.509 Certificate SHA-256 o Confirmation Method Description: X.509 Certificate SHA-256
Thumbprint Thumbprint
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.1 of [[ this specification ]] o Specification Document(s): Section 3.1 of [[ this specification ]]
5.2. OAuth Authorization Server Metadata Registration 6.2. OAuth Authorization Server Metadata Registration
This specification requests registration of the following value in This specification requests registration of the following value in
the IANA "OAuth Authorization Server Metadata" registry the IANA "OAuth Authorization Server Metadata" registry
[IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery]. [IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery].
o Metadata Name: "mutual_tls_sender_constrained_access_tokens" o Metadata Name: "mutual_tls_sender_constrained_access_tokens"
o Metadata Description: Indicates authorization server support for o Metadata Description: Indicates authorization server support for
mutual TLS sender constrained access tokens. mutual TLS sender constrained access tokens.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.3 of [[ this specification ]] o Specification Document(s): Section 3.3 of [[ this specification ]]
5.3. Token Endpoint Authentication Method Registration 6.3. Token Endpoint Authentication Method Registration
This specification requests registration of the following value in This specification requests registration of the following value in
the IANA "OAuth Token Endpoint Authentication Methods" registry the IANA "OAuth Token Endpoint Authentication Methods" registry
[IANA.OAuth.Parameters] established by [RFC7591]. [IANA.OAuth.Parameters] established by [RFC7591].
o Token Endpoint Authentication Method Name: "tls_client_auth" o Token Endpoint Authentication Method Name: "tls_client_auth"
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.1 of [[ this specification o Specification Document(s): Section 2.1.1 of [[ this specification
]] ]]
o Token Endpoint Authentication Method Name: o Token Endpoint Authentication Method Name:
"self_signed_tls_client_auth" "self_signed_tls_client_auth"
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2.1 of [[ this specification o Specification Document(s): Section 2.2.1 of [[ this specification
]] ]]
5.4. OAuth Token Introspection Response Registration 6.4. OAuth Token Introspection Response Registration
This specification requests registration of the following value in This specification requests registration of the following value in
the IANA "OAuth Token Introspection Response" registry the IANA "OAuth Token Introspection Response" registry
[IANA.OAuth.Parameters] established by [RFC7662]. [IANA.OAuth.Parameters] established by [RFC7662].
o Claim Name: "cnf" o Claim Name: "cnf"
o Claim Description: Confirmation o Claim Description: Confirmation
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.2 of [[ this specification ]] o Specification Document(s): Section 3.2 of [[ this specification ]]
5.5. OAuth Dynamic Client Registration Metadata Registration 6.5. OAuth Dynamic Client Registration Metadata Registration
This specification requests registration of the following client This specification requests registration of the following client
metadata definitions in the IANA "OAuth Dynamic Client Registration metadata definitions in the IANA "OAuth Dynamic Client Registration
Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:
o Client Metadata Name: o Client Metadata Name:
"mutual_tls_sender_constrained_access_tokens" "mutual_tls_sender_constrained_access_tokens"
o Client Metadata Description: Indicates the client's intention to o Client Metadata Description: Indicates the client's intention to
use mutual TLS sender constrained access tokens. use mutual TLS sender constrained access tokens.
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.4 of [[ this specification ]] o Specification Document(s): Section 3.4 of [[ this specification ]]
o Client Metadata Name: "tls_client_auth_subject_dn" o Client Metadata Name: "tls_client_auth_subject_dn"
o Client Metadata Description: String value specifying the expected o Client Metadata Description: String value specifying the expected
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.1. TLS Versions and Best Practices
TLS 1.2 [RFC5246] is cited in this document because, at the time of
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
authorization server may decide to only accept a limited number of
CAs whose certificate issuance policy meets its security
requirements.
7. References 7. References
7.1. Normative References 7.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/bcp195>. 2015, <http://www.rfc-editor.org/info/bcp195>.
skipping to change at page 14, line 35 skipping to change at page 15, line 10
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012, Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-oauth-discovery] [I-D.ietf-oauth-discovery]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth- Authorization Server Metadata", draft-ietf-oauth-
discovery-07 (work in progress), September 2017. discovery-08 (work in progress), November 2017.
[I-D.ietf-oauth-token-binding]
Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", draft-ietf-oauth-token-
binding-05 (work in progress), October 2017.
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[OpenID.Discovery] [OpenID.Discovery]
skipping to change at page 15, line 26 skipping to change at page 16, line 5
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015, RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>. <https://www.rfc-editor.org/info/rfc7591>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
Appendix A. Acknowledgements Appendix A. Relationship to Token Binding
OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the
application of Token Binding to the various artifacts and tokens
employed throughout OAuth. That includes binding of an access token
to a Token Binding key, which bears some similarities in motivation
and design to the mutual TLS sender constrained resources access
defined in this document. Both documents define what is often called
a proof-of-possession security mechanism for access tokens, whereby a
client must demonstrate possession of cryptographic keying material
when accessing a protected resource. The details differ somewhat
between the two documents but both have the authorization server bind
the access token it issues to an asymmetric key pair on the client.
The client then proves possession of the private key from that pair
on the TLS connection over which the protected resource is accessed.
The two documents then are effectively competing specifications, at
least with respect to the binding of access tokens. Token Binding
uses bare keys that are generated on the client, which avoids many of
the difficulties of creating, distributing, and managing certificates
and has the potential to see wider scale adoption and deployment.
However, at the time of writing, Token Binding is fairly new and
there is relatively little support for it in available application
development platforms and tooling. Until better support for the
underlying core Token Binding specifications exists, practical
implementations of OAuth 2.0 Token Binding are infeasible. Despite
its name, Token Binding doesn't have a monopoly on the binding of
tokens. Mutual TLS, on the other hand, has been around for some time
and enjoys widespread support in web servers and development
platforms. Mutual TLS for OAuth 2.0 can be built and deployed now
using existing platforms and tools. There are emerging and immediate
scenarios, such as OAuth enabled financial transactions motivated by
regulatory requirements in some cases, which demand the additional
security protections of proof-of-possession access tokens. This
document aspires to provide standardized and expeditious solution for
those scenarios.
Appendix B. 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, Takahiko Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, Phil
Kawasaki Sean Leonard, Kepeng Li, James Manger, Jim Manico, Nov Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim
Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and
Tschofenig. Hannes Tschofenig.
Appendix B. Document(s) History Appendix C. 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-06
o Add an appendix section describing the relationship of this
document to OAuth Token Binding as requested during the the
Singapore meeting https://datatracker.ietf.org/doc/minutes-
100-oauth/
o Add an explicit note that the implicit flow is not supported for
obtaining certificate bound access tokens as discussed at the
Singapore meeting https://datatracker.ietf.org/doc/minutes-
100-oauth/
o Add/incorporate text to the Security Considerations on Certificate
Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/
V26070X-6OtbVSeUz_7W2k94vCo
o Changed the title to be more descriptive
o Move the Security Considerations section to before the IANA
Considerations
o Elaborated on certificate bound access tokens a bit more in the
Abstract
o Update draft-ietf-oauth-discovery reference to -08
draft-ietf-oauth-mtls-05 draft-ietf-oauth-mtls-05
o Editorial fixes 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".
skipping to change at page 17, line 17 skipping to change at page 19, line 5
request for "cnf". request for "cnf".
o Specify that tls_client_auth_subject_dn and o Specify that tls_client_auth_subject_dn and
tls_client_auth_root_dn are RFC 4514 String Representation of tls_client_auth_root_dn are RFC 4514 String Representation of
Distinguished Names. Distinguished Names.
o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
o Changed the text in the Section 3 to not be specific about using a o Changed the text in the Section 3 to not be specific about using a
hash of the cert. hash of the cert.
o Changed the abbreviated title to 'OAuth Mutual TLS' (previously o Changed the abbreviated title to 'OAuth Mutual TLS' (previously
was the acronym MTLSPOC). was the acronym MTLSPOC).
draft-ietf-oauth-mtls-00
o Created the initial working group version from draft-campbell- o Created the initial working group version from draft-campbell-
oauth-mtls oauth-mtls
draft-campbell-oauth-mtls-01 draft-campbell-oauth-mtls-01
o Fix some typos. o Fix some typos.
o Add to the acknowledgements list. o Add to the acknowledgements list.
draft-campbell-oauth-mtls-00 draft-campbell-oauth-mtls-00
 End of changes. 27 change blocks. 
68 lines changed or deleted 154 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/