1- <?xml version =" 1.0" encoding =" utf-8"
1+ <?xml version =" 1.0" encoding =" utf-8"
22<!-- This template is for creating an Internet Draft using xml2rfc,
33 which is available here: http://xml.resource.org. -->
44<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
340340
341341 <t >A TokenBindingMessage is validated by the server as described in Section
342342 4.2. "Server Processing Rules" of <xref target =" I-D.ietf-tokbind-protocol"
343- If validaion fails and a Token Binding is rejected, any associated bound
343+ If validation fails and a Token Binding is rejected, any associated bound
344344 tokens MUST also be rejected by the server. HTTP requests containing invalid
345- tokens MUST be rejected. In this case, the server application may return HTTP
345+ tokens MUST be rejected. In this case, the server application MAY return HTTP
346346 status code 400 (Bad Request) or proceed with an application-specific invalid
347347 token response (e.g. directing the client to re-authenticate and present a
348348 different token), or terminate the connection.</t >
408408 </section >
409409
410410 <section title =" First-party Use Cases"
411- <t >In a first-party use case, an HTTP server issues a security token
411+ <t >In a first-party use case (also known as a
412+ "same-site" use case), an HTTP server issues a security token
412413 such as a cookie (or similar) to a client, and expects the client to return
413414 the security token at a later time, e.g., in order
414415 to authenticate. Binding the security token to the TLS connection between
488489 want to include in the token the Token-Binding public key that the client
489490 uses when communicating with the Token Consumer, thus
490491 <spanx style =" emph" spanx > the token to client's Token-Binding
491- keypair . The client
492+ key pair . The client
492493 proves possession of the private key when communicating with
493494 the Token Consumer through the <xref target =" I-D.ietf-tokbind-protocol"
494495 Binding Protocol</xref >, and reveals the corresponding public key of this
495- keypair as part of the Token Binding ID. Comparing the public key from the
496+ key pair as part of the Token Binding ID. Comparing the public key from the
496497 token with the public key from the Token Binding ID allows the Token
497498 Consumer to verify that the token was sent to it by the legitimate
498499 client.</t >
571572 TokenBinding MUST be signed
572573 with the Token Binding key used by the client for connections
573574 between itself and the Token Consumer (more specifically, the
574- web origin that issued the Include-Referred-Token-Binding-ID
575+ server that issued the Include-Referred-Token-Binding-ID
575576 response header field). The Token Binding ID established by this
576577 TokenBinding is called a <spanx style =" emph"
577578 Binding ID</spanx >.</t >
578579
579580 <t >As described above, the TokenBindingMessage MUST
580581 additionally contain a Provided Token Binding ID, i.e., a
581- TokenBinding structure with TokenBindingType
582+ TokenBinding structure with TokenBindingType of
582583 provided_token_binding, which MUST be signed with the Token
583584 Binding key used by the client for connections between itself
584- and the Token Provider (more specifically, the web origin that
585+ and the Token Provider (more specifically, the server that
585586 the token request is being sent to).
586587 </t >
587588
588589 <t >If for some deployment-specific reason the initial
589590 Token Provider ("TP1") needs to redirect the
590591client to another Token Provider ("TP2"), rather than
591592directly back to the Token Consumer, it can be
592- accomodated using the header fields defined in this
593+ accommodated using the header fields defined in this
593594specification in the following fashion ("the
594595redirect-chain approach"):
595596
@@ -623,9 +624,9 @@ contexts. Other approaches are possible, but are outside the scope of this speci
623624 key parameters negotiated with the Token Consumer in the
624625 referred_token_binding TokenBinding of the TokenBindingMessage,
625626 even if those key parameters are different from the ones
626- negotiated with the origin that the header field is sent to.</t >
627+ negotiated with the server that the header field is sent to.</t >
627628 <t >Token Providers SHOULD support all the Token Binding key parameters
628- specified in the <xref target =" I-D.ietf-tokbind-protocol"
629+ specified in <xref target =" I-D.ietf-tokbind-protocol"
629630 If a token provider does not support the key parameters
630631 specified in the referred_token_binding TokenBinding in the
631632 TokenBindingMessage, it MUST NOT issue a bound token.</t >
@@ -731,7 +732,7 @@ contexts. Other approaches are possible, but are outside the scope of this speci
731732 +-------------------------------->| |
732733 | 3b. HTTPS GET or POST with |
733734 | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] |
734- | conveying Authn Reponse containing |
735+ | conveying Authn Response containing |
735736 | ID Token w/TBID1, issued for TC |
736737 | | |
737738 | | |
@@ -771,8 +772,8 @@ contexts. Other approaches are possible, but are outside the scope of this speci
771772 can return an
772773 Include-Referred-Token-Binding-ID HTTP response header field to a Web browser,
773774 thus signaling to the Token Binding implementation in the Web browser
774- that the Web application associated with the server's origin
775- intents to convey the Web browser's Token Binding ID to another server.
775+ that the server
776+ intends to convey the Web browser's Token Binding ID to another server.
776777 Other signaling mechanisms are possible, and are specific to the application
777778 layer protocol, but are outside the scope of this specification.
778779 <list style =" hanging" hangIndent =" 7"
@@ -791,12 +792,13 @@ contexts. Other approaches are possible, but are outside the scope of this speci
791792 prevent attackers from exporting and replaying tokens used in
792793 protocols between the client and Token Consumer, thereby
793794 impersonating legitimate users and gaining access to protected
794- resources. Bound tokens can still be replayed by malware
795- present in the client. In order to export the token to
796- another machine and successfully replay it, the attacker also
797- needs to export the corresponding private key. The Token
798- Binding private key is therefore a high-value asset and MUST
799- be strongly protected, ideally by generating it in a hardware
795+ resources. Although bound tokens can still be replayed by any malware
796+ present in clients (which may be undetectable by a server),
797+ in order to export bound tokens to
798+ other machines and successfully replay them, attackers also
799+ need to export the corresponding Token Binding private keys. Token
800+ Binding private keys are therefore high-value assets and SHOULD
801+ be strongly protected, ideally by generating them in a hardware
800802 security module that prevents key export.</t >
801803 </section >
802804 <section title =" Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions"
@@ -870,9 +872,9 @@ contexts. Other approaches are possible, but are outside the scope of this speci
870872 </t >
871873 <t >
872874 Therefore, we need to protect the integrity of the Sec-Token-Binding
873- header field. One origin should not be able to set the Sec-Token-Binding header field
875+ header field. One eTLD+1 should not be able to set the Sec-Token-Binding header field
874876 (through a DOM API or otherwise) that the User Agent uses with
875- another origin . Employing the "Sec-" header field prefix helps to meet this
877+ another eTLD+1 . Employing the "Sec-" header field prefix helps to meet this
876878 requirement by denoting the header field name to be a "forbidden header name",
877879 see <xref target =" fetch-spec"
878880 </t >
@@ -955,7 +957,7 @@ contexts. Other approaches are possible, but are outside the scope of this speci
955957 must be communicated to the Token Producer in a manner that can not
956958 be affected by the man-in-the-middle (who, as we recall, can modify
957959 redirect URLs and Javascript at the client). Including the referred
958- Token Binding message in the Sec-Token-Binding header field (as opposed to,
960+ Token Binding structure in the Sec-Token-Binding header field (as opposed to,
959961 say, including the referred Token Binding key in an application-level
960962 message as part of the redirect URL) is one way to assure that the
961963 man-in-the-middle between client and Token Consumer cannot affect the
@@ -979,7 +981,8 @@ contexts. Other approaches are possible, but are outside the scope of this speci
979981 </t >
980982 <t >In the case of HTTP cookies, servers may use Token Binding to secure their cookies.
981983 These cookies can be attached to any
982- sub-domain of effective top-level domains, and clients therefore should use the same
984+ sub-domain of effective top-level domains (eTLDs),
985+ and clients therefore should use the same
983986 Token Binding key across such subdomains. This will ensure that any server
984987 capable of receiving the cookie will see the same Token Binding ID from
985988 the client, and thus be able to verify the token binding of the cookie.
@@ -993,7 +996,7 @@ contexts. Other approaches are possible, but are outside the scope of this speci
993996 permissible to use different Token Binding key scoping rules, such as
994997 using the same Token Binding key for both the Relying Party and the Identity
995998 Provider. Absent such special knowledge, conservative key-scoping rules
996- should be used, assuring that clients use different Token Binding keys
999+ should be used, assuring that clients use different Token Binding key pairs
9971000 with different servers.
9981001 </t >
9991002 </section >
@@ -1190,6 +1193,7 @@ contexts. Other approaches are possible, but are outside the scope of this speci
11901193 v07 2016-11-22 Andrei Popov Merged PR #81: renegotiation requirements.
11911194 v08 2016-12-06 Jeff Hodges Init -08.
11921195 v08 2016-12-06 Jeff Hodges Add explanation of splitting across renego boundaries.
1196+ v08 2016-12-14 Jeff Hodges Various editorial cleanups.
11931197 -->
11941198 </back >
11951199</rfc >
0 commit comments