--- 1/draft-ietf-oauth-mtls-06.txt 2018-01-30 10:13:38.049339884 -0800 +++ 2/draft-ietf-oauth-mtls-07.txt 2018-01-30 10:13:38.093340925 -0800 @@ -1,24 +1,24 @@ OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track J. Bradley -Expires: July 19, 2018 Yubico +Expires: August 2, 2018 Yubico N. Sakimura Nomura Research Institute T. Lodderstedt YES Europe AG - January 15, 2018 + January 29, 2018 OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens - draft-ietf-oauth-mtls-06 + draft-ietf-oauth-mtls-07 Abstract This document describes Transport Layer Security (TLS) mutual authentication using X.509 certificates as a mechanism for OAuth client authentication to the authorization sever as well as for 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. @@ -30,21 +30,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 July 19, 2018. + This Internet-Draft will expire on August 2, 2018. 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 @@ -128,22 +128,23 @@ access tokens or replay of access tokens by unauthorized parties. Mutual TLS sender constrained access tokens and mutual TLS client authentication are distinct mechanisms, which are complementary but don't necessarily need to be deployed together. 1.1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in RFC - 2119 [RFC2119]. + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 1.2. Terminology This specification uses the following phrases interchangeably: Transport Layer Security (TLS) Mutual Authentication Mutual TLS These phrases all refer to the process whereby a client presents its @@ -694,20 +695,24 @@ [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 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 @@ -749,20 +754,24 @@ for their input and contributions to the specification: Sergey Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, Phil Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, 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-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 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/ @@ -829,29 +838,32 @@ 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