draft-ietf-oauth-mtls-15.txt   draft-ietf-oauth-mtls-16.txt 
OAuth Working Group B. Campbell OAuth Working Group B. Campbell
Internet-Draft Ping Identity Internet-Draft Ping Identity
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 4, 2020 Yubico Expires: February 14, 2020 Yubico
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
T. Lodderstedt T. Lodderstedt
YES.com AG YES.com AG
July 3, 2019 August 13, 2019
OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound
Access Tokens Access Tokens
draft-ietf-oauth-mtls-15 draft-ietf-oauth-mtls-16
Abstract Abstract
This document describes OAuth client authentication and certificate- This document describes OAuth client authentication and certificate-
bound access and refresh tokens using mutual Transport Layer Security bound access and refresh tokens using mutual Transport Layer Security
(TLS) authentication with X.509 certificates. OAuth clients are (TLS) authentication with X.509 certificates. OAuth clients are
provided a mechanism for authentication to the authorization server provided a mechanism for authentication to the authorization server
using mutual TLS, based on either self-signed certificates or public using mutual TLS, based on either self-signed certificates or public
key infrastructure (PKI). OAuth authorization servers are provided a key infrastructure (PKI). OAuth authorization servers are provided a
mechanism for binding access tokens to a client's mutual TLS mechanism for binding access tokens to a client's mutual TLS
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 4, 2020. This Internet-Draft will expire on February 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 16, line 24 skipping to change at page 16, line 24
intermediary. How the client certificate metadata is securely intermediary. How the client certificate metadata is securely
communicated between the intermediary and the application server in communicated between the intermediary and the application server in
this case is out of scope of this specification. this case is out of scope of this specification.
7. Security Considerations 7. Security Considerations
7.1. Certificate-Bound Refresh Tokens 7.1. Certificate-Bound Refresh Tokens
The OAuth 2.0 Authorization Framework [RFC6749] requires that an The OAuth 2.0 Authorization Framework [RFC6749] requires that an
authorization server bind refresh tokens to the client to which they 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) authentication credentials with the authorization server)
authenticate to the AS when presenting a refresh token. As a result, authenticate to the AS when presenting a refresh token. As a result,
refresh tokens are indirectly certificate-bound when issued to refresh tokens are indirectly certificate-bound when issued to
clients utilizing the "tls_client_auth" or clients utilizing the "tls_client_auth" or
"self_signed_tls_client_auth" methods of client authentication. "self_signed_tls_client_auth" methods of client authentication.
Section 4 describes certificate-bound refresh tokens issued to public Section 4 describes certificate-bound refresh tokens issued to public
clients (those without authentication credentials associated with the clients (those without authentication credentials associated with the
"client_id"). "client_id").
7.2. Certificate Thumbprint Binding 7.2. Certificate Thumbprint Binding
skipping to change at page 25, line 44 skipping to change at page 25, line 44
This specification was developed within the OAuth Working Group under This specification was developed within the OAuth Working Group under
the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security
Area Directors. Additionally, the following individuals contributed Area Directors. Additionally, the following individuals contributed
ideas, feedback, and wording that helped shape this specification: ideas, feedback, and wording that helped shape this specification:
Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer, Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer,
Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif
Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko
Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim
Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer, 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 Appendix D. 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-16
o Editorial updates from last call review.
draft-ietf-oauth-mtls-15 draft-ietf-oauth-mtls-15
o Editorial updates from second AD review. o Editorial updates from second AD review.
draft-ietf-oauth-mtls-14 draft-ietf-oauth-mtls-14
o Editorial clarifications around there being only a single subject o Editorial clarifications around there being only a single subject
registered/configured per client for the tls_client_auth method. registered/configured per client for the tls_client_auth method.
o Add a brief explanation about how, with tls_client_auth and o Add a brief explanation about how, with tls_client_auth and
self_signed_tls_client_auth, refresh tokens are certificate-bound self_signed_tls_client_auth, refresh tokens are certificate-bound
indirectly via the client authentication. indirectly via the client authentication.
o Add mention of refresh tokens in the abstract. o Add mention of refresh tokens in the abstract.
skipping to change at page 27, line 47 skipping to change at page 28, line 4
o Add a new security considerations section on X.509 parsing and o Add a new security considerations section on X.509 parsing and
validation per WGLC feedback from Neil Madden and Benjamin Kaduk validation per WGLC feedback from Neil Madden and Benjamin Kaduk
o Note that a server can terminate TLS at a load balancer, reverse o Note that a server can terminate TLS at a load balancer, reverse
proxy, etc. but how the client certificate metadata is securely proxy, etc. but how the client certificate metadata is securely
communicated to the backend is out of scope per WGLC feedback communicated to the backend is out of scope per WGLC feedback
o Note that revocation checking is at the discretion of the AS per o Note that revocation checking is at the discretion of the AS per
WGLC feedback WGLC feedback
o Editorial updates and clarifications o Editorial updates and clarifications
o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf- o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf-
oauth-token-binding to -06 oauth-token-binding to -06
o Add folks involved in WGLC feedback to the acknowledgements list o Add folks involved in WGLC feedback to the acknowledgements list
draft-ietf-oauth-mtls-07 draft-ietf-oauth-mtls-07
o Update to use the boilerplate from RFC 8174 o Update to use the boilerplate from RFC 8174
draft-ietf-oauth-mtls-06
o Add an appendix section describing the relationship of this o Add an appendix section describing the relationship of this
document to OAuth Token Binding as requested during the Singapore document to OAuth Token Binding as requested during the Singapore
meeting https://datatracker.ietf.org/doc/minutes-100-oauth/ meeting https://datatracker.ietf.org/doc/minutes-100-oauth/
o Add an explicit note that the implicit flow is not supported for o Add an explicit note that the implicit flow is not supported for
obtaining certificate bound access tokens as discussed at the obtaining certificate bound access tokens as discussed at the
Singapore meeting https://datatracker.ietf.org/doc/minutes- Singapore meeting https://datatracker.ietf.org/doc/minutes-
100-oauth/ 100-oauth/
o Add/incorporate text to the Security Considerations on Certificate o Add/incorporate text to the Security Considerations on Certificate
Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/ Spoofing as suggested https://mailarchive.ietf.org/arch/msg/oauth/
V26070X-6OtbVSeUz_7W2k94vCo V26070X-6OtbVSeUz_7W2k94vCo
skipping to change at page 29, line 44 skipping to change at page 30, line 4
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 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
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. 12 change blocks. 
7 lines changed or deleted 16 lines changed or added

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