draft-ietf-oauth-mtls-10.txt   draft-ietf-oauth-mtls-11.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: January 18, 2019 Yubico Expires: March 3, 2019 Yubico
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES Europe AG YES Europe AG
July 17, 2018 August 30, 2018
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
Tokens Tokens
draft-ietf-oauth-mtls-10 draft-ietf-oauth-mtls-11
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 tokens using mutual Transport Layer Security (TLS)
authentication with X.509 certificates. OAuth clients are provided a authentication with X.509 certificates. OAuth clients are provided a
mechanism for authentication to the authorization sever using mutual mechanism for authentication to the authorization server using mutual
TLS, based on either self-signed certificates or public key TLS, based on either self-signed certificates or public key
infrastructure (PKI). OAuth authorization servers are provided a 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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 January 18, 2019. This Internet-Draft will expire on March 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12 5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12
5.3. X.509 Certificate Parsing and Validation Complexity . . . 12 5.3. X.509 Certificate Parsing and Validation Complexity . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13 6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13
6.2. OAuth Authorization Server Metadata Registration . . . . 13 6.2. OAuth Authorization Server Metadata Registration . . . . 13
6.3. Token Endpoint Authentication Method Registration . . . . 13 6.3. Token Endpoint Authentication Method Registration . . . . 13
6.4. OAuth Token Introspection Response Registration . . . . . 14 6.4. OAuth Token Introspection Response Registration . . . . . 14
6.5. OAuth Dynamic Client Registration Metadata Registration . 14 6.5. OAuth Dynamic Client Registration Metadata Registration . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Relationship to Token Binding . . . . . . . . . . . 17 Appendix A. Relationship to Token Binding . . . . . . . . . . . 17
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Appendix C. Document(s) History . . . . . . . . . . . . . . . . 18 Appendix C. Document(s) History . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This document describes OAuth client authentication and certificate This document describes OAuth client authentication and certificate
bound access tokens using mutual TLS [RFC5246] authentication with bound access tokens using mutual TLS [RFC5246] authentication with
X.509 certificates. OAuth clients are provided mechanisms for X.509 certificates. OAuth clients are provided mechanisms for
authentication to the authorization sever using mutual TLS. OAuth authentication to the authorization server using mutual TLS. OAuth
authorization servers are provided a mechanism for binding access authorization servers are provided a mechanism for binding access
tokens to a client's mutual TLS certificate, and OAuth protected tokens to a client's mutual TLS certificate, and OAuth protected
resources are provided a method for ensuring that such an access resources are provided a method for ensuring that such an access
token presented to it was issued to the client presenting the token. token presented to it was issued to the client presenting the token.
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 definition
definition and use of additional client authentication mechanisms and use of additional client authentication mechanisms when
when interacting directly with the authorization server. This interacting directly with the authorization server. This document
document describes an additional mechanism of client authentication describes an additional mechanism of client authentication utilizing
utilizing mutual TLS certificate-based authentication, which provides mutual TLS certificate-based authentication, which provides better
better security characteristics than shared secrets. While [RFC6749] security characteristics than shared secrets. While [RFC6749]
documents client authentication for requests to the token endpoint, documents client authentication for requests to the token endpoint,
extensions to OAuth 2.0 (such as Introspection [RFC7662] and extensions to OAuth 2.0 (such as Introspection [RFC7662] and
Revocation [RFC7009]) define endpoints that also utilize client Revocation [RFC7009]) define endpoints that also utilize client
authentication and the mutual TLS methods defined herein are authentication and the mutual TLS methods defined herein are
applicable to those endpoints as well. applicable to those endpoints as well.
Mutual TLS certificate bound access tokens ensure that only the party Mutual TLS certificate bound access tokens ensure that only the party
in possession of the private key corresponding to the certificate can in possession of the private key corresponding to the certificate can
utilize the token to access the associated resources. Such a utilize the token to access the associated resources. Such a
constraint is sometimes referred to as key confirmation, proof-of- constraint is sometimes referred to as key confirmation, proof-of-
skipping to change at page 5, line 47 skipping to change at page 5, line 47
a certificate to a client. a certificate to a client.
2.1.2. Client Registration Metadata 2.1.2. Client Registration Metadata
The following metadata parameter is introduced for the OAuth 2.0 The following metadata parameter is introduced for the OAuth 2.0
Dynamic Client Registration Protocol [RFC7591] in support of the PKI Dynamic Client Registration Protocol [RFC7591] in support of the PKI
method of binding a certificate to a client: method of binding a certificate to a client:
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, which the OAuth client will
mutual TLS authentication. use in 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 an 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" defined in source for its X.509 certificates (such as the "jwks_uri" defined in
[RFC7591] that references a JSON Web Key [RFC7517] Set containing the [RFC7591] that references a JSON Web Key [RFC7517] Set containing the
client's certificates and public keys) with the authorization server. client's certificates and public keys) with the authorization server.
skipping to change at page 12, line 20 skipping to change at page 12, line 20
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.
5. Security Considerations 5. Security Considerations
5.1. TLS Versions and Best Practices 5.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 the latest version that is widely deployed. However, writing, it is the latest version that is widely deployed. However,
this 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, including the relatively
recently published TLS 1.3 [RFC8446]. 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].
5.2. X.509 Certificate Spoofing 5.2. 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 but issued by a different CA, which the authorization server DN but issued by a different CA, which the authorization server
trusts. To cope with that threat, the authorization server should trusts. To cope with that threat, the authorization server should
skipping to change at page 17, line 5 skipping to change at page 17, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[X509Pitfalls] [X509Pitfalls]
Wong, D., "Common x509 certificate validation/creation Wong, D., "Common x509 certificate validation/creation
pitfalls", September 2016, pitfalls", September 2016,
<https://www.cryptologie.net/article/374/ <https://www.cryptologie.net/article/374/
common-x509-certificate-validationcreation-pitfalls>. common-x509-certificate-validationcreation-pitfalls>.
Appendix A. Relationship to Token Binding Appendix A. Relationship to Token Binding
OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the
application of Token Binding to the various artifacts and tokens application of Token Binding to the various artifacts and tokens
skipping to change at page 18, line 7 skipping to change at page 18, line 20
Appendix B. Acknowledgements 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, 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.
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, Leif Johansson, Beryozkin, Sophie Bremer, Vladimir Dzhuvinov, Samuel Erdtman, Leif
Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko
Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, 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 C. 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-11
o Editorial updates.
o Mention/reference TLS 1.3 RFC8446 in the TLS Versions and Best
Practices section.
draft-ietf-oauth-mtls-10 draft-ietf-oauth-mtls-10
o Update draft-ietf-oauth-discovery reference to RFC8414 o Update draft-ietf-oauth-discovery reference to RFC8414
draft-ietf-oauth-mtls-09 draft-ietf-oauth-mtls-09
o Change "single certificates" to "self-signed certificates" in the o Change "single certificates" to "self-signed certificates" in the
Abstract Abstract
draft-ietf-oauth-mtls-08 draft-ietf-oauth-mtls-08
skipping to change at page 21, line 5 skipping to change at page 21, line 26
draft-ietf-oauth-mtls-00 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
o Add a Mutual TLS sender constrained protected resource access o Add a Mutual TLS sender constrained protected resource access
method and a x5t#S256 cnf method for JWT access tokens (concepts method and a x5t#S256 cnf method for JWT access tokens (concepts
taken in part from draft-sakimura-oauth-jpop-04). taken in part from draft-sakimura-oauth-jpop-04).
o Fixed "token_endpoint_auth_methods_supported" to o Fixed "token_endpoint_auth_methods_supported" to
"token_endpoint_auth_method" for client metadata. "token_endpoint_auth_method" for client metadata.
o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn"
client metadata parameters and mention using "jwks_uri" or "jwks". client metadata parameters and mention using "jwks_uri" or "jwks".
o Say that the authentication method is determined by client policy o Say that the authentication method is determined by client policy
regardless of whether the client was dynamically registered or regardless of whether the client was dynamically registered or
statically configured. statically configured.
 End of changes. 15 change blocks. 
22 lines changed or deleted 35 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/