diff options
Diffstat (limited to 'doc/rfc/rfc8473.txt')
| -rw-r--r-- | doc/rfc/rfc8473.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8473.txt b/doc/rfc/rfc8473.txt new file mode 100644 index 0000000..963ba29 --- /dev/null +++ b/doc/rfc/rfc8473.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Popov +Request for Comments: 8473 M. Nystroem +Category: Standards Track Microsoft Corp. +ISSN: 2070-1721 D. Balfanz, Ed. + N. Harper + Google Inc. + J. Hodges + Kings Mountain Systems + October 2018 + + + Token Binding over HTTP + +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 that it issues to a client -- and that the client + subsequently returns to the server -- to the TLS connection between + the client and the 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 document is a companion document to "The Token Binding Protocol + Version 1.0" (RFC 8471). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8473. + + + + +Popov, et al. Standards Track [Page 1] + +RFC 8473 Token Binding over HTTP October 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. The Sec-Token-Binding HTTP Request Header Field . . . . . . . 4 + 2.1. HTTPS Token Binding Key-Pair Scoping . . . . . . . . . . 5 + 3. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . . . 6 + 4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 7 + 5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 + 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10 + 5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12 + 5.5. Federation Example . . . . . . . . . . . . . . . . . . . 13 + 6. Implementation Considerations . . . . . . . . . . . . . . . . 15 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 16 + 7.2. Sensitivity of the Sec-Token-Binding Header . . . . . . . 16 + 7.3. Securing Federated Sign-On Protocols . . . . . . . . . . 17 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 + 8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 20 + 8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20 + 8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 21 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . 23 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + + + + + + + +Popov, et al. Standards Track [Page 2] + +RFC 8473 Token Binding over HTTP October 2018 + + +1. Introduction + + The Token Binding protocol [RFC8471] defines a 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 public key of a + private-public key pair. The client proves possession of the + corresponding private key. This Token Binding key pair is + long-lived. That is, subsequent TLS connections between the same + client and server have the same Token Binding ID, unless specifically + reset, e.g., by the user. When issuing a security token (e.g., an + HTTP cookie or an OAuth token [RFC6749]) 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 (reuse, attempted + impersonation, etc.) by attackers. + + While the Token Binding protocol [RFC8471] 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 1.1 [RFC7230] and 2 [RFC7540]). Note that + TokenBindingMessages are only defined if the underlying transport + uses TLS. This means that Token Binding over HTTP is only defined + when HTTP is layered on top of TLS (commonly referred to as HTTPS + [RFC2818]). + + 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. + + A TokenBindingMessage allows a client to establish multiple Token + Binding IDs with the server by including multiple TokenBinding + structures. By default, a client will establish a Provided 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 Referred Token Binding ID + in the TokenBindingMessage, indicating a Token Binding ID that the + client is using with a different server than the one that the + TokenBindingMessage is sent to. This is useful in federation + scenarios. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + +Popov, et al. Standards Track [Page 3] + +RFC 8473 Token Binding over HTTP October 2018 + + +2. The Sec-Token-Binding HTTP Request Header Field + + Once a client and server have negotiated the Token Binding protocol + with HTTP/1.1 or HTTP/2 (see [RFC8471] and [RFC8472]), clients MUST + include a Sec-Token-Binding header field in their HTTP requests and + MUST include only one such header field per HTTP request. Also, the + Sec-Token-Binding header field MUST NOT be included in HTTP + responses. The ABNF of the Sec-Token-Binding header field is (per + the style of [RFC7230]; see also Section 8.3 of [RFC7231]): + + Sec-Token-Binding = EncodedTokenBindingMessage + + The header field name is Sec-Token-Binding, and its single value, + EncodedTokenBindingMessage, is a base64url encoding of a single + TokenBindingMessage, as defined in [RFC8471]. The base64url encoding + uses the URL and filename safe character set described in Section 5 + of [RFC4648], with all trailing padding characters (i.e., "=") + omitted and without the inclusion of any line breaks, whitespace, or + other additional characters. + + For example: + + Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\ + 9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\ + aOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25Gg\ + mKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA + + (Note that the backslashes and line breaks are provided to ease + readability; they are not part of the actual encoded message.) + + 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 + 400 (Bad Request) HTTP status code. Additionally, the + Sec-Token-Binding header field: + + o SHOULD NOT be stored by origin servers on PUT requests, + + o MAY be listed by a server in a Vary response header field, and + + o MUST NOT be used in HTTP trailers. + + The TokenBindingMessage MUST contain exactly one TokenBinding + structure with a TokenBindingType value 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 key pairs for + different servers; see Section 2.1 below). The Token Binding ID + + + + +Popov, et al. Standards Track [Page 4] + +RFC 8473 Token Binding over HTTP October 2018 + + + established by this TokenBinding is called a "Provided Token + Binding ID". + + The TokenBindingMessage MAY also contain exactly one TokenBinding + structure with a TokenBindingType value of referred_token_binding, as + specified in Section 5.3. In addition to the latter, or rather than + the latter, the TokenBindingMessage MAY contain other TokenBinding + structures. This is specific to the use case in question; such use + cases are outside the scope of this specification. + + A TokenBindingMessage is validated by the server as described in + Section 4.2 ("Server Processing Rules") of [RFC8471]. If validation + fails and a Token Binding is rejected, any associated bound tokens + MUST also be rejected by the server. HTTP requests containing + invalid tokens MUST be rejected. In this case, the server + application MAY return HTTP status code 400 (Bad Request) or proceed + with an application-specific "invalid token" response (e.g., + directing the client to re-authenticate and present a different + token), or terminate the connection. + + In HTTP/2, the client SHOULD use header compression [RFC7541] to + avoid the overhead of repeating the same header field in subsequent + HTTP requests. + +2.1. HTTPS Token Binding Key-Pair Scoping + + 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 that + context, HTTP cookies [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 [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 [RFC6265], whereas OAuth is a framework and + defines various token types with various scopings, some of which are + determined by the encompassing application. + + The scoping of Token Binding key pairs generated by web browsers for + the purpose of binding HTTP cookies MUST be no wider than the + granularity of a "registered domain" (also known as "effective + top-level domain + 1", or "eTLD+1"). An origin's "registered domain" + is the origin's host's public suffix plus the label to its left + (where the term "public suffix" is defined in the "NOTE:" paragraph + in Section 5.3 of [RFC6265] as "a domain that is controlled by a + public registry"). For example, for "https://www.example.com", the + public suffix (eTLD) is "com", and the registered domain (eTLD+1) is + + + +Popov, et al. Standards Track [Page 5] + +RFC 8473 Token Binding over HTTP October 2018 + + + "example.com". User Agents SHOULD use an up-to-date public suffix + list, such as the one maintained by Mozilla [PSL]. + + This means that in practice the scope of a Token Binding key pair is + no larger than the scope of a cookie allowed by a web browser. If a + web browser restricts cookies to a narrower scope than registered + domains, the scope of Token Binding key pairs MAY also be narrower. + This applies to the use of Token Binding key pairs in first-party use + cases, as well as in federation use cases defined in this + specification (Section 5). + + Key pairs used to bind other application tokens, such as OAuth tokens + or "OpenID Connect" ID Tokens [OpenID.Core], SHOULD adhere to the + above eTLD+1 scoping requirement for those tokens being employed in + first-party or federation scenarios. Applications other than web + browsers MAY use different key-pair scoping rules. See also + Section 8.1 below. + + Scoping rules for other HTTP-based application contexts are outside + the scope of this specification. + +3. TLS Renegotiation + + Token Binding over HTTP/1.1 [RFC7230] can be performed in combination + with TLS renegotiation. In this case, renegotiation MUST only occur + between a client's HTTP request and the server's response, the client + MUST NOT send any pipelined requests, and the client MUST NOT + initiate renegotiation. (That is, the client may only send a + renegotiation ClientHello in response to the server's HelloRequest.) + These conditions ensure that both the client and the server can + clearly identify which TLS Exported Keying Material value [RFC5705] + to use when generating or verifying the TokenBindingMessage. This + also prevents a TokenBindingMessage from being split across TLS + renegotiation boundaries due to TLS message fragmentation; see + Section 6.2.1 of [RFC5246]. + + (Note: This document deals with TLS 1.2 and therefore refers to + RFC 5246 (which has been obsoleted by RFC 8446); [TOKENBIND-TLS13] + addresses Token Binding in TLS 1.3.) + + + + + + + + + + + + +Popov, et al. Standards Track [Page 6] + +RFC 8473 Token Binding over HTTP October 2018 + + +4. First-Party Use Cases + + In a first-party use case (also known as a "same-site" 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 the client and the 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. + + See Section 5 of [RFC8471] for general guidance regarding the binding + of security tokens and their subsequent validation. + +5. Federation Use Cases + +5.1. Introduction + + For privacy reasons, clients use different Token Binding key pairs 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 ID Token [OpenID.Core]) 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. + + In this section, we describe mechanisms to achieve this. The common + idea among these mechanisms is that a server (called the "Token + Consumer" 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 "Token Provider" in this + document). Also common across the mechanisms is how the Token + Binding ID is revealed to the Token Provider: the client uses the + Token Binding protocol [RFC8471] and includes a TokenBinding + structure in the Sec-Token-Binding HTTP header field defined above. + What differs between the various mechanisms is how 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. + + + + + + + + + +Popov, et al. Standards Track [Page 7] + +RFC 8473 Token Binding over HTTP October 2018 + + + 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, signature]] | + |----------------------------------------------------->| + | | + | | | + | | | + +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 the Security Assertion Markup Language (SAML) + [OASIS.saml-core-2.0-os] (in which the identity token is a SAML + assertion). + + + + + + +Popov, et al. Standards Track [Page 8] + +RFC 8473 Token Binding over HTTP October 2018 + + + 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 + be described as follows: + + o 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. + + o The client delivers the token request to the Token Provider. + + o 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. + + o Therefore, in the previous step, the Token Provider may want to + include in the token the Token Binding ID (or a cryptographic hash + of it) that the client uses when communicating with the Token + Consumer, thus binding the token to the client's Token Binding key + pair. The client proves possession of the private key when + communicating with the Token Consumer through the Token Binding + protocol [RFC8471] and uses the corresponding public key of this + key pair as a component of the Token Binding ID. Comparing the + Token Binding ID from the token to the Token Binding ID + established with the client allows the Token Consumer to verify + that the token was sent to it by the legitimate client. + + o To allow the Token Provider to include the Token Binding ID in the + token, the Token Binding ID between the client and the 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 Token Binding protocol [RFC8471]. + + The client will perform this last operation only if the Token + Consumer requests the client to do so. + + + + + + +Popov, et al. Standards Track [Page 9] + +RFC 8473 Token Binding over HTTP October 2018 + + + 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, includes a redirect from the Token Consumer to the Token + Provider. It is outside the scope of this document to specify + similar mechanisms for flows that do not include such redirects. + +5.3. HTTP Redirects + + When a Token Consumer redirects the client to a Token Provider as a + means to deliver the token request, it SHOULD include an + Include-Referred-Token-Binding-ID HTTP response header field in its + HTTP response. The ABNF of the Include-Referred-Token-Binding-ID + header is (per the style of [RFC7230]; see also Section 8.3 of + [RFC7231]): + + Include-Referred-Token-Binding-ID = "true" + + Where the header field name is "Include-Referred-Token-Binding-ID" + and the field value of "true" is case insensitive. For example: + + Include-Referred-Token-Binding-ID: true + + 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. + + As illustrated in Section 5.5, when a client receives this header + field, it should take the TokenBindingID [RFC8471] of the provided + TokenBinding from the referrer and create a referred TokenBinding + with it to include in the TokenBindingMessage in 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. + + 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. + + The referred Token Binding is sent only in the initial request + resulting from the HTTP response that included the + Include-Referred-Token-Binding-ID header. Should the response to + that initial request be a further redirect, the original referred + + + +Popov, et al. Standards Track [Page 10] + +RFC 8473 Token Binding over HTTP October 2018 + + + Token Binding is no longer included in subsequent requests. (A new + referred Token Binding may be included if the redirecting endpoint + itself responded with an Include-Referred-Token-Binding-ID response + header.) + + If the Include-Referred-Token-Binding-ID header field is + received in response to a request that did not include the + Sec-Token-Binding header field, the client MUST ignore the + Include-Referred-Token-Binding-ID header field. + + This header field only has meaning if the HTTP status code is a + redirection code (300-399) and MUST be ignored by the client for any + other status codes. As described in Section 2, 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 sends the Sec-Token-Binding header field to the Token Provider + with each HTTP request. + + The TokenBindingMessage included in the redirect request to the Token + Provider SHOULD contain a TokenBinding with a TokenBindingType value + of referred_token_binding. If included, this TokenBinding MUST be + signed with the Token Binding private key used by the client for + connections between itself and the Token Consumer (more specifically, + the server that issued the Include-Referred-Token-Binding-ID response + header field). The Token Binding ID established by this TokenBinding + is called a "Referred Token Binding ID". + + As described above, the TokenBindingMessage MUST additionally contain + a Provided Token Binding ID, i.e., a TokenBinding structure with a + TokenBindingType value of provided_token_binding, which MUST be + signed with the Token Binding private key used by the client for + connections between itself and the Token Provider (more specifically, + the server that the token request is being sent to). + + 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 + accommodated using the header fields defined in this specification in + the following fashion ("the redirect-chain approach"): + + Initially, the client is redirected to TP1 by the Token Consumer + ("TC"), as described above. Upon receiving a client's request + that contains a TokenBindingMessage that in turn contains both + provided and referred TokenBindings (for TP1 and TC, + respectively), TP1 responds to the client with a redirect response + that (1) contains the Include-Referred-Token-Binding-ID header + field and (2) directs the client to send a request to TP2. This + causes the client to follow the same pattern and send a request + + + +Popov, et al. Standards Track [Page 11] + +RFC 8473 Token Binding over HTTP October 2018 + + + containing a TokenBindingMessage that contains both provided and + referred TokenBindings (for TP2 and TP1, respectively) to TP2. + Note that this pattern can continue to additional 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 that had + been conveyed earlier, and sends a redirect response pointing to + the TC, containing the bound security token, to the client. + + 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. + +5.4. Negotiated Key Parameters + + The TLS extension for Token Binding protocol negotiation [RFC8472] + allows the server and client to negotiate the parameters (signature + algorithm, length) of the Token Binding key pair. 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 the + 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 server that the header field is sent to. + + Token Providers SHOULD support all the Token Binding key parameters + specified in [RFC8471]. 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. + + + + + + + + + + + + + + + + + + + + +Popov, et al. Standards Track [Page 12] + +RFC 8473 Token Binding over HTTP October 2018 + + +5.5. Federation Example + + The diagram below shows a typical HTTP redirect-based web browser + single sign-on (SSO) profile (Section 4.1 of + [OASIS.saml-prof-2.0-os]) (no artifact, no callbacks), featuring the + binding of, for example, a TLS Token Binding ID into an OpenID + Connect ID Token. + + Legend: + + +------------+------------------------------------------------------+ + | EKM: | TLS Exported Keying Material [RFC5705] | + | | | + | {EKMn}Ksm: | EKM for server "n", signed by the private key of | + | | TBID "m", where "n" must represent the 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. For | + | | example, see step 1b in the diagram below. | + | | | + | ETBMSG: | "Sec-Token-Binding" HTTP header field conveying an | + | | EncodedTokenBindingMessage, in turn conveying | + | | TokenBinding (TB)struct(s), e.g., ETBMSG[[TB]] or | + | | ETBMSG[[TB1],[TB2]] | + | | | + | ID Token: | the ID Token in OpenID Connect. It is the semantic | + | | equivalent of a SAML "authentication assertion". | + | | "ID Token w/TBIDn" denotes a "token bound" ID Token | + | | containing TBIDn. | + | | | + | Ks and Kp: | private (aka secret) key and public key, | + | | respectively, of the client-side Token Binding key | + | | pair | + | | | + | OIDC: | OpenID Connect | + | | | + | TB: | TokenBinding struct containing a signed EKM, TBID, | + | | and TB type, e.g., | + | | [{EKM1}Ks1,TBID1,provided_token_binding] | + | | | + | TBIDn: | Token Binding ID for client and server n's token- | + | | bound TLS association. TBIDn contains Kpn. | + +------------+------------------------------------------------------+ + + + + + + + + +Popov, et al. Standards Track [Page 13] + +RFC 8473 Token Binding over HTTP October 2018 + + +Client, aka Token Consumer, aka Token Provider, 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 and Kp1, TBID1 | + | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | + |------------------------------>| | + | | | + | | | + | | | + | 1a. OIDC ID Token request, aka| | + | "Authentication Request", conveyed with | + | an 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 a 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) | + | | | + | | | + + + + + +Popov, et al. Standards Track [Page 14] + +RFC 8473 Token Binding over HTTP October 2018 + + + | | | + | 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 an Authentication Response containing | + | an ID Token w/TBID1, issued for TC | + | | | + | | | + | | | + | 4. user is signed on; any security-relevant cookie(s)| + | that is set SHOULD contain TBID1 | + |<------------------------------| | + | | | + | | | + +6. Implementation Considerations + + 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 Section 5.3. + + Thus, Token Binding implementations should provide APIs for such + applications to generate Token Binding messages containing Token + Binding IDs of various application-specified Token Binding types, to + be conveyed by the Sec-Token-Binding header field. + + However, Token Binding implementations MUST only convey Token Binding + IDs to servers if signaled to do so by an application. Signaling + mechanisms other than the Include-Referred-Token-Binding-ID HTTP + response header field are possible, but these mechanisms are outside + the scope of this specification. + + NOTE: See Section 8 ("Privacy Considerations") for privacy guidance + regarding the use of this functionality. + + + + + + + + + + + +Popov, et al. Standards Track [Page 15] + +RFC 8473 Token Binding over HTTP October 2018 + + +7. Security Considerations + +7.1. Security Token Replay + + The goal of the federated Token Binding mechanisms is to prevent + attackers from exporting and replaying tokens used in protocols + between the client and the Token Consumer, thereby impersonating + legitimate users and gaining access to protected resources. Although + bound tokens can still be replayed by any malware present in clients + (which may be undetectable to a server), in order to export bound + tokens to other machines and successfully replay them, attackers also + need to export the corresponding Token Binding private keys. Token + Binding private keys are therefore high-value assets and SHOULD be + strongly protected, ideally by generating them in a hardware security + module that prevents key export. + + This consideration is a special case of the scenario described in + Section 7.1 ("Security Token Replay") of [RFC8471]. + +7.2. Sensitivity of the Sec-Token-Binding Header + + 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. + + For example, the client must keep its Token Binding private key + secret. If the private key is not secret, then another actor in the + system could create a valid Token Binding header field and thereby + impersonate 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, they 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. + + Likewise, we need integrity protection of the Sec-Token-Binding + header field. A client should not be tricked into sending to a + server a Sec-Token-Binding header field that contains Token Bindings + signed with any Token Binding keys that the client does not control. + + + +Popov, et al. Standards Track [Page 16] + +RFC 8473 Token Binding over HTTP October 2018 + + + 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 into sending 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). + + If A has a pre-existing relationship with S (e.g., 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 IDs 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, in this + scenario, A can trick 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 + C's behavior (for example, if S has a feature that lets account + holders see their activity history on S). + + Therefore, we need to protect the integrity of the Sec-Token-Binding + header field. One eTLD+1 should not be able to set the + Sec-Token-Binding header field (through a Document Object Model (DOM) + API [W3C.REC-DOM-Level-3-Core-20040407] or otherwise) that the User + Agent uses with another eTLD+1. Employing the "Sec-" header field + prefix helps to meet this requirement by denoting the header field + name as a "forbidden header name"; see [fetch-spec]. + +7.3. Securing Federated Sign-On Protocols + + As explained above, in a federated sign-on scenario, a client will + prove possession of two different Token Binding private keys to a + Token Provider: one private key corresponds to the "provided" Token + Binding ID (which the client normally uses with the Token Provider), + and the other is the Token Binding private key corresponding to the + "referred" Token Binding ID (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 ID. + + + + + +Popov, et al. Standards Track [Page 17] + +RFC 8473 Token Binding over HTTP October 2018 + + + Both proofs (that of the provided Token Binding private key and that + of the referred Token Binding private key) are necessary. To show + this, consider the following scenario: + + o The client has an authentication token with the Token Provider + that is bound to the client's Token Binding ID used with that + Token Provider. + + o The client wants to establish a secure (i.e., free of men-in-the- + middle) authenticated session with the Token Consumer but has not + yet done so (in other words, we are about to run the federated + sign-on protocol). + + o A man-in-the-middle is allowed to intercept the connection between + the client and the Token Consumer or between the client and the + Token Provider (or both). + + The goal is to detect the presence of the man-in-the-middle in these + scenarios. + + 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 private key. Therefore, it can choose + to either (1) replace the Token Binding ID 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 (2) 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 EKM for + the connection between the client and the man-in-the-middle) will not + match a signature on the EKM between the man-in-the-middle and the + Token Provider. If it chooses the former (and creates its own + signature, using its own Token Binding private key, over the EKM for + the connection between itself, the man-in-the-middle, and the Token + Provider), then the Token Binding message will match the connection + between the man-in-the-middle and the Token Provider, but the Token + Binding ID in the message will not match the Token Binding ID 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 possession of the provided Token Binding private key is + required in the protocol (as is done above). + + + + +Popov, et al. Standards Track [Page 18] + +RFC 8473 Token Binding over HTTP October 2018 + + + Next, consider the presence of a man-in-the-middle between the client + and the 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 Provider into + issuing a token bound to its Token Binding ID and not to the Token + Binding ID of the legitimate client. To thwart this goal of the + man-in-the-middle, the client's Referred Token Binding ID must be + communicated to the Token Provider in a manner that cannot be + affected by the man-in-the-middle (who, as mentioned above, can + modify redirect URLs and JavaScript at the client). Including the + referred TokenBinding structure in the Sec-Token-Binding header field + (as opposed to, say, including the Referred Token Binding ID in an + application-level message as part of the redirect URL) is one way to + assure that the man-in-the-middle between the client and the Token + Consumer cannot affect the communication of the Referred Token + Binding ID to the Token Provider. + + 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 and a proof of possession of the referred Token + Binding key. + + Note that the presence of Token Binding does not relieve the Token + Provider and Token Consumer from performing various checks to ensure + the security of clients during the use of federated sign-on + protocols. These include the following: + + o The Token Provider should not issue tokens to Token Consumers that + have been shown to act maliciously. To aid in this, the + federation protocol should identify the Token Consumer to the + Token Provider (e.g., through OAuth client IDs or similar + mechanisms), and the Token Provider should ensure that tokens are + indeed issued to the Token Consumer identified in the token + request (e.g., by verifying that the redirect URI is associated + with the OAuth client ID). + + + + + + + + + + + +Popov, et al. Standards Track [Page 19] + +RFC 8473 Token Binding over HTTP October 2018 + + + o The Token Consumer should verify that the tokens were issued for + it and not for some other Token Consumer. To aid in this, the + federation protocol should include an audience parameter in the + token response or apply equivalent mechanisms (the implicit OAuth + flow requires Token Consumers to identify themselves when they + exchange OAuth authorization codes for OAuth refresh tokens, + leaving it up to the Token Provider to verify that the OAuth + authorization was delivered to the correct Token Consumer). + +8. Privacy Considerations + +8.1. Scoping of Token Binding Key Pairs + + 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 (Section 4.1 of [RFC8471]). + + In the case of HTTP cookies, servers may use Token Binding to secure + their cookies. These cookies can be attached to any subdomain of + effective top-level domains (eTLDs), and clients therefore should use + the same Token Binding key pair 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 Section 2.1 above. + + If the client application is not a web browser, it may have + additional knowledge about the relationship between different + servers. For example, the client application might be aware of the + fact that two servers play the roles of Relying Party and Identity + Provider, respectively, in a federated sign-on protocol and that they + therefore share the identity of the user. In such cases, it is + permissible to use different Token Binding key-pair scoping rules, + such as using the same Token Binding key pair for both the Relying + Party and the Identity Provider. Absent such special knowledge, + conservative key-pair 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 + interface for discarding Token Binding key pairs (similar to the + controls provided for deleting cookies). + + + + +Popov, et al. Standards Track [Page 20] + +RFC 8473 Token Binding over HTTP October 2018 + + + 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 MUST 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 the 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 + context, "an application" is a combination of client-side and + server-side components, communicating over HTTPS, where the client + side may be web-browser-based, native-application-based, or both.) + 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, then also having Token Binding IDs for + these connections does not provide additional correlation + information. If not, by providing the other Token Binding IDs, + additional information is then 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. + + Also, Token Binding implementations must take care to only reveal + Token Binding IDs to other endpoints if signaled to do so by the + application associated with a Token Binding ID; see Section 6 + ("Implementation Considerations"). + + 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. + + + + + + + + + +Popov, et al. Standards Track [Page 21] + +RFC 8473 Token Binding over HTTP October 2018 + + +9. IANA Considerations + + Below is the Internet Assigned Numbers Authority (IANA) "Permanent + Message Header Field Names" registration information per [RFC3864]. + + Header Field name: Sec-Token-Binding + Protocol: HTTP + Status: standard + Reference: This document + + Header Field name: Include-Referred-Token-Binding-ID + Protocol: HTTP + Status: standard + Reference: This document + +10. References + +10.1. Normative References + + [PSL] Mozilla, "Public Suffix List", + <https://publicsuffix.org/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <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 + Procedures for Message Header Fields", BCP 90, RFC 3864, + DOI 10.17487/RFC3864, September 2004, + <https://www.rfc-editor.org/info/rfc3864>. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, + <https://www.rfc-editor.org/info/rfc4648>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC5705] Rescorla, E., "Keying Material Exporters for Transport + Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, + March 2010, <https://www.rfc-editor.org/info/rfc5705>. + + + +Popov, et al. Standards Track [Page 22] + +RFC 8473 Token Binding over HTTP October 2018 + + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + DOI 10.17487/RFC6265, April 2011, + <https://www.rfc-editor.org/info/rfc6265>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + <https://www.rfc-editor.org/info/rfc7231>. + + [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for + HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, + <https://www.rfc-editor.org/info/rfc7541>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, + "The Token Binding Protocol Version 1.0", RFC 8471, + DOI 10.17487/RFC8471, October 2018, + <https://www.rfc-editor.org/info/rfc8471>. + + [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport + Layer Security (TLS) Extension for Token Binding Protocol + Negotiation", RFC 8472, DOI 10.17487/RFC8472, October + 2018, <https://www.rfc-editor.org/info/rfc8472>. + +10.2. Informative References + + [fetch-spec] + WhatWG, "Fetch", Living Standard, + <https://fetch.spec.whatwg.org/>. + + [OASIS.saml-core-2.0-os] + Cantor, S., Kemp, J., Philpott, R., and E. Maler, + "Assertions and Protocols 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>. + + + + + + + +Popov, et al. Standards Track [Page 23] + +RFC 8473 Token Binding over HTTP October 2018 + + + [OASIS.saml-prof-2.0-os] + Hughes, J., Ed., Cantor, S., Ed., Hodges, J., Ed., Hirsch, + F., Ed., Mishra, P., Ed., Philpott, R., Ed., and E. Maler, + Ed., "Profiles for the OASIS Security Assertion Markup + Language (SAML) V2.0", OASIS Standard + OASIS.saml-profiles-2.0-os, March 2005, + <http://docs.oasis-open.org/security/ + saml/v2.0/saml-profiles-2.0-os.pdf>. + + [OpenID.Core] + Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0 incorporating + errata set 1", November 2014, + <http://openid.net/specs/openid-connect-core-1_0.html>. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + <https://www.rfc-editor.org/info/rfc6749>. + + [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext + Transfer Protocol Version 2 (HTTP/2)", RFC 7540, + DOI 10.17487/RFC7540, May 2015, + <https://www.rfc-editor.org/info/rfc7540>. + + [TOKENBIND-TLS13] + Harper, N., "Token Binding for Transport Layer Security + (TLS) Version 1.3 Connections", Work in Progress, + draft-ietf-tokbind-tls13-01, May 2018. + + [W3C.REC-DOM-Level-3-Core-20040407] + Le Hors, A., Ed., Le Hegaret, P., Ed., Wood, L., Ed., + Nicol, G., Ed., Robie, J., Ed., Champion, M., Ed., and S. + Byrne, Ed., "Document Object Model (DOM) Level 3 Core + Specification", World Wide Web Consortium Recommendation + REC-DOM-Level-3-Core-20040407, April 2004, + <https://www.w3.org/TR/2004/ + REC-DOM-Level-3-Core-20040407>. + + + + + + + + + + + + + + +Popov, et al. Standards Track [Page 24] + +RFC 8473 Token Binding over HTTP October 2018 + + +Acknowledgements + + This document incorporates comments and suggestions offered by Eric + Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony + Nadalin, Michael B. Jones, Bill Cox, Brian Campbell, and others. + + This document was produced under the chairmanship of John Bradley and + Leif Johansson. The area directors included Eric Rescorla, Kathleen + Moriarty, and Stephen Farrell. + +Authors' Addresses + + Andrei Popov + Microsoft Corp. + United States of America + + Email: andreipo@microsoft.com + + + Magnus Nystroem + Microsoft Corp. + United States of America + + Email: mnystrom@microsoft.com + + + Dirk Balfanz (editor) + Google Inc. + United States of America + + Email: balfanz@google.com + + + Nick Harper + Google Inc. + United States of America + + Email: nharper@google.com + + + Jeff Hodges + Kings Mountain Systems + United States of America + + Email: Jeff.Hodges@KingsMountain.com + + + + + + +Popov, et al. Standards Track [Page 25] + |