draft-ietf-tokbind-https-13.txt   draft-ietf-tokbind-https-14.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: October 14, 2018 D. Balfanz, Ed. Expires: November 2, 2018 D. Balfanz, Ed.
A. Langley A. Langley
N. Harper N. Harper
Google Inc. Google Inc.
J. Hodges J. Hodges
PayPal PayPal
April 12, 2018 May 1, 2018
Token Binding over HTTP Token Binding over HTTP
draft-ietf-tokbind-https-13 draft-ietf-tokbind-https-14
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
subsequently returns to the server, to the TLS connection between the subsequently returns to the server, to the TLS connection between the
client and server. Such bound security tokens are protected from client and server. Such bound security tokens are protected from
misuse since the server can generally detect if they are replayed misuse since the server can generally detect if they are replayed
inappropriately, e.g., over other TLS connections. inappropriately, e.g., over other TLS connections.
Federated token bindings, on the other hand, allow servers to Federated token bindings, on the other hand, allow servers to
cryptographically bind security tokens to a TLS connection that the cryptographically bind security tokens to a TLS connection that the
client has with a different server than the one issuing the token. client has with a different server than the one issuing the token.
This Internet-Draft is a companion document to The Token Binding This document is a companion document to The Token Binding Protocol.
Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 14, 2018. This Internet-Draft will expire on November 2, 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 8, line 47 skipping to change at page 8, line 47
| | | |
| | | | | |
| | | | | |
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 [OASIS.saml-core-2.0-os] (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
between the client and the Relying Party, thus ensuring that only between the client and the Relying Party, thus ensuring that only
said client can use the identity token. The Relying Party will said client can use the identity token. The Relying Party will
compare the Token Binding ID (or a cryptographic hash of it) in the compare the Token Binding ID (or a cryptographic hash of it) in the
identity token with the Token Binding ID (or a hash thereof) of the identity token with the Token Binding ID (or a hash thereof) of the
TLS connection between this Relying Party and the client. TLS connection between this Relying Party and the client.
This is an example of a federation scenario, which more generally can This is an example of a federation scenario, which more generally can
skipping to change at page 20, line 32 skipping to change at page 20, line 32
same Token Binding key pair for both the Relying Party and the same Token Binding key pair for both the Relying Party and the
Identity Provider. Absent such special knowledge, conservative key- Identity Provider. Absent such special knowledge, conservative key-
scoping rules should be used, assuring that clients use different scoping rules should be used, assuring that clients use different
Token Binding key pairs with different servers. Token Binding key pairs with different servers.
8.2. Lifetime of Token Binding Key Pairs 8.2. Lifetime of Token Binding Key Pairs
Token Binding key pairs do not have an expiration time. This means Token Binding key pairs do not have an expiration time. This means
that they can potentially be used by a server to track a user for an that they can potentially be used by a server to track a user for an
extended period of time (similar to a long-lived cookie). HTTPS extended period of time (similar to a long-lived cookie). HTTPS
clients such as Web user agents should therefore provide a user clients such as Web user agents SHOULD therefore provide a user
interface for discarding Token Binding key pairs (similar to the interface for discarding Token Binding key pairs (similar to the
affordances provided to delete cookies). affordances provided to delete cookies).
If a user agent provides modes such as private browsing mode in which If a user agent provides modes such as private browsing mode in which
the user is promised that browsing state such as cookies are the user is promised that browsing state such as cookies are
discarded after the session is over, the user agent should also discarded after the session is over, the user agent SHOULD also
discard Token Binding key pairs from such modes after the session is discard Token Binding key pairs from such modes after the session is
over. Generally speaking, users should be given the same level of over. Generally speaking, users should be given the same level of
control over lifetime of Token Binding key pairs as they have over control over lifetime of Token Binding key pairs as they have over
cookies or other potential tracking mechanisms. cookies or other potential tracking mechanisms.
8.3. Correlation 8.3. Correlation
An application's various communicating endpoints that receive Token An application's various communicating endpoints that receive Token
Binding IDs for TLS connections other than their own, obtain Binding IDs for TLS connections other than their own, obtain
information about the application's other TLS connections. (In this information about the application's other TLS connections. (In this
skipping to change at page 22, line 27 skipping to change at page 22, line 27
11.1. Normative References 11.1. Normative References
[fetch-spec] [fetch-spec]
WhatWG, "Fetch", Living Standard , WhatWG, "Fetch", Living Standard ,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[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-10 (work in progress), October 2017. negotiation-12 (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-16 (work in progress), October 2017. ietf-tokbind-protocol-17 (work in progress), April 2018.
[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,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
skipping to change at page 23, line 34 skipping to change at page 23, line 34
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>.
11.2. Informative References 11.2. Informative References
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", August 2015, C. Mortimore, "OpenID Connect Core 1.0", August 2015,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication "Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>. <https://www.rfc-editor.org/info/rfc5746>.
 End of changes. 11 change blocks. 
11 lines changed or deleted 18 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/