draft-ietf-tokbind-https-11.txt		draft-ietf-tokbind-https-12.txt
	Internet Engineering Task Force A. Popov		Internet Engineering Task Force A. Popov
	Internet-Draft M. Nystroem		Internet-Draft M. Nystroem
	Intended status: Standards Track Microsoft Corp.		Intended status: Standards Track Microsoft Corp.
	Expires: May 19, 2018 D. Balfanz, Ed.		Expires: July 11, 2018 D. Balfanz, Ed.
	A. Langley		A. Langley
	N. Harper		N. Harper
	Google Inc.		Google Inc.
	J. Hodges		J. Hodges
	PayPal		PayPal
	November 15, 2017		January 7, 2018
	Token Binding over HTTP		Token Binding over HTTP
	draft-ietf-tokbind-https-11		draft-ietf-tokbind-https-12
	Abstract		Abstract
	This document describes a collection of mechanisms that allow HTTP		This document describes a collection of mechanisms that allow HTTP
	servers to cryptographically bind security tokens (such as cookies		servers to cryptographically bind security tokens (such as cookies
	and OAuth tokens) to TLS connections.		and OAuth tokens) to TLS connections.
	We describe both first-party and federated scenarios. In a first-		We describe both first-party and federated scenarios. In a first-
	party scenario, an HTTP server is able to cryptographically bind the		party scenario, an HTTP server is able to cryptographically bind the
	security tokens it issues to a client, and which the client		security tokens it issues to a client, and which the client
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 May 19, 2018.		This Internet-Draft will expire on July 11, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. The Sec-Token-Binding HTTP Request Header Field . . . . . . . 4		2. The Sec-Token-Binding HTTP Request Header Field . . . . . . . 4
	2.1. HTTPS Token Binding Key Pair Scoping . . . . . . . . . . 5		2.1. HTTPS Token Binding Key Pair Scoping . . . . . . . . . . 5
	3. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . . . 6		3. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . . . 6
	4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 6		4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 6
	5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 6		5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 6
	5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 8		5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 10		5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12
	5.5. Federation Example . . . . . . . . . . . . . . . . . . . 11		5.5. Federation Example . . . . . . . . . . . . . . . . . . . 12
	6. Implementation Considerations . . . . . . . . . . . . . . . . 13		6. Implementation Considerations . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 13		7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 15
	7.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS		7.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS
	Versions . . . . . . . . . . . . . . . . . . . . . . . . 14		Versions . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.3. Sensitivity of the Sec-Token-Binding Header . . . . . . . 14		7.3. Sensitivity of the Sec-Token-Binding Header . . . . . . . 16
	7.4. Securing Federated Sign-On Protocols . . . . . . . . . . 15		7.4. Securing Federated Sign-On Protocols . . . . . . . . . . 17
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 18		8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 19
	8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 18		8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20
	8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 19		8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11.1. Normative References . . . . . . . . . . . . . . . . . . 20		11.1. Normative References . . . . . . . . . . . . . . . . . . 22
	11.2. Informative References . . . . . . . . . . . . . . . . . 21		11.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The Token Binding Protocol [I-D.ietf-tokbind-protocol] defines a		The Token Binding Protocol [I-D.ietf-tokbind-protocol] defines a
	Token Binding ID for a TLS connection between a client and a server.		Token Binding ID for a TLS connection between a client and a server.
	The Token Binding ID of a TLS connection is constructed using the		The Token Binding ID of a TLS connection is constructed using the
	public key of a private-public key pair. The client proves		public key of a private-public key pair. The client proves
	possession of the corresponding private key. This Token Binding key		possession of the corresponding private key. This Token Binding key
	pair is long-lived. I.e., subsequent TLS connections between the		pair is long-lived. I.e., subsequent TLS connections between the
	same client and server have the same Token Binding ID, unless		same client and server have the same Token Binding ID, unless
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	(re-use, attempted impersonation, etc.) by attackers.		(re-use, attempted impersonation, etc.) by attackers.
	While the Token Binding Protocol [I-D.ietf-tokbind-protocol] defines		While the Token Binding Protocol [I-D.ietf-tokbind-protocol] defines
	a message format for establishing a Token Binding ID, it does not		a message format for establishing a Token Binding ID, it does not
	specify how this message is embedded in higher-level protocols. The		specify how this message is embedded in higher-level protocols. The
	purpose of this specification is to define how TokenBindingMessages		purpose of this specification is to define how TokenBindingMessages
	are embedded in HTTP (both versions 1.1 [RFC7230] and 2 [RFC7540]).		are embedded in HTTP (both versions 1.1 [RFC7230] and 2 [RFC7540]).
	Note that TokenBindingMessages are only defined if the underlying		Note that TokenBindingMessages are only defined if the underlying
	transport uses TLS. This means that Token Binding over HTTP is only		transport uses TLS. This means that Token Binding over HTTP is only
	defined when the HTTP protocol is layered on top of TLS (commonly		defined when the HTTP protocol is layered on top of TLS (commonly
	referred to as HTTPS).		referred to as HTTPS [RFC2818]).
	HTTP clients establish a Token Binding ID with a server by including		HTTP clients establish a Token Binding ID with a server by including
	a special HTTP header field in HTTP requests. The HTTP header field		a special HTTP header field in HTTP requests. The HTTP header field
	value is a base64url-encoded TokenBindingMessage.		value is a base64url-encoded TokenBindingMessage.
	TokenBindingMessages allow clients to establish multiple Token		TokenBindingMessages allow clients to establish multiple Token
	Binding IDs with the server, by including multiple TokenBinding		Binding IDs with the server, by including multiple TokenBinding
	structures in the TokenBindingMessage. By default, a client will		structures in the TokenBindingMessage. By default, a client will
	establish a provided Token Binding ID with the server, indicating a		establish a provided Token Binding ID with the server, indicating a
	Token Binding ID that the client will persistently use with the		Token Binding ID that the client will persistently use with the
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	The header field name is Sec-Token-Binding and its single value,		The header field name is Sec-Token-Binding and its single value,
	EncodedTokenBindingMessage, is a base64url encoding of a single		EncodedTokenBindingMessage, is a base64url encoding of a single
	TokenBindingMessage, as defined in [I-D.ietf-tokbind-protocol], using		TokenBindingMessage, as defined in [I-D.ietf-tokbind-protocol], using
	the URL- and filename-safe character set described in Section 5 of		the URL- and filename-safe character set described in Section 5 of
	[RFC4648], with all trailing padding characters '=' omitted and		[RFC4648], with all trailing padding characters '=' omitted and
	without the inclusion of any line breaks, whitespace, or other		without the inclusion of any line breaks, whitespace, or other
	additional characters.		additional characters.
	For example:		For example:
	Sec-Token-Binding: <base64url-encoded TokenBindingMessage>		Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\
			9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\
			aOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25Gg\
			mKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA
	If the server receives more than one Sec-Token-Binding header field		If the server receives more than one Sec-Token-Binding header field
	in an HTTP request, then the server MUST reject the message with a		in an HTTP request, then the server MUST reject the message with a
	400 (Bad Request) HTTP status code. Additionally, the Sec-Token-		400 (Bad Request) HTTP status code. Additionally, the Sec-Token-
	Binding header field:		Binding header field:
	SHOULD NOT be stored by origin servers on PUT requests,		SHOULD NOT be stored by origin servers on PUT requests,
	MAY be listed by a server in a Vary response header field, and,		MAY be listed by a server in a Vary response header field, and,
	MUST NOT be used in HTTP trailers.		MUST NOT be used in HTTP trailers.
	The TokenBindingMessage MUST contain one TokenBinding structure with		The TokenBindingMessage MUST contain exactly one TokenBinding
	TokenBindingType of provided_token_binding, which MUST be signed with		structure with TokenBindingType of provided_token_binding, which MUST
	the Token Binding private key used by the client for connections		be signed with the Token Binding private key used by the client for
	between itself and the server that the HTTP request is sent to		connections between itself and the server that the HTTP request is
	(clients use different Token Binding key pairs for different servers,		sent to (clients use different Token Binding key pairs for different
	see Section 2.1 below). The Token Binding ID established by this		servers, see Section 2.1 below). The Token Binding ID established by
	TokenBinding is called a Provided Token Binding ID.		this TokenBinding is called a Provided Token Binding ID.
	The TokenBindingMessage MAY also contain one TokenBinding structure		The TokenBindingMessage MAY also contain exactly one TokenBinding
	with TokenBindingType of referred_token_binding, as specified in		structure with TokenBindingType of referred_token_binding, as
	Section 5.3. In addition to the latter, or rather than the latter,		specified in Section 5.3. In addition to the latter, or rather than
	the TokenBindingMessage MAY contain other TokenBinding structures.		the latter, the TokenBindingMessage MAY contain other TokenBinding
	This is use case-specific, and such use cases are outside the scope		structures. This is use case-specific, and such use cases are
	of this specification.		outside the scope of this specification.
	A TokenBindingMessage is validated by the server as described in		A TokenBindingMessage is validated by the server as described in
	Section 4.2. ("Server Processing Rules") of		Section 4.2. ("Server Processing Rules") of
	[I-D.ietf-tokbind-protocol]. If validation fails and a Token Binding		[I-D.ietf-tokbind-protocol]. If validation fails and a Token Binding
	is rejected, any associated bound tokens MUST also be rejected by the		is rejected, any associated bound tokens MUST also be rejected by the
	server. HTTP requests containing invalid tokens MUST be rejected.		server. HTTP requests containing invalid tokens MUST be rejected.
	In this case, the server application MAY return HTTP status code 400		In this case, the server application MAY return HTTP status code 400
	(Bad Request) or proceed with an application-specific invalid token		(Bad Request) or proceed with an application-specific invalid token
	response (e.g., directing the client to re-authenticate and present a		response (e.g., directing the client to re-authenticate and present a
	different token), or terminate the connection.		different token), or terminate the connection.
	skipping to change at page 7, line 24 ¶		skipping to change at page 8, line 5 ¶
	document). Also common across the mechanisms is how the Token		document). Also common across the mechanisms is how the Token
	Binding ID is revealed to the Token Provider: The client uses the		Binding ID is revealed to the Token Provider: The client uses the
	Token Binding Protocol [I-D.ietf-tokbind-protocol], and includes a		Token Binding Protocol [I-D.ietf-tokbind-protocol], and includes a
	TokenBinding structure in the Sec-Token-Binding HTTP header field		TokenBinding structure in the Sec-Token-Binding HTTP header field
	defined above. What differs between the various mechanisms is how		defined above. What differs between the various mechanisms is how
	the Token Consumer signals to the client that it should reveal the		the Token Consumer signals to the client that it should reveal the
	Token Binding ID to the Token Provider. Below, we specify one such		Token Binding ID to the Token Provider. Below, we specify one such
	mechanism, which is suitable for redirect-based interactions between		mechanism, which is suitable for redirect-based interactions between
	Token Consumers and Token Providers.		Token Consumers and Token Providers.
			Client Token Consumer Token Provider
			+--------+ +----+ +-----+
			| Client | | TC | | TP |
			+--------+ +----+ +-----+
			| | |
			| | |
			| | |
			| Client interacts w/TC | |
			| using TokenBindingID TBID1: | |
			| TBMSG[[provided_token_binding,| |
			| TBID1, signature]] | |
			|------------------------------>| |
			| | |
			| Client interacts w/TP |
			| using TokenBindingID TBID2: |
			| TBMSG[[provided_token_binding, |
			| TBID2, signature]] |
			|----------------------------------------------------->|
			| |
			| | |
			| TC signals permission to | |
			| reveal TBID1 to TP | |
			|<------------------------------| |
			| | |
			| |
			| Client interacts w/TP |
			| using TokenBindingID TBID1 and TBID2: |
			| TBMSG[[provided_token_binding, |
			| TBID2, signature], |
			| [referred_token_binding, |
			| TBID1, sognature]] |
			|----------------------------------------------------->|
			| |
			| | |
			| | |
	5.2. Overview		5.2. Overview
	In a Federated Sign-On protocol, an Identity Provider issues an		In a Federated Sign-On protocol, an Identity Provider issues an
	identity token to a client, which sends the identity token to a		identity token to a client, which sends the identity token to a
	Relying Party to authenticate itself. Examples of this include		Relying Party to authenticate itself. Examples of this include
	OpenID Connect (in which the identity token is called an "ID Token")		OpenID Connect (in which the identity token is called an "ID Token")
	and SAML (in which the identity token is a SAML assertion).		and SAML (in which the identity token is a SAML assertion).
	To better protect the security of the identity token, the Identity		To better protect the security of the identity token, the Identity
	Provider may wish to bind the identity token to the TLS connection		Provider may wish to bind the identity token to the TLS connection
	skipping to change at page 20, line 41 ¶		skipping to change at page 22, line 36 ¶
	[I-D.ietf-tokbind-protocol]		[I-D.ietf-tokbind-protocol]
	Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.		Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
	Hodges, "The Token Binding Protocol Version 1.0", draft-		Hodges, "The Token Binding Protocol Version 1.0", draft-
	ietf-tokbind-protocol-16 (work in progress), October 2017.		ietf-tokbind-protocol-16 (work in progress), October 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
			DOI 10.17487/RFC2818, May 2000,
			<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<https://www.rfc-editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
End of changes. 13 change blocks.
	41 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/