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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/