< draft-ietf-tokbind-https-17.txt		draft-ietf-tokbind-https-18.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: December 7, 2018 D. Balfanz, Ed.		Expires: December 28, 2018 D. Balfanz, Ed.
	A. Langley		A. Langley
	N. Harper		N. Harper
	Google Inc.		Google Inc.
	J. Hodges		J. Hodges
	PayPal		PayPal
	June 5, 2018		June 26, 2018
	Token Binding over HTTP		Token Binding over HTTP
	draft-ietf-tokbind-https-17		draft-ietf-tokbind-https-18
	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 December 7, 2018.		This Internet-Draft will expire on December 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 6		4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 6
	5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 7		5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 7
	5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7		5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10		5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12		5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12
	5.5. Federation Example . . . . . . . . . . . . . . . . . . . 12		5.5. Federation Example . . . . . . . . . . . . . . . . . . . 12
	6. Implementation Considerations . . . . . . . . . . . . . . . . 15		6. Implementation Considerations . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 15		7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 15
	7.2. Sensitivity of the Sec-Token-Binding Header . . . . . . . 16		7.2. Sensitivity of the Sec-Token-Binding Header . . . . . . . 15
	7.3. Securing Federated Sign-On Protocols . . . . . . . . . . 17		7.3. Securing Federated Sign-On Protocols . . . . . . . . . . 17
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
	8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 19		8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 19
	8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20		8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20
	8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 20		8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	11.1. Normative References . . . . . . . . . . . . . . . . . . 21		11.1. Normative References . . . . . . . . . . . . . . . . . . 21
	11.2. Informative References . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . 23
	skipping to change at page 15, line 11 ¶		skipping to change at page 15, line 11 ¶
	|<------------------------------| |		|<------------------------------| |
	| | |		| | |
	| | |		| | |
	6. Implementation Considerations		6. Implementation Considerations
	HTTPS-based applications may have multi-party use cases other than,		HTTPS-based applications may have multi-party use cases other than,
	or in addition to, the HTTP redirect-based signaling-and-conveyance		or in addition to, the HTTP redirect-based signaling-and-conveyance
	of referred token bindings, as presented above in Section 5.3.		of referred token bindings, as presented above in Section 5.3.
	Thus, platforms (Web browsers, operating systems, etc.) that		Thus, Token Binding implementations should provide APIs for such
	implement Token Binding and expose its functionality to applications		applications to generate Token Binding messages containing Token
	should provide means for such applications to generate Token Binding		Binding IDs of various application-specified Token Binding types, to
	messages containing Token Binding IDs of various application-		be conveyed by the Sec-Token-Binding header field.
	specified Token Binding types, to be conveyed by the Sec-Token-
	Binding header field.
	However, such platforms MUST only convey Token Binding IDs to servers		However, Token Binding implementations MUST only convey Token Binding
	if signaled to do so by an application. For example, a server can		IDs to servers if signaled to do so by an application. For example,
	return an Include-Referred-Token-Binding-ID HTTP response header		a server can return an Include-Referred-Token-Binding-ID HTTP
	field to a Web browser (the platform in this case), thus signaling to		response header field to an application, which then signals to the
	the Token Binding implementation in the Web browser that the		Token Binding implementation that it intends to convey the Token
	application intends to convey the Web browser's Token Binding ID to		Binding ID used with this server to another server. Other signaling
	another server. Other signaling mechanisms are possible, and are		mechanisms are possible, and are specific to the application layer
	specific to the application layer protocol, but are outside the scope		protocol, but are outside the scope of this specification.
	of this specification.
	NOTE: See Section 8 ("Privacy Considerations"), for privacy guidance		NOTE: See Section 8 ("Privacy Considerations"), for privacy guidance
	regarding the use of this functionality.		regarding the use of this functionality.
	7. Security Considerations		7. Security Considerations
	7.1. Security Token Replay		7.1. Security Token Replay
	The goal of the Federated Token Binding mechanisms is to prevent		The goal of the Federated Token Binding mechanisms is to prevent
	attackers from exporting and replaying tokens used in protocols		attackers from exporting and replaying tokens used in protocols
	skipping to change at page 22, line 9 ¶		skipping to change at page 21, line 48 ¶
	Moriarty and Stephen Farrell.		Moriarty and Stephen Farrell.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-tokbind-negotiation]		[I-D.ietf-tokbind-negotiation]
	Popov, A., Nystrom, M., Balfanz, D., and A. Langley,		Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
	"Transport Layer Security (TLS) Extension for Token		"Transport Layer Security (TLS) Extension for Token
	Binding Protocol Negotiation", draft-ietf-tokbind-		Binding Protocol Negotiation", draft-ietf-tokbind-
	negotiation-13 (work in progress), May 2018.		negotiation-14 (work in progress), May 2018.
	[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-18 (work in progress), May 2018.		ietf-tokbind-protocol-19 (work in progress), May 2018.
	[PSL] Mozilla, "Public Suffix List, https://publicsuffix.org/",		[PSL] Mozilla, "Public Suffix List, https://publicsuffix.org/",
	<https://publicsuffix.org/>.		<https://publicsuffix.org/>.
	[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,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
End of changes. 9 change blocks.
	22 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/