--- 1/draft-ietf-oauth-mtls-01.txt 2017-06-29 17:13:13.393436430 -0700 +++ 2/draft-ietf-oauth-mtls-02.txt 2017-06-29 17:13:13.421437101 -0700 @@ -1,22 +1,22 @@ OAuth Working Group B. Campbell Internet-Draft J. Bradley Intended status: Standards Track Ping Identity -Expires: November 27, 2017 N. Sakimura +Expires: December 31, 2017 N. Sakimura Nomura Research Institute T. Lodderstedt YES Europe AG - May 26, 2017 + June 29, 2017 - Mutual TLS Profiles for OAuth Clients - draft-ietf-oauth-mtls-01 + Mutual TLS Profile for OAuth 2.0 + draft-ietf-oauth-mtls-02 Abstract This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for both OAuth client authentication to the token endpoint as well as for sender constrained access to OAuth protected resources. Status of This Memo @@ -26,21 +26,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 http://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 November 27, 2017. + This Internet-Draft will expire on December 31, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -212,21 +212,21 @@ access token are possible, per agreement by the authorization server and the protected resource, but are beyond the scope of this specification. The client makes protected resource requests as described in [RFC6750], however, those requests MUST be made over a mutually authenticated TLS connection using the same certificate that was used for mutual TLS at the token endpoint. The protected resource MUST obtain the client certificate used for - mutual TLS authentication and MUST verify that the that certificate + mutual TLS authentication and MUST verify that the certificate matches the certificate associated with the access token. If they do not match, the resource access attempt MUST be rejected with an error. 3.1. X.509 Certificate SHA-256 Thumbprint Confirmation Method for JWT When access tokens are represented as a JSON Web Tokens (JWT)[RFC7519], the certificate hash information SHOULD be represented using the "x5t#S256" confirmation method member defined herein. @@ -274,22 +274,22 @@ Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] defined the "cnf" (confirmation) claim, which enables confirmation key information to be carried in a JWT. However, the same proof-of- possession semantics are also useful for introspected access tokens whereby the protected resource obtains the confirmation key data as meta-information of a token introspection response and uses that information in verifying proof-of-possession. Therefore this specification defines and registers proof-of-possession semantics for OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. When included as a top-level member of an OAuth token introspection - response, "cnf" has the same semantics and format as the the claim of - the same name defined in [RFC7800]. While this specification only + response, "cnf" has the same semantics and format as the claim of the + same name defined in [RFC7800]. While this specification only explicitly uses the "x5t#S256" confirmation method member, it needed to define and register the higher level "cnf" structure as an introspection response member in order to define and use its more specific "x5t#S256" confirmation method. The following is an example of an introspection response for an active token with an "x5t#S256" certificate thumbprint confirmation method. HTTP/1.1 200 OK @@ -487,46 +487,52 @@ Additionally, the authors would like to thank the following people for their input and contributions to the specification: Sergey Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Sean Leonard, Kepeng Li, James Manger, Jim Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes Tschofenig. Appendix B. Document(s) History [[ to be removed by the RFC Editor before publication as an RFC ]] + draft-ietf-oauth-mtls-02 + + o Fixed editorial issue https://mailarchive.ietf.org/arch/msg/oauth/ + U46UMEh8XIOQnvXY9pHFq1MKPns + o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is + better than "Mutual TLS Profiles for OAuth Clients"). + draft-ietf-oauth-mtls-01 o Added more explicit details of using RFC 7662 token introspection with mutual TLS sender constrained access tokens. o Added an IANA OAuth Token Introspection Response Registration request for "cnf". 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.