draft-ietf-oauth-mtls-01.txt   draft-ietf-oauth-mtls-02.txt 
OAuth Working Group B. Campbell OAuth Working Group B. Campbell
Internet-Draft J. Bradley Internet-Draft J. Bradley
Intended status: Standards Track Ping Identity Intended status: Standards Track Ping Identity
Expires: November 27, 2017 N. Sakimura Expires: December 31, 2017 N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES Europe AG YES Europe AG
May 26, 2017 June 29, 2017
Mutual TLS Profiles for OAuth Clients Mutual TLS Profile for OAuth 2.0
draft-ietf-oauth-mtls-01 draft-ietf-oauth-mtls-02
Abstract Abstract
This document describes Transport Layer Security (TLS) mutual This document describes Transport Layer Security (TLS) mutual
authentication using X.509 certificates as a mechanism for both OAuth authentication using X.509 certificates as a mechanism for both OAuth
client authentication to the token endpoint as well as for sender client authentication to the token endpoint as well as for sender
constrained access to OAuth protected resources. constrained access to OAuth protected resources.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 27, 2017. This Internet-Draft will expire on December 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 5, line 33 skipping to change at page 5, line 33
access token are possible, per agreement by the authorization server access token are possible, per agreement by the authorization server
and the protected resource, but are beyond the scope of this and the protected resource, but are beyond the scope of this
specification. specification.
The client makes protected resource requests as described in The client makes protected resource requests as described in
[RFC6750], however, those requests MUST be made over a mutually [RFC6750], however, those requests MUST be made over a mutually
authenticated TLS connection using the same certificate that was used authenticated TLS connection using the same certificate that was used
for mutual TLS at the token endpoint. for mutual TLS at the token endpoint.
The protected resource MUST obtain the client certificate used for 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 matches the certificate associated with the access token. If they do
not match, the resource access attempt MUST be rejected with an not match, the resource access attempt MUST be rejected with an
error. error.
3.1. X.509 Certificate SHA-256 Thumbprint Confirmation Method for JWT 3.1. X.509 Certificate SHA-256 Thumbprint Confirmation Method for JWT
When access tokens are represented as a JSON Web Tokens When access tokens are represented as a JSON Web Tokens
(JWT)[RFC7519], the certificate hash information SHOULD be (JWT)[RFC7519], the certificate hash information SHOULD be
represented using the "x5t#S256" confirmation method member defined represented using the "x5t#S256" confirmation method member defined
herein. herein.
skipping to change at page 6, line 47 skipping to change at page 6, line 47
Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800] Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800]
defined the "cnf" (confirmation) claim, which enables confirmation defined the "cnf" (confirmation) claim, which enables confirmation
key information to be carried in a JWT. However, the same proof-of- key information to be carried in a JWT. However, the same proof-of-
possession semantics are also useful for introspected access tokens possession semantics are also useful for introspected access tokens
whereby the protected resource obtains the confirmation key data as whereby the protected resource obtains the confirmation key data as
meta-information of a token introspection response and uses that meta-information of a token introspection response and uses that
information in verifying proof-of-possession. Therefore this information in verifying proof-of-possession. Therefore this
specification defines and registers proof-of-possession semantics for specification defines and registers proof-of-possession semantics for
OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure. OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure.
When included as a top-level member of an OAuth token introspection 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 response, "cnf" has the same semantics and format as the claim of the
the same name defined in [RFC7800]. While this specification only same name defined in [RFC7800]. While this specification only
explicitly uses the "x5t#S256" confirmation method member, it needed explicitly uses the "x5t#S256" confirmation method member, it needed
to define and register the higher level "cnf" structure as an to define and register the higher level "cnf" structure as an
introspection response member in order to define and use its more introspection response member in order to define and use its more
specific "x5t#S256" confirmation method. specific "x5t#S256" confirmation method.
The following is an example of an introspection response for an The following is an example of an introspection response for an
active token with an "x5t#S256" certificate thumbprint confirmation active token with an "x5t#S256" certificate thumbprint confirmation
method. method.
HTTP/1.1 200 OK HTTP/1.1 200 OK
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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, Phil Hunt, Sean Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Phil Hunt, Sean
Leonard, Kepeng Li, James Manger, Jim Manico, Nov Matake, Sascha Leonard, Kepeng Li, James Manger, Jim Manico, Nov Matake, Sascha
Preibisch, Justin Richer, Dave Tonge, and Hannes Tschofenig. Preibisch, Justin Richer, Dave Tonge, and Hannes Tschofenig.
Appendix B. Document(s) History Appendix B. 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-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 draft-ietf-oauth-mtls-01
o Added more explicit details of using RFC 7662 token introspection o Added more explicit details of using RFC 7662 token introspection
with mutual TLS sender constrained access tokens. with mutual TLS sender constrained access tokens.
o Added an IANA OAuth Token Introspection Response Registration o Added an IANA OAuth Token Introspection Response Registration
request for "cnf". request for "cnf".
o Specify that tls_client_auth_subject_dn and o Specify that tls_client_auth_subject_dn and
tls_client_auth_root_dn are RFC 4514 String Representation of tls_client_auth_root_dn are RFC 4514 String Representation of
Distinguished Names. Distinguished Names.
o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn. 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 o Changed the text in the Section 3 to not be specific about using a
hash of the cert. hash of the cert.
o Changed the abbreviated title to 'OAuth Mutual TLS' (previously o Changed the abbreviated title to 'OAuth Mutual TLS' (previously
was the acronym MTLSPOC). was the acronym MTLSPOC).
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
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 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. 9 change blocks. 
10 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/