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/