--- 1/draft-ietf-tokbind-https-13.txt 2018-05-01 18:13:11.853864271 -0700 +++ 2/draft-ietf-tokbind-https-14.txt 2018-05-01 18:13:11.909865623 -0700 @@ -1,62 +1,61 @@ Internet Engineering Task Force A. Popov Internet-Draft M. Nystroem Intended status: Standards Track Microsoft Corp. -Expires: October 14, 2018 D. Balfanz, Ed. +Expires: November 2, 2018 D. Balfanz, Ed. A. Langley N. Harper Google Inc. J. Hodges PayPal - April 12, 2018 + May 1, 2018 Token Binding over HTTP - draft-ietf-tokbind-https-13 + draft-ietf-tokbind-https-14 Abstract This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. - This Internet-Draft is a companion document to The Token Binding - Protocol. + This document is a companion document to The Token Binding Protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -340,21 +339,22 @@ | | | | | | | | 5.2. Overview In a Federated Sign-On protocol, an Identity Provider issues an identity token to a client, which sends the identity token to a Relying Party to authenticate itself. Examples of this include 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 Provider may wish to bind the identity token to the TLS connection between the client and the Relying Party, thus ensuring that only said client can use the identity token. The Relying Party will 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 TLS connection between this Relying Party and the client. This is an example of a federation scenario, which more generally can @@ -878,27 +878,27 @@ same Token Binding key pair for both the Relying Party and the Identity Provider. Absent such special knowledge, conservative key- scoping rules should be used, assuring that clients use different Token Binding key pairs with different servers. 8.2. Lifetime of Token Binding Key Pairs 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 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 affordances provided to delete cookies). If a user agent provides modes such as private browsing mode in which 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 over. Generally speaking, users should be given the same level of control over lifetime of Token Binding key pairs as they have over cookies or other potential tracking mechanisms. 8.3. Correlation An application's various communicating endpoints that receive Token Binding IDs for TLS connections other than their own, obtain information about the application's other TLS connections. (In this @@ -964,26 +964,26 @@ 11.1. Normative References [fetch-spec] WhatWG, "Fetch", Living Standard , . [I-D.ietf-tokbind-negotiation] Popov, A., Nystrom, M., Balfanz, D., and A. Langley, "Transport Layer Security (TLS) Extension for Token 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] Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . @@ -1018,20 +1018,27 @@ Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, . 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, . + [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", August 2015, . [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, .