--- 1/draft-ietf-oauth-mtls-10.txt 2018-08-30 11:13:10.822716091 -0700 +++ 2/draft-ietf-oauth-mtls-11.txt 2018-08-30 11:13:10.866717155 -0700 @@ -1,31 +1,31 @@ OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley -Expires: January 18, 2019 Yubico +Expires: March 3, 2019 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES Europe AG - July 17, 2018 + August 30, 2018 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens - draft-ietf-oauth-mtls-10 + draft-ietf-oauth-mtls-11 Abstract This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) 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 infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 18, 2019. + This Internet-Draft will expire on March 3, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -90,44 +90,44 @@ 5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12 5.3. X.509 Certificate Parsing and Validation Complexity . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13 6.2. OAuth Authorization Server Metadata Registration . . . . 13 6.3. Token Endpoint Authentication Method Registration . . . . 13 6.4. OAuth Token Introspection Response Registration . . . . . 14 6.5. OAuth Dynamic Client Registration Metadata Registration . 14 7. 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 B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix C. Document(s) History . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction This document describes OAuth client authentication and certificate bound access tokens using mutual TLS [RFC5246] authentication with 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 tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The OAuth 2.0 Authorization Framework [RFC6749] defines a shared - secret method of client authentication but also allows for the - definition and use of additional client authentication mechanisms - when interacting directly with the authorization server. This - document describes an additional mechanism of client authentication - utilizing mutual TLS certificate-based authentication, which provides - better security characteristics than shared secrets. While [RFC6749] + secret method of client authentication but also allows for definition + and use of additional client authentication mechanisms when + interacting directly with the authorization server. This document + describes an additional mechanism of client authentication utilizing + mutual TLS certificate-based authentication, which provides better + security characteristics than shared secrets. While [RFC6749] documents client authentication for requests to the token endpoint, extensions to OAuth 2.0 (such as Introspection [RFC7662] and Revocation [RFC7009]) define endpoints that also utilize client authentication and the mutual TLS methods defined herein are applicable to those endpoints as well. Mutual TLS certificate bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. Such a constraint is sometimes referred to as key confirmation, proof-of- @@ -222,22 +222,22 @@ a certificate to a client. 2.1.2. Client Registration Metadata The following metadata parameter is introduced for the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] in support of the PKI method of binding a certificate to a client: tls_client_auth_subject_dn An [RFC4514] string representation of the expected subject - distinguished name of the certificate the OAuth client will use in - mutual TLS authentication. + distinguished name of the certificate, which the OAuth client will + use in mutual TLS authentication. 2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method This method of mutual TLS OAuth client authentication is intended to support client authentication using self-signed certificates. As pre-requisite, the client registers an X.509 certificate or a trusted source for its X.509 certificates (such as the "jwks_uri" defined in [RFC7591] that references a JSON Web Key [RFC7517] Set containing the client's certificates and public keys) with the authorization server. @@ -518,21 +518,22 @@ communicated between the intermediary and the application server in this case is out of scope of this specification. 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 + certificate-based client authentication, including the relatively + recently published TLS 1.3 [RFC8446]. 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 @@ -743,20 +745,24 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + [X509Pitfalls] Wong, D., "Common x509 certificate validation/creation pitfalls", September 2016, . 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 @@ -794,30 +800,36 @@ Appendix B. Acknowledgements Scott "not Tomlinson" Tomilson and Matt Peterson were involved in design and development work on a mutual TLS OAuth client authentication implementation, which predates this document. Experience and learning from that work informed some of the content of this document. Additionally, the authors would like to thank the following people for their input and contributions to the specification: Sergey - Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, - Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean - Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov - Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes - Tschofenig. + Beryozkin, Sophie Bremer, Vladimir Dzhuvinov, Samuel Erdtman, Leif + Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko + Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim + Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and + Hannes Tschofenig. Appendix C. Document(s) History [[ 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 o Update draft-ietf-oauth-discovery reference to RFC8414 draft-ietf-oauth-mtls-09 o Change "single certificates" to "self-signed certificates" in the Abstract draft-ietf-oauth-mtls-08 @@ -933,20 +949,22 @@ draft-ietf-oauth-mtls-00 o Created the initial working group version from draft-campbell- oauth-mtls draft-campbell-oauth-mtls-01 o Fix some typos. o Add to the acknowledgements list. + draft-campbell-oauth-mtls-00 + o Add a Mutual TLS sender constrained protected resource access method and a x5t#S256 cnf method for JWT access tokens (concepts taken in part from draft-sakimura-oauth-jpop-04). o Fixed "token_endpoint_auth_methods_supported" to "token_endpoint_auth_method" for client metadata. o Add "tls_client_auth_subject_dn" and "tls_client_auth_issuer_dn" client metadata parameters and mention using "jwks_uri" or "jwks". o Say that the authentication method is determined by client policy regardless of whether the client was dynamically registered or statically configured.