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/