draft-ietf-tokbind-https-14.txt   draft-ietf-tokbind-https-15.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: November 2, 2018 D. Balfanz, Ed. Expires: November 10, 2018 D. Balfanz, Ed.
A. Langley A. Langley
N. Harper N. Harper
Google Inc. Google Inc.
J. Hodges J. Hodges
PayPal PayPal
May 1, 2018 May 9, 2018
Token Binding over HTTP Token Binding over HTTP
draft-ietf-tokbind-https-14 draft-ietf-tokbind-https-15
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 November 2, 2018. This Internet-Draft will expire on November 10, 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 32 skipping to change at page 2, line 32
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . 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. Triple Handshake Vulnerability in TLS 1.2 and Older TLS 7.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS
Versions . . . . . . . . . . . . . . . . . . . . . . . . 16 Versions . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 8 skipping to change at page 4, line 8
Token Binding ID that the client will persistently use with the Token Binding ID that the client will persistently use with the
server. Under certain conditions, the client can also include a server. Under certain conditions, the client can also include a
referred Token Binding ID in the TokenBindingMessage, indicating a referred Token Binding ID in the TokenBindingMessage, indicating a
Token Binding ID that the client is using with a different server Token Binding ID that the client is using with a different server
than the one that the TokenBindingMessage is sent to. This is useful than the one that the TokenBindingMessage is sent to. This is useful
in federation scenarios. in federation scenarios.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. The Sec-Token-Binding HTTP Request Header Field 2. The Sec-Token-Binding HTTP Request Header Field
Once a client and server have negotiated the Token Binding Protocol Once a client and server have negotiated the Token Binding Protocol
with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
[I-D.ietf-tokbind-negotiation]), clients MUST include a Sec-Token- [I-D.ietf-tokbind-negotiation]), clients MUST include a Sec-Token-
Binding header field in their HTTP requests, and MUST include only Binding header field in their HTTP requests, and MUST include only
one such header field per HTTP request. Also, The Sec-Token-Binding one such header field per HTTP request. Also, The Sec-Token-Binding
header field MUST NOT be included in HTTP responses. The ABNF of the header field MUST NOT be included in HTTP responses. The ABNF of the
Sec-Token-Binding header field is (in [RFC7230] style, see also Sec-Token-Binding header field is (in [RFC7230] style, see also
skipping to change at page 23, line 32 skipping to change at page 23, line 32
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005, <http://docs.oasis- 2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>. open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[OpenID.Core] [OpenID.Core]
 End of changes. 7 change blocks. 
7 lines changed or deleted 13 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/