idnits 2.17.1 draft-ietf-tokbind-ttrp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2018) is 2100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 616 -- Looks like a reference, but probably isn't: '2' on line 618 -- Looks like a reference, but probably isn't: '3' on line 620 ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-12 == Outdated reference: A later version (-14) exists of draft-ietf-tokbind-negotiation-10 == Outdated reference: A later version (-19) exists of draft-ietf-tokbind-protocol-16 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-03) exists of draft-ietf-tokbind-tls13-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track July 27, 2018 5 Expires: January 28, 2019 7 HTTPS Token Binding with TLS Terminating Reverse Proxies 8 draft-ietf-tokbind-ttrp-06 10 Abstract 12 This document defines HTTP header fields that enable a TLS 13 terminating reverse proxy to convey information to a backend server 14 about the validated Token Binding Message received from a client, 15 which enables that backend server to bind, or verify the binding of, 16 cookies and other security tokens to the client's Token Binding key. 17 This facilitates the reverse proxy and backend server functioning 18 together as though they are a single logical server side deployment 19 of HTTPS Token Binding. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 28, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 57 2. HTTP Header Fields and Processing Rules . . . . . . . . . . . 4 58 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. Token Binding ID . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Token Binding Type . . . . . . . . . . . . . . . . . 4 61 2.2. Token Binding ID HTTP Header Fields . . . . . . . . . . . 4 62 2.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4.1. Provided Token Binding ID . . . . . . . . . . . . . . 6 65 2.4.2. Provided and Referred Token Binding IDs . . . . . . . 7 66 2.4.3. Provided and Other Token Binding IDs . . . . . . . . 8 67 3. TLS Versions and Best Practices . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. HTTP Message Header Field Names Registration . . . . . . 10 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 6.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 75 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism 81 that enables HTTP servers to cryptographically bind cookies and other 82 security tokens to a key generated by the client. When the use of 83 Token Binding is negotiated in the TLS [RFC5246] handshake 84 [I-D.ietf-tokbind-negotiation] the client sends an encoded Token 85 Binding Message [I-D.ietf-tokbind-protocol] as a header in each HTTP 86 request, which proves possession of one or more private keys held by 87 the client. The public portion of the keys are represented in the 88 Token Binding IDs of the Token Binding Message and for each one there 89 is a signature over some data, which includes the exported keying 90 material [RFC5705] of the TLS connection. An HTTP server issuing 91 cookies or other security tokens can associate them with the Token 92 Binding ID, which ensures those tokens cannot be used successfully 93 over a different TLS connection or by a different client than the one 94 to which they were issued. 96 A fairly common deployment architecture for HTTPS applications is to 97 have the backend HTTP application servers sit behind a reverse proxy 98 that terminates TLS connections from clients. The proxy is 99 accessible to the internet and dispatches client requests to the 100 appropriate backend server within a private or protected network. 101 The backend servers are not directly accessible by clients and are 102 only reachable through the reverse proxy. The details of such 103 deployments are typically opaque to clients who make requests to the 104 proxy server and see responses as though they originated from the 105 proxy server itself. Although HTTPS is also usually employed between 106 the proxy and the backend server, the TLS connection that the client 107 establishes for HTTPS is between itself and the reverse proxy server. 109 Token Binding facilitates a binding of security tokens to a key held 110 by the client by way of the TLS connection between that client and 111 the server. In a deployment where TLS is terminated by a reverse 112 proxy, however, the TLS connection is between the client and the 113 proxy while the backend server is likely the system that will issue 114 and validate cookies or other security tokens. Additional steps are 115 therefore needed to enable the use of Token Binding in such 116 deployment architectures. In the absence of a standardized approach, 117 different implementations will address it differently, which will 118 make interoperability between such implementations difficult or 119 impossible without complex configurations or custom integrations. 121 This document standardizes HTTP header field names that a TLS 122 terminating reverse proxy (TTRP) adds to requests that it sends to 123 the backend servers. The headers contain information from the 124 validated Token Binding Message sent by the client to the proxy, thus 125 enabling the backend server to bind, or verify the binding of, 126 cookies and other security tokens to the client's Token Binding key. 127 The usage of the headers, both the TTRP adding the headers and the 128 backend application server using the headers to bind cookies or other 129 tokens, are to be configuration options of the respective systems as 130 they will not always be applicable. 132 1.1. Requirements Notation and Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 2. HTTP Header Fields and Processing Rules 142 2.1. Encoding 144 The field-values of the HTTP headers defined herein utilize the 145 following encoded forms. 147 2.1.1. Token Binding ID 149 A Token Binding ID is represented as an "EncodedTokenBindingID", 150 which is thea base64url encoding of the TokenBindingID byte sequence 151 (see section 3 of [I-D.ietf-tokbind-protocol]) using the URL and 152 filename safe alphabet described in Section 5 of [RFC4648], with all 153 trailing pad characters '=' omitted and without the inclusion of any 154 line breaks, whitespace, or other additional characters. ABNF 155 [RFC5234] syntax for "EncodedTokenBindingID" is shown in Figure 1 156 below. 158 EncodedTokenBindingID = *( DIGIT / ALPHA / "-" / "_" ) 160 DIGIT = 161 ALPHA = 163 Figure 1: Encoded Token Binding ID ABNF 165 2.1.2. Token Binding Type 167 A Token Binding type value (a single byte) can be represented as an 168 "EncodedTokenBindingType", which is a case-insensitive hex encoding 169 (Section 8 of [RFC4648]). The ABNF definition is shown in Figure 2 170 below. 172 EncodedTokenBindingType = 1*2HEXDIG 174 HEXDIG = 176 Figure 2: Encoded Token Binding Type ABNF 178 2.2. Token Binding ID HTTP Header Fields 180 The Token Binding Protocol [I-D.ietf-tokbind-protocol] recommends 181 that implementations make Token Binding IDs available to the 182 application as opaque byte sequences, enabling those applications to 183 use the Token Binding IDs when generating and verifying bound tokens. 184 In the context of a TLS terminating reverse proxy (TTRP) deployment, 185 the TTRP makes the Token Binding ID(s) available to the backend 186 application with the following header fields. 188 Sec-Provided-Token-Binding-ID 189 The Token Binding ID of the provided Token Binding represented as 190 an "EncodedTokenBindingID". 192 Sec-Referred-Token-Binding-ID 193 The Token Binding ID of the referred Token Binding represented as 194 an "EncodedTokenBindingID". 196 Sec-Other-Token-Binding-ID 197 Additional Token Bindings that are sent by the client and 198 validated by the TTRP are represented as a comma-separated list of 199 the concatenation of the "EncodedTokenBindingType", a period (".") 200 character, and the "EncodedTokenBindingID" of each. 202 Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding- 203 ID" are single HTTP header field-valued as defined in Section 3.2 of 204 [RFC7230], which MUST NOT have a list of values or occur multiple 205 times in a request. 207 All header fields defined herein are only for use in HTTP requests 208 and MUST NOT to be used in HTTP responses. 210 2.3. Processing Rules 212 This section defines the applicable processing rules for a TLS 213 terminating reverse proxy (TTRP) and backend server(s) to provide 214 server side support of Token Binding over HTTP 215 [I-D.ietf-tokbind-https] using the HTTP headers described in 216 Section 2.2. Use of the technique is to be a configuration or 217 deployment option and the processing rules described herein are for 218 servers operating with that option enabled. 220 A TTRP negotiates the use of Token Binding with the client, such as 221 is described in [I-D.ietf-tokbind-negotiation] and validates the 222 Token Binding Message as defined in The Token Binding Protocol 223 [I-D.ietf-tokbind-protocol] and Token Binding over HTTP 224 [I-D.ietf-tokbind-https] for each HTTP request on the underlying TLS 225 connection. Requests with a valid Token Binding Message (and meeting 226 any other authorization or policy requirements of the TTRP) are 227 dispatched to the backend server with the following modifications. 229 1. The "Sec-Token-Binding" header in the original incoming request 230 MUST be removed from the request that is dispatched to the 231 backend server. 233 2. The Token Binding ID of the provided Token Binding of the Token 234 Binding Message MUST be placed in the "Sec-Provided-Token- 235 Binding-ID" header field of the dispatched request using the 236 format defined in Section 2.2. 238 3. If the Token Binding Message contains a referred Token Binding, 239 the referred Token Binding ID MUST be placed in the "Sec- 240 Referred-Token-Binding-ID" header field of the dispatched request 241 using the format defined in Section 2.2. Otherwise, the "Sec- 242 Referred-Token-Binding-ID" header field MUST NOT be present in 243 the dispatched request. 245 4. If the Token Binding Message contains any additional validated 246 Token Bindings, they are placed in the "Sec-Other-Token-Binding- 247 ID" header field using the format defined in Section 2.2. If the 248 Token Binding Message contains no additional valid Token 249 Bindings, the "Sec-Referred-Token-Binding-ID" header field MUST 250 NOT be present in the dispatched request. 252 5. Any occurrence of the "Sec-Provided-Token-Binding-ID", "Sec- 253 Referred-Token-Binding-ID", and "Sec-Other-Token-Binding-ID" 254 headers in the original incoming request MUST be removed or 255 overwritten before forwarding the request. 257 Requests made over a connection where the use of Token Binding was 258 not negotiated MUST be sanitized by removing any occurrences of the 259 "Sec-Provided-Token-Binding-ID", "Sec-Referred-Token-Binding-ID", and 260 "Sec-Other-Token-Binding-ID" header fields prior to dispatching the 261 request to the backend server. 263 Forward proxies and other intermediaries MUST NOT add the "Sec- 264 Provided-Token-Binding-ID" "Sec-Referred-Token-Binding-ID", or "Sec- 265 Other-Token-Binding-ID" header to requests. 267 2.4. Examples 269 Extra line breaks and whitespace have been added to the following 270 examples for display and formatting purposes only. 272 2.4.1. Provided Token Binding ID 274 The following "Sec-Token-Binding" header is from an HTTP request made 275 over a TLS connection between the client and the TTRP where the use 276 of Token Binding has been negotiated. The base64url-encoded 277 representation of the exported keying material for that connection is 278 "AYVUayPTP9RmELNpGjFl6Ykm2CUx7pUMxe35yb11dgU", which can be used to 279 validate the Token Binding Message. The encoded Token Binding 280 Message has the provided Token Binding that the client uses with the 281 server. 283 Sec-Token-Binding: AIkAAgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_YKTZfFJv 284 6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKkAQEtxe4jeUJU0WezxlQ 285 XWVSBFeHxFMdXRBIH_LKOSAuSMOJ0XEw1Q8DE248qkOiRKzw3KdSNYukYEPmO21bQi 286 3YYAAA 288 Figure 3: Header in HTTP Request to TTRP 290 After validating the Token Binding Message, the TTRP removes the 291 "Sec-Token-Binding" header and adds the following "Sec-Provided- 292 Token-Binding-ID" header with the provided Token Binding ID to the 293 request that is dispatched to the backend server. 295 Sec-Provided-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 296 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 298 Figure 4: Header in HTTP Request to Backend Server 300 2.4.2. Provided and Referred Token Binding IDs 302 The following "Sec-Token-Binding" header is from an HTTP request made 303 over a TLS connection between the client and the TTRP where the use 304 of Token Binding has been negotiated. The base64url-encoded 305 representation of the exported keying material for that connection is 306 "wEWWCP1KPxfq-QL4NxYII_P4ti_9YYqrTpGs28BZEqE", which can be used to 307 validate the Token Binding Message. The encoded Token Binding 308 Message has the provided Token Binding that the client uses with the 309 server as well as the referred Token Binding that it uses with a 310 different server. 312 Sec-Token-Binding: ARIAAgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGjHPJchPav 313 NbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-psAQMyYIqXj7djGPev1dk 314 jV9XxLYGCyqOrBVEtBHrMUCeo22ymLg3OiFcl_fmOPxJbjxI6lKcF0lyfy-dSQmPIe 315 zQ0AAAECAEFArPIiuZxj9gK0dWhIcG63r2-sZ8V3LX9gpNl8Um_oGOtmwoP1v0VHNI 316 HEOzW3BOqcBLvUzVEG6a6KGEj3GrFcqQBAHQm0pzgUTXKLRamuKE1pmmP9I3UBVpoe 317 1DBCe9H2l1VPpsImakUa6crAqZ-0CGBmji7bYzQogpKcyxTTFk5zdwAA 319 Figure 5: Header in HTTP Request to TTRP 321 After validating the Token Binding Message, the TTRP removes the 322 "Sec-Token-Binding" header and adds the following "Sec-Provided- 323 Token-Binding-ID" and "Sec-Referred-Token-Binding-ID" headers, with 324 the provided and referred Token Binding IDs respectively, to the 325 request that is dispatched to the backend server. 327 Sec-Provided-Token-Binding-ID: AgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGj 328 HPJchPavNbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-ps 329 Sec-Referred-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 330 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 332 Figure 6: Headers in HTTP Request to Backend Server 334 2.4.3. Provided and Other Token Binding IDs 336 The following "Sec-Token-Binding" header is from an HTTP request made 337 over a TLS connection between the client and the TTRP where the use 338 of Token Binding has been negotiated. The base64url-encoded 339 representation of the exported keying material for that connection is 340 "Zr_1DESCcDoaltcZCK613UrEWHRf2B3w9i3bwcxpacc", which can be used to 341 validate the Token Binding Message. The encoded Token Binding 342 Message has the provided Token Binding and two other Token Bindings. 344 Sec-Token-Binding: AZsAAgBBQA35hcCjI5GEHLLAZ0i2l2ZvQe-bSPAP7jovkZJM 345 4wYHgmmXNd1aRpnQmXK9ghUmrdtS6p_e2uSlMXIVKOIwgysAQJ-TKyVGF37XUXMy79 346 ybwJyPpfCG9Iq6fdIxLX_yJn-L__Z3p_WIL3g17K0OH3XZmJS3qZNNEVu_8HmPN-d9 347 hGMAAE0CAEFAR68GbdIQyrHqkorJF0sekYJvf8iV03obGxbaWbqAEJetsYxprB6c3M 348 x5KDHBGZjsFbeFW5Xec_EaxX0Hw3RmJwBA-Fu22kokRbB7G0D0g6_sdCHTbczSCmnm 349 6rqP1x7kRIIj_kJNCCWcwMMFzbsBTXcm5fJrRdBTcsqiiqYD6aJ1SgAACwIAQUCDqt 350 6m63By8b1lvhN-n9OsQThoLomzKpMicSZGwR166jplhbkjrFsHzdNqzLFFEhCT9s0p 351 XrcbpOHsZnpRSkmhAEBfOwxjK3Y9EOeMrqjo0IUhmurW2EgtSRBjDwc0r-rDT231Zv 352 _f1oePB8Pkd1kgAtgKX5EDiemfo1YER3_I2cv3AAA 354 Figure 7: Header in HTTP Request to TTRP 356 After validating the Token Binding Message, the TTRP removes the 357 "Sec-Token-Binding" header and adds the following "Sec-Provided- 358 Token-Binding-ID" and "Sec-Other-Token-Binding-ID" headers to the 359 request that is dispatched to the backend server. 361 Sec-Provided-Token-Binding-ID: AgBBQA35hcCjI5GEHLLAZ0i2l2ZvQe-bSPAP 362 7jovkZJM4wYHgmmXNd1aRpnQmXK9ghUmrdtS6p_e2uSlMXIVKOIwgys 363 Sec-Other-Token-Binding-ID: 4d.AgBBQEevBm3SEMqx6pKKyRdLHpGCb3_IldN6 364 GxsW2lm6gBCXrbGMaawenNzMeSgxwRmY7BW3hVuV3nPxGsV9B8N0Zic,B.AgBBQIO 365 q3qbrcHLxvWW-E36f06xBOGguibMqkyJxJkbBHXrqOmWFuSOsWwfN02rMsUUSEJP2 366 zSletxuk4exmelFKSaE 368 Figure 8: Headers in HTTP Request to Backend Server 370 3. TLS Versions and Best Practices 372 TLS 1.2 [RFC5246] is cited in this document because, at the time of 373 writing, it is the latest version that is widely deployed. However, 374 this document is applicable with other TLS versions that allow for 375 negotiating the use of Token Binding. [I-D.ietf-tokbind-tls13], for 376 example, describes Token Binding for TLS 1.3 [I-D.ietf-tls-tls13]. 377 Implementation security considerations for TLS, including version 378 recommendations, can be found in Recommendations for Secure Use of 379 Transport Layer Security (TLS) and Datagram Transport Layer Security 380 (DTLS) [BCP195]. 382 4. Security Considerations 384 The headers described herein enable a reverse proxy and backend 385 server to function together as though they are a single logical 386 server side deployment of HTTPS Token Binding. Use of the headers 387 outside that intended use case, however, may undermine the 388 protections afforded by Token Binding. Therefore steps MUST be taken 389 to prevent unintended use, both in sending the headers and in relying 390 on their value. 392 Producing and consuming the headers SHOULD be a configurable option, 393 respectively, in a reverse proxy and backend server (or individual 394 application in that server). The default configuration for both 395 should be to not use the headers thus requiring an "opt-in" to the 396 functionality. 398 Backend servers MUST only accept the headers from trusted reverse 399 proxies. And reverse proxies MUST sanitize the incoming request 400 before forwarding it on by removing or overwriting any existing 401 instances of the headers. Otherwise arbitrary clients can control 402 the header values as seen and used by the backend server. 404 The communication between a reverse proxy and backend server needs to 405 be secured against eavesdropping and modification by unintended 406 parties. 408 The configuration options and request sanitization are necessarily 409 functionally of the respective servers. The other requirements can 410 be met in a number of ways, which will vary based on specific 411 deployments. The communication between a reverse proxy and backend 412 server, for example, might be over a mutually authenticated TLS with 413 the insertion and consumption headers occurring only on that 414 connection. Alternatively the network topology might dictate a 415 private network such that the backend application is only able to 416 accept requests from the reverse proxy and the proxy can only make 417 requests to that server. Other deployments that meet the 418 requirements set forth herein are also possible. 420 Employing the "Sec-" header field prefix for the headers defined 421 herein denotes them as forbidden header names (see [fetch-spec]), 422 which means they cannot be set or modified programmatically by script 423 running in-browser. 425 5. IANA Considerations 427 5.1. HTTP Message Header Field Names Registration 429 This document specifies the following new HTTP header fields, 430 registration of which is requested in the "Permanent Message Header 431 Field Names" registry defined in [RFC3864]. 433 o Header Field Name: "Sec-Provided-Token-Binding-ID" 434 o Applicable protocol: HTTP 435 o Status: standard 436 o Author/change Controller: IETF 437 o Specification Document(s): [[ this specification ]] 439 o Header Field Name: "Sec-Referred-Token-Binding-ID" 440 o Applicable protocol: HTTP 441 o Status: standard 442 o Author/change Controller: IETF 443 o Specification Document(s): [[ this specification ]] 445 o Header Field Name: "Sec-Other-Token-Binding-ID" 446 o Applicable protocol: HTTP 447 o Status: standard 448 o Author/change Controller: IETF 449 o Specification Document(s): [[ this specification ]] 451 6. References 453 6.1. Normative References 455 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 456 "Recommendations for Secure Use of Transport Layer 457 Security (TLS) and Datagram Transport Layer Security 458 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 459 2015, . 461 [I-D.ietf-tokbind-https] 462 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 463 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 464 tokbind-https-12 (work in progress), January 2018. 466 [I-D.ietf-tokbind-negotiation] 467 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 468 "Transport Layer Security (TLS) Extension for Token 469 Binding Protocol Negotiation", draft-ietf-tokbind- 470 negotiation-10 (work in progress), October 2017. 472 [I-D.ietf-tokbind-protocol] 473 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 474 Hodges, "The Token Binding Protocol Version 1.0", draft- 475 ietf-tokbind-protocol-16 (work in progress), October 2017. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 483 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 484 . 486 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 487 Specifications: ABNF", STD 68, RFC 5234, 488 DOI 10.17487/RFC5234, January 2008, 489 . 491 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 492 (TLS) Protocol Version 1.2", RFC 5246, 493 DOI 10.17487/RFC5246, August 2008, 494 . 496 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 497 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 498 March 2010, . 500 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 501 Protocol (HTTP/1.1): Message Syntax and Routing", 502 RFC 7230, DOI 10.17487/RFC7230, June 2014, 503 . 505 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 506 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 507 May 2017, . 509 6.2. Informative References 511 [fetch-spec] 512 WhatWG, "Fetch", Living Standard , 513 . 515 [I-D.ietf-tls-tls13] 516 Rescorla, E., "The Transport Layer Security (TLS) Protocol 517 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 518 March 2018. 520 [I-D.ietf-tokbind-tls13] 521 Harper, N., "Token Binding for Transport Layer Security 522 (TLS) Version 1.3 Connections", draft-ietf-tokbind- 523 tls13-01 (work in progress), May 2018. 525 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 526 Procedures for Message Header Fields", BCP 90, RFC 3864, 527 DOI 10.17487/RFC3864, September 2004, 528 . 530 Appendix A. Acknowledgements 532 The author would like to thank the following people for their various 533 contributions to the specification: Vinod Anupam, Dirk Balfanz, John 534 Bradley, William Denniss, Nick Harper, Jeff Hodges, Subodh Iyengar, 535 Leif Johansson, Michael B. Jones, Yoav Nir, James Manger, Andrei 536 Popov, Eric Rescorla, Piotr Sikora, Martin Thomson, and Hans Zandbelt 538 Appendix B. Document History 540 [[ to be removed by the RFC Editor before publication as an RFC ]] 542 draft-ietf-tokbind-ttrp-06 544 o Move TLS Versions and Best Practices out of Security 545 Considerations to its own top-level section. 547 draft-ietf-tokbind-ttrp-05 549 o Editorial updates. 551 o Change one character in the last example to help emphasize the 552 case-insensitivity of hex. 554 o Add a TLS Versions and Best Practices section with BCP195 and also 555 mention of ietf-tokbind-tls13 and ietf-tls-tls13. 557 draft-ietf-tokbind-ttrp-04 559 o Add an example with Sec-Other-Token-Binding-ID. 561 o Use the HEXDIG core ABNF rule for EncodedTokenBindingType and 562 mention case-insensitive in the text. 564 o Minor editorial fixes. 566 o Add to the Acknowledgements and remove the 'and others' bit. 568 draft-ietf-tokbind-ttrp-03 570 o Add a header to allow for additional token binding types other 571 than provided and referred to be conveyed. 573 o Reword the Abstract somewhat for (hopefully) improved readability. 575 o Minor editorial and formatting updates. 577 draft-ietf-tokbind-ttrp-02 579 o Add to the Acknowledgements. 581 o Update references for Token Binding negotiation, protocol, and 582 https. 584 o Use the boilerplate from RFC 8174. 586 o Reformat the "HTTP Header Fields and Processing Rules" section to 587 make the header names more prominent and move the encoding 588 definitions earlier. 590 draft-ietf-tokbind-ttrp-01 592 o Prefix the header names with "Sec-" so that they are denoted as 593 forbidden header names by Fetch https://fetch.spec.whatwg.org/ 595 o Removed potentially confusing sentence from Security 596 Considerations per 597 https://mailarchive.ietf.org/arch/msg/unbearable/ 598 O0IpppyyEqMrQjEkyEi8p8CeBGA 600 o Editorial fixes. 602 draft-ietf-tokbind-ttrp-00 604 o Initial WG draft from draft-campbell-tokbind-ttrp. 606 draft-campbell-tokbind-ttrp-01 608 o Minor editorial fixes. 610 o Add to the Acknowledgements. 612 o Initial draft based on 'consensus to work on the problem' from the 613 Seoul meeting [1][2] and reflecting the consensus approach from 614 discussions at the Chicago meeting [3]. 616 [1] https://www.ietf.org/proceedings/97/minutes/minutes-97- 617 tokbind-01.txt (minutes from Seoul) 618 [2] https://www.ietf.org/proceedings/97/slides/slides-97-tokbind- 619 reverse-proxies-00.pdf (slides from Seoul) 620 [3] https://mailarchive.ietf.org/arch/msg/ 621 unbearable/_ZHI8y2Vs5WMP8VMRr7zroo_sNU (summary of discussion) 623 Author's Address 625 Brian Campbell 626 Ping Identity 628 Email: brian.d.campbell@gmail.com