--- 1/draft-ietf-oauth-mtls-15.txt 2019-08-13 04:14:23.537092811 -0700 +++ 2/draft-ietf-oauth-mtls-16.txt 2019-08-13 04:14:23.721097475 -0700 @@ -1,24 +1,24 @@ OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley -Expires: January 4, 2020 Yubico +Expires: February 14, 2020 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES.com AG - July 3, 2019 + August 13, 2019 OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens - draft-ietf-oauth-mtls-15 + draft-ietf-oauth-mtls-16 Abstract This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a 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 @@ -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 4, 2020. + This Internet-Draft will expire on February 14, 2020. Copyright Notice Copyright (c) 2019 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 @@ -702,21 +702,21 @@ intermediary. How the client certificate metadata is securely communicated between the intermediary and the application server in this case is out of scope of this specification. 7. Security Considerations 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 + were 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 @@ -1144,27 +1144,31 @@ This specification was developed within the OAuth Working Group under the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security Area Directors. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification: Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer, - Filip Skokan, Dave Tonge, and Hannes Tschofenig. + Vincent Roca, Filip Skokan, Dave Tonge, and Hannes Tschofenig. Appendix D. Document(s) History [[ to be removed by the RFC Editor before publication as an RFC ]] + draft-ietf-oauth-mtls-16 + o Editorial updates from last call review. + draft-ietf-oauth-mtls-15 + o Editorial updates from second AD review. 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. @@ -1241,25 +1246,29 @@ o Add a new security considerations section on X.509 parsing and validation per WGLC feedback from Neil Madden and Benjamin Kaduk o Note that a server can terminate TLS at a load balancer, reverse proxy, etc. but how the client certificate metadata is securely communicated to the backend is out of scope per WGLC feedback o Note that revocation checking is at the discretion of the AS per WGLC feedback o Editorial updates and clarifications o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- oauth-token-binding to -06 + o Add folks involved in WGLC feedback to the acknowledgements list draft-ietf-oauth-mtls-07 o Update to use the boilerplate from RFC 8174 + + draft-ietf-oauth-mtls-06 + o Add an appendix section describing the relationship of this document to OAuth Token Binding as requested during 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 @@ -1331,29 +1341,30 @@ o Specify that tls_client_auth_subject_dn and tls_client_auth_root_dn are RFC 4514 String Representation of Distinguished Names. 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 hash of the cert. o Changed the abbreviated title to 'OAuth Mutual TLS' (previously was the acronym MTLSPOC). 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.