draft-ietf-tokbind-https-06.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml">
<!ENTITY RFC4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5705 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5705.xml">
<!ENTITY RFC5746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY RFC6749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC6750 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml">
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7301.xml">
<!ENTITY RFC7540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7540.xml">
<!ENTITY RFC7541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7541.xml">
<!ENTITY RFC7627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7627.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-tokbind-https-06" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>Token Binding over HTTP</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Andrei Popov" initials="A."
            surname="Popov">
      <organization>Microsoft Corp.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>andreipo@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Magnus Nyström" initials="M."
            surname="Nyström">
      <organization>Microsoft Corp.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>mnystrom@microsoft.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Dirk Balfanz" initials="D."
            surname="Balfanz" role="editor">
      <organization>Google Inc.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>balfanz@google.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Adam Langley" initials="A."
            surname="Langley">
      <organization>Google Inc.</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>agl@google.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Jeff Hodges" initials="J."
            surname="Hodges">
      <organization>Paypal</organization>

      <address>
        <postal>
          <street></street>

          <!-- Reorder these if your country does things differently -->

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <email>Jeff.Hodges@paypal.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2016" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>draft</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document describes a collection of mechanisms that allow
      HTTP servers to cryptographically bind authentication tokens
      (such as cookies and OAuth tokens) to <xref
      target="RFC5246">TLS</xref> connections.</t>

      <t>We describe both <spanx style="emph">first-party</spanx> and
      <spanx style="emph">federated</spanx> 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.</t>

      <t>Federated token bindings, on the other hand, allow servers to
      cryptographically bind security tokens to a TLS
      connection that the client has with
      a <spanx style="emph">different</spanx> server than the one
      issuing the token.</t>

      <t>This Internet-Draft is a companion document to <xref
      target="I-D.ietf-tokbind-protocol">The Token Binding Protocol</xref></t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="I-D.ietf-tokbind-protocol">The Token Binding Protocol</xref>
      defines a Token Binding ID for a TLS connection between a client
      and a server. The Token Binding ID of a TLS connection is
      related to a private key, that the client proves possession of to
      the server, and is long-lived (i.e., subsequent TLS connections
      between the same client and server have the same Token Binding
      ID). When issuing a security token (e.g. an HTTP cookie or an
      OAuth token) to a client, the server can include the Token
      Binding ID in the token, thus cryptographically binding the
      token to TLS connections between that particular client and
      server, and inoculating the token against abuse (re-use, 
      attempted impersonation, etc.) by attackers.</t>
      <t>While the <xref target="I-D.ietf-tokbind-protocol">Token Binding
      Protocol</xref> defines a message format for establishing a
      Token Binding ID, it does not specify how this message is
      embedded in higher-level protocols. The purpose of this
      specification is to define how TokenBindingMessages are embedded
      in HTTP (both versions <xref target="RFC7230">1.1</xref> and
      <xref target="RFC7540">2</xref>). Note that
      TokenBindingMessages are only defined if the underlying
      transport uses TLS. This means that Token Binding over HTTP is
      only defined when the HTTP protocol is layered on top of TLS
      (commonly referred to as HTTPS).</t>
      <t>HTTP clients establish a Token Binding ID with a server by
      including a special HTTP header field in HTTP requests. The HTTP
      header field value is a base64url-encoded TokenBindingMessage.</t>
      <t>TokenBindingMessages allow clients to establish multiple
      Token Binding IDs with the server, by including multiple
      TokenBinding structures in the TokenBindingMessage. By default,
      a client will establish a <spanx style="emph">provided</spanx>
      Token Binding ID with the server, indicating a Token Binding ID
      that the client will persistently use with the server. Under
      certain conditions, the client can also include a <spanx
      style="emph">referred</spanx> Token Binding ID in the
      TokenBindingMessage, indicating a Token Binding ID that the
      client is using with a <spanx style="emph">different</spanx>
      server than the one that the TokenBindingMessage is sent
      to. This is useful in federation scenarios.</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119" />.</t>
      </section>
    </section>

    <section title="The Sec-Token-Binding Header Field">
      <t>Once a client and server have negotiated the Token Binding
      Protocol with HTTP/1.1 or HTTP/2 (see <xref
      target="I-D.ietf-tokbind-protocol"/> and <xref
      target="I-D.ietf-tokbind-negotiation"/>), clients
      MUST include the Sec-Token-Binding header field in their HTTP requests. The ABNF 
      of the Sec-Token-Binding header field is (in <xref target="RFC7230"/> style, see also <xref target="RFC7231"/> Section 8.3):
      </t>
      <figure><artwork><![CDATA[
  Sec-Token-Binding = EncodedTokenBindingMessage
        ]]></artwork></figure>

      <t>The header field name is <spanx style="verb">Sec-Token-Binding</spanx> 
      and its value is a base64url encoding of the TokenBindingMessage defined 
      in <xref target="I-D.ietf-tokbind-protocol"/> using the URL- and 
      filename-safe character set described in Section 5 of 
      <xref target="RFC4648"/>, with all trailing pad characters '=' omitted 
      and without the inclusion of any line breaks, whitespace, or other 
      additional characters.</t>

      <t>For example:</t>
      <figure><artwork><![CDATA[
  Sec-Token-Binding: <base64url-encoded TokenBindingMessage>
        ]]></artwork></figure>
      

      <t>The TokenBindingMessage MUST contain one TokenBinding structure 
      with TokenBindingType of provided_token_binding, which MUST be signed
      with the Token Binding private key used by the client for connections
      between itself and the server that the HTTP request is sent to
      (clients use different Token Binding keys for different
      servers, see <xref target="sctn-keypair-scope"/> below). 
      The Token Binding ID established by this TokenBinding
      is called a <spanx style="emph">Provided Token Binding
      ID</spanx>.</t>
      
      <t>The TokenBindingMessage MAY also contain one TokenBinding structure
      with TokenBindingType of referred_token_binding, as specified in
      <xref target="sctn-http-redir"/>. In addition to the latter,
      or rather than the latter, the TokenBindingMessage 
      MAY contain other TokenBinding structures. This is use case-specific, 
      and such use cases are outside the scope of this
      specification.</t>

      <t>In HTTP/2, the client SHOULD use <xref
      target="RFC7541">Header
      Compression</xref> to avoid the overhead of repeating the same
      header field in subsequent HTTP requests.</t>
      
      
      
      <section title="HTTPS Token Binding Key Pair Scoping" 
        anchor="sctn-keypair-scope">
        
        <t>HTTPS is used in conjunction with various application 
        protocols, and application contexts, in various ways. 
        For example, general purpose Web browsing is one such HTTP-based 
        application context. Within the latter context, HTTP cookies 
        <xref target="RFC6265"/> are typically utilized for state management, 
        including client authentication. 
        A related, though distinct, example of other HTTP-based
        application contexts is where OAuth tokens <xref target="RFC6749"/>
        are utilized to manage 
        authorization for third-party application access to resources. 
        The token scoping rules of these two 
        examples can differ: the scoping rules for cookies are concisely 
        specified in <xref target="RFC6265"/>, whereas OAuth is 
        a framework and defines various 
        token types with various scopings, some of which are determined by
        the encompassing application. 
        </t>
        
        <t>The Token Binding key pair scoping for those key pairs generated in 
        the context of the first-party and federation use cases defined in this 
        specification (below), and to be used for binding HTTP cookies MUST be at the 
        granularity of "effective top-level domain (public suffix) + 1" (eTLD+1), 
          i.e., at the same granularity at which cookies can be set 
          (see <xref target="RFC6265"/>).  Key pairs used to bind other application
          tokens, such as OAuth tokens, SHOULD adhere to the above eTLD+1
          scoping requirement for those tokens being employed in first-party
          or federation scenarios as described below, e.g., OAuth refresh tokens 
          or Open ID Connect "ID Tokens". See also <xref 
          target="sctn-priv-tbkey-scoping"/>, below.</t>
          
        <t>Scoping rules for other HTTP-based application contexts are outside the scope of 
        this specification.</t>
        
      </section>
      
    </section>

    <section title="First-party Use Cases">
      <t>In a first-party use case, an HTTP server issues a security token
      such as a cookie (or similar) to a client, and expects the client to return
      the security token at a later time, e.g., in order
      to authenticate. Binding the security token to the TLS connection between
      client and server protects the security token from misuse 
      since the server can detect if the security token is
      replayed inappropriately, e.g., over other TLS connections.</t>
      
      <t>See <xref target="I-D.ietf-tokbind-protocol"/> Section 6 for 
      general guidance regarding binding of security tokens and their 
      subsequent validation.</t>
      
    </section>
    
    <section title="Federation Use Cases">

      <section title="Introduction">
	<t>For privacy reasons, clients use different private keys to
	establish Provided Token Binding IDs with different
	servers. As a result, a server cannot bind a security token
	(such as an OAuth token or an OpenID Connect identity token)
	to a TLS connection that the client has with a different
	server. This is, however, a common requirement in federation
	scenarios: For example, an Identity Provider may wish to issue
	an identity token to a client and cryptographically bind that
	token to the TLS connection between the client and a Relying
	Party.</t>
	
	<t>In this section we describe mechanisms to achieve this. The
	common idea among these mechanisms is that a server (called
	the <spanx style="emph">Token Consumer</spanx> in this
	document) signals to the client that it should reveal the Provided
	Token Binding ID that is used between the client and itself,
	to another server (called the <spanx style="emph">Token
	Provider</spanx> in this document). Also common across the
	mechanisms is how the Token Binding ID is revealed to the
	Token Provider: The client uses the <xref
	target="I-D.ietf-tokbind-protocol">Token Binding Protocol</xref>, and
	includes a TokenBinding structure in the Sec-Token-Binding HTTP
	header field defined above.  What differs between the various
	mechanisms is <spanx style="emph">how</spanx> the Token
	Consumer signals to the client that it should reveal the Token Binding ID
	to the Token Provider. Below we specify one such mechanism, which is 
  suitable for redirect-based interactions between Token Consumers and
  Token Providers.</t>
      </section>

      <section title="Overview">
	<t>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 (where the identity token is called "ID
	Token") and SAML (where the identity token is a SAML
	assertion).</t>
	<t>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 in the identity
	token with the Token Binding ID of the TLS connection between it
	and the client.</t>
	<t>This is an example of a federation scenario, which more
	generally can be described as follows:
	<list style="symbols">
	  <t>A Token Consumer causes the client to issue a token request
	  to the Token Provider. The goal is for the client to obtain a
	  token and then use it with the Token Consumer.</t>
	  <t>The client delivers the token request to the Token
	  Provider.</t>
	  <t>The Token Provider issues the token. The token is issued
	  for the specific Token Consumer who requested it (thus
	  preventing malicious Token Consumers from using tokens with
	  other Token Consumers). The token is, however, typically a
	  bearer token, meaning that any client can use it with the
	  Token Consumer, not just the client to which it was
	  issued.</t>
	  <t>Therefore, in the previous step, the Token Provider may
	  want to include in the token the Token-Binding public key that the client
    uses when communicating with the Token Consumer, thus 
    <spanx style="emph">binding</spanx> the token to client's Token-Binding
    keypair. The client
    proves possession of the private key when communicating with 
    the Token Consumer through the <xref target="I-D.ietf-tokbind-protocol">Token
	  Binding Protocol</xref>, and reveals the corresponding public key of this 
    keypair as part of the Token Binding ID. Comparing the public key from the
    token with the public key from the Token Binding ID allows the Token 
    Consumer to verify that the token was sent to it by the legitimate 
    client.</t>
	  <t>To allow the Token Provider to include the Token-Binding public key in
    the token, the Token Binding ID (between client and Token Consumer) must 
    therefore be communicated to the Token Provider along with the token
    request. Communicating a Token Binding ID involves proving possession of a 
    private key and is described in the <xref target="I-D.ietf-tokbind-protocol">Token
	  Binding Protocol</xref>.</t>
	</list>
	</t>
	<t>The client will perform this last operation (proving
	possession of a private key that corresponds to a Token Binding
	ID between the client and the Token Consumer while delivering
	the token request to the Token Provider) only if the Token
	Consumer requests the client to do so.</t>
	<t>Below, we specify how Token Consumers can signal this request in
    redirect-based federation protocols. Note that this assumes that the federated
    sign-on flow starts at the Token Consumer, or at the very least include a redirect
    from Token Consumer to Token Provider. It is outside the scope of this
    document to specify similar mechanisms for flows that do not include such redirects.</t>
      </section>
      
      <section title="HTTP Redirects" anchor="sctn-http-redir">
	<t>When a Token Consumer redirects the client to a Token Provider as a means to deliver the token
	request, it SHOULD include a Include-Referred-Token-Binding-ID HTTP response header field in its
	HTTP response. The ABNF of the Include-Referred-Token-Binding-ID header is (in <xref
	target="RFC7230"/> style, see also <xref target="RFC7231"/> Section 8.3):</t>
	<figure><artwork><![CDATA[
  Include-Referred-Token-Binding-ID = "true"
        ]]></artwork></figure>
        

      <t>Where the header field name is "Include-Referred-Token-Binding-ID", and the 
      field-value of "true" is case-insensitive. For example:</t>
      
      <figure><artwork><![CDATA[
  Include-Referred-Token-Binding-ID: true
        ]]></artwork></figure>
      
	<t>Including this response header field signals to the client that it
	should reveal, to the Token Provider, the Token Binding ID used between itself and
	the Token Consumer. In the absence of this 
        response header field, the client will not disclose any information 
        about the Token Binding used between the client and the Token 
        Consumer to the Token Provider.</t>
	
	<t>As illustrated in <xref target="sctn-fed-example"/>, when a client 
	receives this header field, it should take the TokenBindingID
	of the provided TokenBinding from the referrer and create a referred TokenBinding
	with it to include in the TokenBindingMessage on the redirect request. In other
  words, the Token Binding message in the redirect request to the Token Provider
  now includes one provided binding and one referred binding, the latter constructed
  from the binding between the client and the Token Consumer.</t>

  <t>When a client receives the Include-Referred-Token-Binding-ID header, it includes the 
  referred token binding even if both the Token Provider and the Token Consumer fall 
  under the same eTLD+1 and the provided and referred token binding IDs are the same. 
  Note that the referred token binding is sent only on the request resulting from the 
  redirect and not on any subsequent requests to the Token Provider.</t>
  
  <t>If the Include-Referred-Token-Binding-ID header field is received in response to a
  request that did not include the Token-Binding header field, the client MUST ignore
  the Include-Referred-Token-Binding-ID header field.</t>
	
	<t>This header field has only meaning if the HTTP status code is 301,
	302, 303, 307 or 308, and MUST be ignored by the client for any other status
	codes. If the client supports the Token Binding Protocol, and
	has negotiated the Token Binding Protocol with both the Token
	Consumer and the Token Provider, it already sends the
 Sec-Token-Binding header field to the Token Provider with each HTTP
	request (see above).</t>

	<t>The TokenBindingMessage SHOULD contain a TokenBinding with
	TokenBindingType referred_token_binding. If included, this 
        TokenBinding MUST be signed 
	with the Token Binding key used by the client for connections
	between itself and the Token Consumer (more specifically, the
	web origin that issued the Include-Referred-Token-Binding-ID
	response header field). The Token Binding ID established by this
	TokenBinding is called a <spanx style="emph">Referred Token
	Binding ID</spanx>.</t>
	
	<t>As described above, the TokenBindingMessage MUST
	additionally contain a Provided Token Binding ID, i.e., a
	TokenBinding structure with TokenBindingType
	provided_token_binding, which MUST be signed with the Token
	Binding key used by the client for connections between itself
	and the Token Provider (more specifically, the web origin that
	the token request is being sent to).
 </t>
	
	<t>If for some deployment-specific reason the initial 
	Token Provider ("TP1") needs to redirect the
client to another Token Provider ("TP2"), rather than 
directly back to the Token Consumer, it can be
accomodated using the header fields defined in this 
specification in the following fashion ("the
redirect-chain approach"):
	
	<list>
	<t>Initially, the client is redirected to TP1 by the Token Consumer ("TC"), as described above.
	Upon receiving the client's request, containing a TokenBindingMessage which contains both provided
	and referred TokenBindings (for TP1 and TC, respectively), TP1 responds to the client with a
	redirect response containing the Include-Referred-Token-Binding-ID header field and directing the
	client to send a request to TP2. This causes the client to follow the same pattern and send a
	request containing a TokenBindingMessage which contains both provided and referred TokenBindings
	(for TP2 and TP1, respectively) to TP2. Note that this pattern can continue to further Token
	Providers. In this case, TP2 issues a security token, bound to the client's TokenBinding with TP1,
	and sends a redirect response to the client pointing to TP1. TP1 in turn constructs a security
	token for the Token Consumer, bound to the TC's referred TokenBinding which had been conveyed
	earlier, and sends a redirect response pointing to the TC, containing the bound security token, to
	the client.</t>
	</list>
	
The above is intended as only a non-normative example. Details are specific to deployment
contexts. Other approaches are possible, but are outside the scope of this specification.</t>
      </section>
      
      <section title="Negotiated Key Parameters">
	<t>The <xref target="I-D.ietf-tokbind-negotiation">TLS Extension 
        for Token Binding Protocol Negotiation</xref> allows the server and 
        client to negotiate the parameters (signature algorithm, length) 
        of the Token Binding key. It is possible that the Token
        Binding ID used between the client and the Token Consumer, and
        the Token Binding ID used between the client and Token Provider,
        use different key parameters. The client MUST use the
        key parameters negotiated with the Token Consumer in the
        referred_token_binding TokenBinding of the TokenBindingMessage,
        even if those key parameters are different from the ones 
        negotiated with the origin that the header field is sent to.</t>
        <t>Token Providers SHOULD support all the Token Binding key parameters
        specified in the <xref target="I-D.ietf-tokbind-protocol"/>. 
        If a token provider does not support the key parameters
        specified in the referred_token_binding TokenBinding in the
        TokenBindingMessage, it MUST NOT issue a bound token.</t>
      </section>
      
      <section title="Federation Example" anchor="sctn-fed-example">
        
        
        <t> The diagram below shows a 
           typical HTTP Redirect-based Web Browser SSO Profile
           (no artifact, no callbacks), featuring binding of,
           e.g., a TLS Token Binding ID into an OpenID Connect "ID Token".
        </t>
        
        <texttable>
        <preamble>Legend:</preamble>
        <ttcol></ttcol><ttcol></ttcol>
           <c>EKM:</c>       <c>TLS Exported Keying Material [RFC5705]</c>

           <c>{EKMn}Ksm:</c> <c>EKM for server "n", signed by private key of TBID "m",
                      where "n" must represent server receiving the ETBMSG,
                      if a conveyed TB's type is provided_token_binding, then
                      m = n, else if TB's type is referred_token_binding, then
                      m != n. E.g., see step 1b in diagram below.</c>

           <c>ETBMSG:</c>    <c>"Sec-Token-Binding" HTTP header field conveying an
                      EncodedTokenBindingMessage, in turn conveying
                      TokenBinding (TB)struct(s), e.g.:
                      ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]]</c>

           <c>ID Token:</c>  <c>the "ID Token" in OIDC, it is the semantic equivalent
                      of a SAML "authentication assertion". "ID Token w/TBIDn"
                      denotes a "token bound" ID Token containing TBIDn.</c>

           <c>Ks &amp; Kp:</c>   <c>private (aka secret) key, and public key, respectively,
                      of client-side Token Binding key pair</c>

           <c>OIDC:</c>      <c>Open ID Connect</c>

           <c>TB:</c>        <c>TokenBinding struct containing signed EKM, TBID, and
                      TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding]</c>

           <c>TBIDn:</c>     <c>Token Binding ID for client and server n's token-bound
                      TLS association. TBIDn contains Kpn.</c>
           </texttable>


<figure><artwork><![CDATA[
 Client,                      Token Consumer,       Token Provider,
 aka:                         aka:                  aka:
 User Agent                   OpenID Client,        OpenID Provider,
                              OIDC Relying Party,   OIDC Provider,
                              SAML Relying Party    SAML Identity Provider
                              [ server "1" ]        [ server "2" ]
 +--------+                        +----+                +-----+
 | Client |                        | TC |                | TP  |
 +--------+                        +----+                +-----+
     |                               |                      |
     |                               |                      |
     |                               |                      |
     | 0. Client interacts w/TC      |                      |
     | over HTTPS, establishes Ks1 & Kp1, TBID1             |
     | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]     |
     |------------------------------>|                      |
     |                               |                      |
     |                               |                      |
     |                               |                      |
     | 1a. OIDC ID Token request, aka|                      |
     | "Authentication Request", conveyed with              |
     | HTTP response header field of:                       |
     | Include-Referred-Token-Binding-ID:true               |
     | any security-relevant cookies |                      |
     | should contain TBID1          |                      |
   +<- - - - - - - - - - - - - - - - |                      |
   . | (redirect to TP via 301, 302, |                      |
   . |  303, 307, or 308)            |                      |
   . |                               |                      |
   +------------------------------------------------------->|
     | 1b. opens HTTPS w/TP,                                |
     | establishes Ks2, Kp2, TBID2;                         |
     | sends GET or POST with                               |
     | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding],     |
     |        [{EKM2}Ks1,TBID1,referred_token_binding]]     |
     | as well as the ID Token request                      |
     |                               |                      |
     |                               |                      |
     |                               |                      |
     | 2. user authentication (if applicable,               |
     |    methods vary, particulars are out of scope)       |
     |<====================================================>|
     | (TP generates ID Token for TC containing TBID1, may  |
     |  also set cookie(s) containing TBID2 and/or TBID1,   |
     |  details vary, particulars are out of scope)         |
     |                               |                      |
     |                               |                      |
     |                               |                      |
     | 3a. ID Token containing Kp1, issued for TC,          |
     |    conveyed via OIDC "Authentication Response"       |
   +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -|
   . |   (redirect to TC)            |                      |
   . |                               |                      |
   . |                               |                      |
   +-------------------------------->|                      |
     | 3b. HTTPS GET or POST with                           |
     | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]     |
     | conveying Authn Reponse containing                   |
     | ID Token w/TBID1, issued for TC                      |
     |                               |                      |
     |                               |                      |
     |                               |                      |
     | 4. user is signed-on, any security-relevant cookie(s)|
     | that are set SHOULD contain TBID1                    |
     |<------------------------------|                      |
     |                               |                      |
     |                               |                      |        
]]></artwork></figure>
      </section>
      
      
    </section>

    <section title="Implementation Considerations" anchor="impl-cons">
      <t>
        HTTPS-based applications may have multi-party use 
        cases other than, or in addition to, the HTTP redirect-based 
        signaling-and-conveyance of referred token bindings, as 
        presented above in <xref target="sctn-http-redir"/>.
      </t>
      <t>
        Thus, generic Token Binding implementations intended to support 
        any HTTPS-based client-side application (e.g., so-called "native 
        applications"), should provide means for applications to have 
        Token Binding messages, containing Token Binding IDs of various 
        application-specified Token Binding types and for 
        application-specified TLS connections, conveyed over an 
        application-specified HTTPS connection, i.e., within the 
        TokenBindingMessage conveyed by the Sec-Token-Binding header 
        field.
      </t>
      <t>
        However, such applications MUST only convey Token Binding IDs 
        to other servers if the server associated with a Token Binding ID 
        explicitly signals to do so, e.g., by returning an 
        Include-Referred-Token-Binding-ID HTTP response header field.
        <list style="hanging" hangIndent="7">
          <t hangText="NOTE:">
            See <xref target="privacy-cons"/> 
            "<xref target="privacy-cons" format="title"/>",
            for privacy guidance regarding the use of this functionality. 
          </t>
        </list>
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <section title="Security Token Replay">
        <t>The goal of the Federated Token Binding mechanisms is to
        prevent attackers from exporting and replaying tokens used in
        protocols between the client and Token Consumer, thereby
        impersonating legitimate users and gaining access to protected
        resources. Bound tokens can still be replayed by  malware
        present in the client. In order to export the token to
        another machine and successfully replay it, the attacker also
        needs to export the corresponding private key. The Token
        Binding private key is therefore a high-value asset and MUST
        be strongly protected, ideally by generating it in a hardware
        security module that prevents key export.</t>
      </section>
      <section title="Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions">
        <t>The Token Binding protocol relies on the exported key material (EKM)
          value <xref target="RFC5705" /> to associate a TLS connection with a
          TLS Token Binding. The triple handshake attack <xref target="TRIPLE-HS" /> 
          is a known vulnerability in TLS 1.2 and older TLS versions, allowing the 
          attacker to synchronize keying material between TLS connections. The 
          attacker can then successfully replay bound tokens. For this reason, the Token 
          Binding protocol MUST NOT be negotiated with these TLS versions, unless the 
          Extended Master Secret <xref target="RFC7627" /> TLS extension has also been 
          negotiated. In addition, TLS renegotiation MUST NOT be initiated or allowed, 
          unless the Renegotiation Indication <xref target="RFC5746" /> TLS extension 
          has been negotiated.</t>
      </section>
      <section title="Sensitivity of the Sec-Token-Binding Header">
        <t>
          The purpose of the Token Binding protocol is to convince the server
          that the client that initiated the TLS connection controls a certain
          key pair. For the server to correctly draw this conclusion after
          processing the Sec-Token-Binding header field, certain secrecy and integrity
          requirements must be met.
        </t>
        <t>
          For example, the client's private Token Binding key must be kept
          secret by the client. If the private key is not secret, then another
          actor in the system could create a valid Token Binding header field,
          impersonating the client. This can render the main purpose of the
          protocol - to bind bearer tokens to certain clients - moot: Consider,
          for example, an attacker who obtained (perhaps through a network
          intrusion) an authentication cookie that a client uses with a certain
          server. Consider further that the server bound that cookie to the
          client's Token Binding ID precisely to thwart misuse of the cookie. If the
          attacker were to come into possession of the client's private key, he
          could then establish a TLS connection with the server and craft a
          Sec-Token-Binding header field that matches the binding present in the cookie,
          thus successfully authenticating as the client, and gaining access to
          the client's data at the server. The Token Binding protocol, in this
          case, did not successfully bind the cookie to the client.
        </t>
        <t>
          Likewise, we need integrity protection of the Sec-Token-Binding header field: A
          client should not be tricked into sending a Sec-Token-Binding header field to a
          server that contains Token Binding messages about key pairs that the
          client does not control. Consider an attacker A that somehow has
          knowledge of the exported keying material (EKM) for a TLS connection
          between a client C and a server S. (While that is somewhat unlikely,
          it is also not entirely out of the question, since the client might
          not treat the EKM as a secret - after all, a pre-image-resistant hash
          function has been applied to the TLS master secret, making it
          impossible for someone knowing the EKM to recover the TLS master
          secret. Such considerations might lead some clients to not treat the
          EKM as a secret.) Such an attacker A could craft a Sec-Token-Binding
          header field with A's key pair over C's EKM. If the attacker could now
          trick C to send such a header field to S, it would appear to S as if C
          controls a certain key pair when in fact it does not (the attacker A
          controls the key pair).
        </t>
        <t>
          If A has a pre-existing relationship with S (perhaps has an account
          on S), it now appears to the server S as if A is connecting to it,
          even though it is really C. (If the server S does not simply use Token
          Binding keys to identify clients, but also uses bound authentication
          cookies, then A would also have to trick C into sending one of A's
          cookies to S, which it can do through a variety of means - inserting
          cookies through Javascript APIs, setting cookies through
          related-domain attacks, etc.) In other words, A tricked C into
          logging into A's account on S. This could lead to a loss of privacy
          for C, since A presumably has some other way to also access the
          account, and can thus indirectly observe A's behavior (for example,
          if S has a feature that lets account holders see their activity
          history on S).
        </t>
        <t>
          Therefore, we need to protect the integrity of the Sec-Token-Binding
          header field. One origin should not be able to set the Sec-Token-Binding header field
          (through a DOM API or otherwise) that the User Agent uses with
          another origin. Employing the "Sec-" header field prefix helps to meet this 
          requirement by denoting the header field name to be a "forbidden header name",
          see <xref target="fetch-spec"/>. 
        </t>
      </section>
      <section title="Securing Federated Sign-On Protocols">
        <t>
          As explained above, in a federated sign-in scenario a client will
          prove possession of two different key pairs to a Token Provider: One
          key pair is the "provided" Token Binding key pair (which the client
          normally uses with the Token Provider), and the other is the
          "referred" Token Binding key pair (which the client normally uses
          with the Token Consumer). The Token Provider is expected to issue a
          token that is bound to the referred Token Binding key.
        </t>
        <t>
          Both proofs (that of the provided Token Binding key and that of the
          referred Token Binding key) are necessary. To show this, consider the
          following scenario:
          <list style="symbols">
            <t>
              The client has an authentication token with the Token Provider
              that is bound to the client's Token Binding key.
            </t>
            <t>
              The client wants to establish a secure (i.e., free of
              men-in-the-middle) authenticated session with the Token Consumer,
              but has not done so yet (in other words, we are about to run the
              federated sign-on protocol).
            </t>
            <t>
              A man-in-the-middle is allowed to intercept the connection
              between client and Token Consumer or between Client and Token
              Provider (or both).
            </t>
          </list>
          The goal is to detect the presence of the man-in-the-middle in these
          scenarios.
        </t>
        <t>
          First, consider a man-in-the-middle between the client and the Token
          Provider. Recall that we assume that the client possesses a bound
          authentication token (e.g., cookie) for the Token Provider. The
          man-in-the-middle can intercept and modify any message sent by the
          client to the Token Provider, and any message sent by the Token
          Provider to the client. (This means, among other things, that the
          man-in-the-middle controls the Javascript running at the client in
          the origin of the Token Provider.) It is not, however, in possession
          of the client's Token Binding key. Therefore, it can either choose to
          replace the Token Binding key in requests from the client to the
          Token Provider, and create a Sec-Token-Binding header field that matches the
          TLS connection between the man-in-the-middle and the Token Provider;
          or it can choose to leave the Sec-Token-Binding header field unchanged. If it
          chooses the latter, the signature in the Token Binding message
          (created by the original client on the exported keying material (EKM)
          for the connection between client and man-in-the-middle) will not
          match the EKM between man-in-the-middle and the Token Provider. If it
          chooses the former (and creates its own signature, with its own Token
          Binding key, over the EKM for the connection between
          man-in-the-middle and Token Provider), then the Token Binding message
          will match the connection between man-in-the-middle and Token
          Provider, but the Token Binding key in the message will not match the
          Token Binding key that the client's authentication token is bound to.
          Either way, the man-in-the-middle is detected by the Token Provider,
          but only if the proof of key possession of the provided Token Binding
          key is required in the protocol (as we do above).
        </t>
        <t>
          Next, consider the presence of a man-in-the-middle between client and
          Token Consumer. That man-in-the-middle can intercept and modify any
          message sent by the client to the Token Consumer, and any message
          sent by the Token Consumer to the client. The Token Consumer is the
          party that redirects the client to the Token Provider. In this case,
          the man-in-the-middle controls the redirect URL, and can tamper with
          any redirect URL issued by the Token Consumer (as well as with any
          Javascript running in the origin of the Token Consumer). The goal of
          the man-in-the-middle is to trick the Token Issuer to issue a token
          bound to <spanx style="emph">its</spanx> Token Binding key, not to
          the Token Binding key of the legitimate client. To thwart this goal
          of the man-in-the-middle, the client's referred Token Binding key
          must be communicated to the Token Producer in a manner that can not
          be affected by the man-in-the-middle (who, as we recall, can modify
          redirect URLs and Javascript at the client). Including the referred
          Token Binding message in the Sec-Token-Binding header field (as opposed to,
          say, including the referred Token Binding key in an application-level
          message as part of the redirect URL) is one way to assure that the
          man-in-the-middle between client and Token Consumer cannot affect the
          communication of the referred Token Binding key to the Token Provider.
        </t>
        <t>
          Therefore, the Sec-Token-Binding header field in the federated sign-on use case
          contains both, a proof of possession of the provided Token Binding
          key, as well as a proof of possession of the referred Token Binding
          key.
        </t>
      </section>
    </section>
    <section title="Privacy Considerations" anchor="privacy-cons">
      <section title="Scoping of Token Binding Keys" anchor="sctn-priv-tbkey-scoping">
        <t>Clients use different Token Binding key pairs for different servers, so as 
          to not allow Token Binding to become a tracking tool across different servers.
          However, the scoping of the Token Binding key pairs to servers varies according
          to the scoping rules of the application protocol (<xref 
          target="I-D.ietf-tokbind-protocol"/> section 4.1).
        </t>
          
        <t>In the case of HTTP cookies, servers may use Token Binding to secure their cookies. 
          These cookies can be attached to any 
          sub-domain of effective top-level domains, and clients therefore should use the same 
          Token Binding key across such subdomains. This will ensure that any server
          capable of receiving the cookie will see the same Token Binding ID from 
          the client, and thus be able to verify the token binding of the cookie.
          See <xref target="sctn-keypair-scope"/>, above. 
        </t>
      </section>
      <section title="Life Time of Token Binding Keys">
        <t>Token Binding keys do not have an expiration time. This means that they 
          can potentially be used by a server to track a user across an extended
          period of time (similar to a long-lived cookie). HTTPS clients such as 
          web user agents should therefore provide a user interface for discarding
          Token Binding keys (similar to the affordances provided to delete cookies).
        </t>
        <t>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 discard Token
          Binding keys from such modes after the session is over. Generally speaking,
          users should be given the same level of control over life time of Token
          Binding keys as they have over cookies or other potential tracking 
          mechanisms.
        </t>
      </section>
      <section title="Correlation" anchor="Correlation">
        <t>
          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 context, "an application" is a 
          combination of client-side and server-side components, communicating over 
          HTTPS, where the client side may be either or both web browser-based or native 
          application-based). These other Token Binding IDs can serve as correlation 
          handles for the endpoints of the other connections. If the receiving endpoints 
          are otherwise aware of these other connections, then no additional information 
          is being exposed. For instance, if in a redirect-based federation protocol, 
          the Identity Provider and Relying Party already possess URLs for one another, 
          also having Token Binding IDs for these connections does not provide additional 
          correlation information. If not, then, by providing the other Token Binding 
          IDs, additional information is exposed that can be used to correlate the other 
          endpoints. In such cases, a privacy analysis of enabled correlations and their 
          potential privacy impacts should be performed as part of the application design 
          decisions of how, and whether, to utilize Token Binding.
        </t>
        <t>
          Also, applications must take care to only reveal Token Binding IDs to other 
          endpoints if the server associated with a Token Binding ID explicitly signals 
          to do so, see <xref target="impl-cons"/> 
          "<xref target="impl-cons" format="title"/>".
        </t>
        <t>
          Finally, care should be taken to ensure that unrelated applications do not 
          obtain information about each other's Token Bindings. For instance, a Token 
          Binding implementation shared between multiple applications on a given system 
          should prevent unrelated applications from obtaining each other's Token Binding 
          information. This may be accomplished by using techniques such as application 
          isolation and key segregation, depending upon system capabilities.
        </t>
      </section>
    </section> <!-- priv cons -->
    
    <section title="IANA Considerations" anchor="iana-cons">
      <t>
        Below are the Internet Assigned Numbers Authority (IANA)
        Permanent Message Header Field registration
        information per <xref target="RFC3864" />.
      </t>
      <figure>
        <artwork>
  Header field name:           Sec-Token-Binding
  Applicable protocol:         HTTP 
  Status:                      standard
  Author/Change controller:    IETF
  Specification document(s):   this one
        </artwork>
      </figure>
      <figure>
        <artwork>
  Header field name:           Include-Referred-Token-Binding-ID
  Applicable protocol:         HTTP 
  Status:                      standard
  Author/Change controller:    IETF
  Specification document(s):   this one
        </artwork>
      </figure>
    <t>[[TODO: possibly add further considerations wrt the behavior of the above 
    header fields, per &lt;https://tools.ietf.org/html/rfc7231#section-8.3&gt;]]
    </t>

    </section> <!-- IANA cons -->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel 
      Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Nick 
      Harper, Brian Campbell, and others.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      &RFC2119;
      &RFC3864;
      <!-- &RFC4492; -->
      &RFC4648;
      <!-- &RFC5226; -->
      &RFC5246;
      &RFC5705;
      <!-- &RFC5929; -->
      &RFC6265;
      &RFC7230;
      &RFC7231;
      <!-- &RFC7301; -->
      &RFC7541;
      <?rfc include="reference.I-D.ietf-tokbind-negotiation.xml"?>
      <?rfc include="reference.I-D.ietf-tokbind-protocol.xml"?>
      
      <reference anchor="fetch-spec" target="https://fetch.spec.whatwg.org/">
        <front>
          <title>Fetch</title>
          <author>
            <organization>WhatWG</organization>
          </author>
          <date />
        </front>
        <seriesInfo name="Living Standard" value="" />
      </reference>
    </references>

    <references title="Informative References">
      &RFC5746;
      &RFC6749;
      &RFC6750;
      &RFC7540;
      &RFC7627;

      <reference anchor="TRIPLE-HS">
        <front>
          <title>Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over 
          TLS. IEEE Symposium on Security and Privacy</title>
          <author initials="K." surname="Bhargavan">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="A." surname="Delignat-Lavaud">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="C." surname="Fournet">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="A." surname="Pironti">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <author initials="P." surname="Strub">
            <organization>Inria Paris-Rocquencourt</organization>
          </author>
          <date year="2014" />
        </front>
      </reference>
    </references>

    <!-- Change Log
      v00 2014-08-21  Andrei Popov   Initial version
      v00 2015-03-27  Andrei Popov   Renamed as tokbind WG draft
      v01 2015-06-30  Dirk Balfanz   Added Sec- prefix to header
      v02 2015-06-30  Dirk Balfanz   Removed Sec- prefix, added design rationalization in 
                                     Security Considerations section
      v03 2016-03-20  Dirk Balfanz   TB header field has Sec- prefix again;
                                     Add figure of redirect flow for the federation case;
                                     Expand priv considerations: eTLD+1, TB Keys lifetime;
                                     Language tweaks to make it clearer how/when to use referred token bindings;
      v03+ 2016-03-?? Jeff Hodges    Update header field presentation to match rfc7230 style, add
                                     refs, add IANA considerations per BCP90/RFC3864;
      v04 2016-06-22  Andrei Popov   Merged pull request to clarify that the TB messages are sent 
                                     base64url-encoded;
                                     Removed references to SignatureAndHashAlgorithm;
                                     Added references to TBPROTO and TBNEGO;
      v04+ 2016-07-04 Jeff Hodges    Refined TB key pair scoping rules, issue #33;
      v05 2016-07-07  Andrei Popov   Moved TB key parameters IDs registration from TBNEGO to 
                                     TBPROTO;
      v06 2016-07-23  Mike Jones &   Added Implementation Considerations and additional 
                      Jeff Hodges    Privacy Considerations.
                                     [ Mike jones -> Michael Jones -> Michael B. Jones 
                                     (there's too many of me!) ;-) ]
      v06 2016-08-23  Andrei Popov   Merged PRs #54, #57.
      v06 2016-08-26  Andrei Popov   Clarified that renegotiation indication ext. is only needed when renegotiation is enabled.
    -->
  </back>
</rfc>