idnits 2.17.1 draft-ietf-tokbind-ttrp-07.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 (October 19, 2018) is 2015 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 615 -- Looks like a reference, but probably isn't: '2' on line 617 -- Looks like a reference, but probably isn't: '3' on line 619 ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) ** 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 (~~), 2 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 October 19, 2018 5 Expires: April 22, 2019 7 HTTPS Token Binding with TLS Terminating Reverse Proxies 8 draft-ietf-tokbind-ttrp-07 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 April 22, 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 . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 9 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 [RFC8473] provides a mechanism that enables 81 HTTP servers to cryptographically bind cookies and other security 82 tokens to a key generated by the client. When the use of Token 83 Binding is negotiated in the TLS [RFC5246] handshake [RFC8472] the 84 client sends an encoded Token Binding Message [RFC8471] as a header 85 in each HTTP request, which proves possession of one or more private 86 keys held by the client. The public portion of the keys are 87 represented in the Token Binding IDs of the Token Binding Message and 88 for each one there is a signature over some data, which includes the 89 exported keying material [RFC5705] of the TLS connection. An HTTP 90 server issuing cookies or other security tokens can associate them 91 with the Token Binding ID, which ensures those tokens cannot be used 92 successfully over a different TLS connection or by a different client 93 than the one to which they were issued. 95 A fairly common deployment architecture for HTTPS applications is to 96 have the backend HTTP application servers sit behind a reverse proxy 97 that terminates TLS connections from clients. The proxy is 98 accessible to the internet and dispatches client requests to the 99 appropriate backend server within a private or protected network. 100 The backend servers are not directly accessible by clients and are 101 only reachable through the reverse proxy. The details of such 102 deployments are typically opaque to clients who make requests to the 103 proxy server and see responses as though they originated from the 104 proxy server itself. Although HTTPS is also usually employed between 105 the proxy and the backend server, the TLS connection that the client 106 establishes for HTTPS is between itself and the reverse proxy server. 108 Token Binding facilitates a binding of security tokens to a key held 109 by the client by way of the TLS connection between that client and 110 the server. In a deployment where TLS is terminated by a reverse 111 proxy, however, the TLS connection is between the client and the 112 proxy while the backend server is likely the system that will issue 113 and validate cookies or other security tokens. Additional steps are 114 therefore needed to enable the use of Token Binding in such 115 deployment architectures. In the absence of a standardized approach, 116 different implementations will address it differently, which will 117 make interoperability between such implementations difficult or 118 impossible without complex configurations or custom integrations. 120 This document standardizes HTTP header field names that a TLS 121 terminating reverse proxy (TTRP) adds to requests that it sends to 122 the backend servers. The headers contain information from the 123 validated Token Binding Message sent by the client to the proxy, thus 124 enabling the backend server to bind, or verify the binding of, 125 cookies and other security tokens to the client's Token Binding key. 126 The usage of the headers, both the TTRP adding the headers and the 127 backend application server using the headers to bind cookies or other 128 tokens, are to be configuration options of the respective systems as 129 they will not always be applicable. 131 1.1. Requirements Notation and Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2. HTTP Header Fields and Processing Rules 140 2.1. Encoding 142 The field-values of the HTTP headers defined herein utilize the 143 following encoded forms. 145 2.1.1. Token Binding ID 147 A Token Binding ID is represented as an "EncodedTokenBindingID", 148 which is thea base64url encoding of the TokenBindingID byte sequence 149 (see section 3 of [RFC8471]) using the URL and filename safe alphabet 150 described in Section 5 of [RFC4648], with all trailing pad characters 151 '=' omitted and without the inclusion of any line breaks, whitespace, 152 or other additional characters. ABNF [RFC5234] syntax for 153 "EncodedTokenBindingID" is shown in Figure 1 below. 155 EncodedTokenBindingID = *( DIGIT / ALPHA / "-" / "_" ) 157 DIGIT = 158 ALPHA = 160 Figure 1: Encoded Token Binding ID ABNF 162 2.1.2. Token Binding Type 164 A Token Binding type value (a single byte) can be represented as an 165 "EncodedTokenBindingType", which is a case-insensitive hex encoding 166 (Section 8 of [RFC4648]). The ABNF definition is shown in Figure 2 167 below. 169 EncodedTokenBindingType = 1*2HEXDIG 171 HEXDIG = 173 Figure 2: Encoded Token Binding Type ABNF 175 2.2. Token Binding ID HTTP Header Fields 177 The Token Binding Protocol [RFC8471] recommends that implementations 178 make Token Binding IDs available to the application as opaque byte 179 sequences, enabling those applications to use the Token Binding IDs 180 when generating and verifying bound tokens. In the context of a TLS 181 terminating reverse proxy (TTRP) deployment, the TTRP makes the Token 182 Binding ID(s) available to the backend application with the following 183 header fields. 185 Sec-Provided-Token-Binding-ID 186 The Token Binding ID of the provided Token Binding represented as 187 an "EncodedTokenBindingID". 189 Sec-Referred-Token-Binding-ID 190 The Token Binding ID of the referred Token Binding represented as 191 an "EncodedTokenBindingID". 193 Sec-Other-Token-Binding-ID 194 Additional Token Bindings that are sent by the client and 195 validated by the TTRP are represented as a comma-separated list of 196 the concatenation of the "EncodedTokenBindingType", a period (".") 197 character, and the "EncodedTokenBindingID" of each. 199 Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding- 200 ID" are single HTTP header field-valued as defined in Section 3.2 of 201 [RFC7230], which MUST NOT have a list of values or occur multiple 202 times in a request. 204 All header fields defined herein are only for use in HTTP requests 205 and MUST NOT to be used in HTTP responses. 207 2.3. Processing Rules 209 This section defines the applicable processing rules for a TLS 210 terminating reverse proxy (TTRP) and backend server(s) to provide 211 server side support of Token Binding over HTTP [RFC8473] using the 212 HTTP headers described in Section 2.2. Use of the technique is to be 213 a configuration or deployment option and the processing rules 214 described herein are for servers operating with that option enabled. 216 A TTRP negotiates the use of Token Binding with the client, such as 217 is described in [RFC8472] and validates the Token Binding Message as 218 defined in The Token Binding Protocol [RFC8471] and Token Binding 219 over HTTP [RFC8473] for each HTTP request on the underlying TLS 220 connection. Requests with a valid Token Binding Message (and meeting 221 any other authorization or policy requirements of the TTRP) are 222 dispatched to the backend server with the following modifications. 224 1. The "Sec-Token-Binding" header in the original incoming request 225 MUST be removed from the request that is dispatched to the 226 backend server. 228 2. The Token Binding ID of the provided Token Binding of the Token 229 Binding Message MUST be placed in the "Sec-Provided-Token- 230 Binding-ID" header field of the dispatched request using the 231 format defined in Section 2.2. 233 3. If the Token Binding Message contains a referred Token Binding, 234 the referred Token Binding ID MUST be placed in the "Sec- 235 Referred-Token-Binding-ID" header field of the dispatched request 236 using the format defined in Section 2.2. Otherwise, the "Sec- 237 Referred-Token-Binding-ID" header field MUST NOT be present in 238 the dispatched request. 240 4. If the Token Binding Message contains any additional validated 241 Token Bindings, they are placed in the "Sec-Other-Token-Binding- 242 ID" header field using the format defined in Section 2.2. If the 243 Token Binding Message contains no additional valid Token 244 Bindings, the "Sec-Referred-Token-Binding-ID" header field MUST 245 NOT be present in the dispatched request. 247 5. Any occurrence of the "Sec-Provided-Token-Binding-ID", "Sec- 248 Referred-Token-Binding-ID", and "Sec-Other-Token-Binding-ID" 249 headers in the original incoming request MUST be removed or 250 overwritten before forwarding the request. 252 Requests made over a connection where the use of Token Binding was 253 not negotiated MUST be sanitized by removing any occurrences of the 254 "Sec-Provided-Token-Binding-ID", "Sec-Referred-Token-Binding-ID", and 255 "Sec-Other-Token-Binding-ID" header fields prior to dispatching the 256 request to the backend server. 258 Forward proxies and other intermediaries MUST NOT add the "Sec- 259 Provided-Token-Binding-ID" "Sec-Referred-Token-Binding-ID", or "Sec- 260 Other-Token-Binding-ID" header to requests. 262 2.4. Examples 264 Extra line breaks and whitespace have been added to the following 265 examples for display and formatting purposes only. 267 2.4.1. Provided Token Binding ID 269 The following "Sec-Token-Binding" header is from an HTTP request made 270 over a TLS connection between the client and the TTRP where the use 271 of Token Binding has been negotiated. The base64url-encoded 272 representation of the exported keying material for that connection is 273 "AYVUayPTP9RmELNpGjFl6Ykm2CUx7pUMxe35yb11dgU", which can be used to 274 validate the Token Binding Message. The encoded Token Binding 275 Message has the provided Token Binding that the client uses with the 276 server. 278 Sec-Token-Binding: AIkAAgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_YKTZfFJv 279 6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKkAQEtxe4jeUJU0WezxlQ 280 XWVSBFeHxFMdXRBIH_LKOSAuSMOJ0XEw1Q8DE248qkOiRKzw3KdSNYukYEPmO21bQi 281 3YYAAA 283 Figure 3: Header in HTTP Request to TTRP 285 After validating the Token Binding Message, the TTRP removes the 286 "Sec-Token-Binding" header and adds the following "Sec-Provided- 287 Token-Binding-ID" header with the provided Token Binding ID to the 288 request that is dispatched to the backend server. 290 Sec-Provided-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 291 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 293 Figure 4: Header in HTTP Request to Backend Server 295 2.4.2. Provided and Referred Token Binding IDs 297 The following "Sec-Token-Binding" header is from an HTTP request made 298 over a TLS connection between the client and the TTRP where the use 299 of Token Binding has been negotiated. The base64url-encoded 300 representation of the exported keying material for that connection is 301 "wEWWCP1KPxfq-QL4NxYII_P4ti_9YYqrTpGs28BZEqE", which can be used to 302 validate the Token Binding Message. The encoded Token Binding 303 Message has the provided Token Binding that the client uses with the 304 server as well as the referred Token Binding that it uses with a 305 different server. 307 Sec-Token-Binding: ARIAAgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGjHPJchPav 308 NbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-psAQMyYIqXj7djGPev1dk 309 jV9XxLYGCyqOrBVEtBHrMUCeo22ymLg3OiFcl_fmOPxJbjxI6lKcF0lyfy-dSQmPIe 310 zQ0AAAECAEFArPIiuZxj9gK0dWhIcG63r2-sZ8V3LX9gpNl8Um_oGOtmwoP1v0VHNI 311 HEOzW3BOqcBLvUzVEG6a6KGEj3GrFcqQBAHQm0pzgUTXKLRamuKE1pmmP9I3UBVpoe 312 1DBCe9H2l1VPpsImakUa6crAqZ-0CGBmji7bYzQogpKcyxTTFk5zdwAA 314 Figure 5: Header in HTTP Request to TTRP 316 After validating the Token Binding Message, the TTRP removes the 317 "Sec-Token-Binding" header and adds the following "Sec-Provided- 318 Token-Binding-ID" and "Sec-Referred-Token-Binding-ID" headers, with 319 the provided and referred Token Binding IDs respectively, to the 320 request that is dispatched to the backend server. 322 Sec-Provided-Token-Binding-ID: AgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGj 323 HPJchPavNbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-ps 324 Sec-Referred-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 325 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 327 Figure 6: Headers in HTTP Request to Backend Server 329 2.4.3. Provided and Other Token Binding IDs 331 The following "Sec-Token-Binding" header is from an HTTP request made 332 over a TLS connection between the client and the TTRP where the use 333 of Token Binding has been negotiated. The base64url-encoded 334 representation of the exported keying material for that connection is 335 "Zr_1DESCcDoaltcZCK613UrEWHRf2B3w9i3bwcxpacc", which can be used to 336 validate the Token Binding Message. The encoded Token Binding 337 Message has the provided Token Binding and two other Token Bindings. 339 Sec-Token-Binding: AZsAAgBBQA35hcCjI5GEHLLAZ0i2l2ZvQe-bSPAP7jovkZJM 340 4wYHgmmXNd1aRpnQmXK9ghUmrdtS6p_e2uSlMXIVKOIwgysAQJ-TKyVGF37XUXMy79 341 ybwJyPpfCG9Iq6fdIxLX_yJn-L__Z3p_WIL3g17K0OH3XZmJS3qZNNEVu_8HmPN-d9 342 hGMAAE0CAEFAR68GbdIQyrHqkorJF0sekYJvf8iV03obGxbaWbqAEJetsYxprB6c3M 343 x5KDHBGZjsFbeFW5Xec_EaxX0Hw3RmJwBA-Fu22kokRbB7G0D0g6_sdCHTbczSCmnm 344 6rqP1x7kRIIj_kJNCCWcwMMFzbsBTXcm5fJrRdBTcsqiiqYD6aJ1SgAACwIAQUCDqt 345 6m63By8b1lvhN-n9OsQThoLomzKpMicSZGwR166jplhbkjrFsHzdNqzLFFEhCT9s0p 346 XrcbpOHsZnpRSkmhAEBfOwxjK3Y9EOeMrqjo0IUhmurW2EgtSRBjDwc0r-rDT231Zv 347 _f1oePB8Pkd1kgAtgKX5EDiemfo1YER3_I2cv3AAA 349 Figure 7: Header in HTTP Request to TTRP 351 After validating the Token Binding Message, the TTRP removes the 352 "Sec-Token-Binding" header and adds the following "Sec-Provided- 353 Token-Binding-ID" and "Sec-Other-Token-Binding-ID" headers to the 354 request that is dispatched to the backend server. 356 Sec-Provided-Token-Binding-ID: AgBBQA35hcCjI5GEHLLAZ0i2l2ZvQe-bSPAP 357 7jovkZJM4wYHgmmXNd1aRpnQmXK9ghUmrdtS6p_e2uSlMXIVKOIwgys 358 Sec-Other-Token-Binding-ID: 4d.AgBBQEevBm3SEMqx6pKKyRdLHpGCb3_IldN6 359 GxsW2lm6gBCXrbGMaawenNzMeSgxwRmY7BW3hVuV3nPxGsV9B8N0Zic,B.AgBBQIO 360 q3qbrcHLxvWW-E36f06xBOGguibMqkyJxJkbBHXrqOmWFuSOsWwfN02rMsUUSEJP2 361 zSletxuk4exmelFKSaE 363 Figure 8: Headers in HTTP Request to Backend Server 365 3. TLS Versions and Best Practices 367 TLS 1.2 [RFC5246] is cited in this document because, at the time of 368 writing, it is the latest version that is widely deployed. However, 369 this document is applicable with other TLS versions that allow for 370 negotiating the use of Token Binding. Token Binding for Transport 371 Layer Security (TLS) Version 1.3 Connections 372 [I-D.ietf-tokbind-tls13], for example, describes Token Binding with 373 TLS 1.3 [RFC8446]. Implementation security considerations for TLS, 374 including version recommendations, can be found in Recommendations 375 for Secure Use of Transport Layer Security (TLS) and Datagram 376 Transport Layer Security (DTLS) [BCP195]. 378 4. Security Considerations 380 The headers described herein enable a reverse proxy and backend 381 server to function together as though they are a single logical 382 server side deployment of HTTPS Token Binding. Use of the headers 383 outside that intended use case, however, may undermine the 384 protections afforded by Token Binding. Therefore steps MUST be taken 385 to prevent unintended use, both in sending the headers and in relying 386 on their value. 388 Producing and consuming the headers SHOULD be a configurable option, 389 respectively, in a reverse proxy and backend server (or individual 390 application in that server). The default configuration for both 391 should be to not use the headers thus requiring an "opt-in" to the 392 functionality. 394 Backend servers MUST only accept the headers from trusted reverse 395 proxies. And reverse proxies MUST sanitize the incoming request 396 before forwarding it on by removing or overwriting any existing 397 instances of the headers. Otherwise arbitrary clients can control 398 the header values as seen and used by the backend server. 400 The communication between a reverse proxy and backend server needs to 401 be secured against eavesdropping and modification by unintended 402 parties. 404 The configuration options and request sanitization are necessarily 405 functionally of the respective servers. The other requirements can 406 be met in a number of ways, which will vary based on specific 407 deployments. The communication between a reverse proxy and backend 408 server, for example, might be over a mutually authenticated TLS with 409 the insertion and consumption headers occurring only on that 410 connection. Alternatively the network topology might dictate a 411 private network such that the backend application is only able to 412 accept requests from the reverse proxy and the proxy can only make 413 requests to that server. Other deployments that meet the 414 requirements set forth herein are also possible. 416 Employing the "Sec-" header field prefix for the headers defined 417 herein denotes them as forbidden header names (see [fetch-spec]), 418 which means they cannot be set or modified programmatically by script 419 running in-browser. 421 5. IANA Considerations 422 5.1. HTTP Message Header Field Names Registration 424 This document specifies the following new HTTP header fields, 425 registration of which is requested in the "Permanent Message Header 426 Field Names" registry defined in [RFC3864]. 428 o Header Field Name: "Sec-Provided-Token-Binding-ID" 429 o Applicable protocol: HTTP 430 o Status: standard 431 o Author/change Controller: IETF 432 o Specification Document(s): [[ this specification ]] 434 o Header Field Name: "Sec-Referred-Token-Binding-ID" 435 o Applicable protocol: HTTP 436 o Status: standard 437 o Author/change Controller: IETF 438 o Specification Document(s): [[ this specification ]] 440 o Header Field Name: "Sec-Other-Token-Binding-ID" 441 o Applicable protocol: HTTP 442 o Status: standard 443 o Author/change Controller: IETF 444 o Specification Document(s): [[ this specification ]] 446 6. References 448 6.1. Normative References 450 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 451 "Recommendations for Secure Use of Transport Layer 452 Security (TLS) and Datagram Transport Layer Security 453 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 454 2015, . 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 462 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 463 . 465 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 466 Specifications: ABNF", STD 68, RFC 5234, 467 DOI 10.17487/RFC5234, January 2008, 468 . 470 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 471 (TLS) Protocol Version 1.2", RFC 5246, 472 DOI 10.17487/RFC5246, August 2008, 473 . 475 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 476 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 477 March 2010, . 479 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 480 Protocol (HTTP/1.1): Message Syntax and Routing", 481 RFC 7230, DOI 10.17487/RFC7230, June 2014, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, 489 "The Token Binding Protocol Version 1.0", RFC 8471, 490 DOI 10.17487/RFC8471, October 2018, 491 . 493 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 494 Layer Security (TLS) Extension for Token Binding Protocol 495 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 496 2018, . 498 [RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and 499 J. Hodges, "Token Binding over HTTP", RFC 8473, 500 DOI 10.17487/RFC8473, October 2018, 501 . 503 6.2. Informative References 505 [fetch-spec] 506 WhatWG, "Fetch", Living Standard , 507 . 509 [I-D.ietf-tokbind-tls13] 510 Harper, N., "Token Binding for Transport Layer Security 511 (TLS) Version 1.3 Connections", draft-ietf-tokbind- 512 tls13-01 (work in progress), May 2018. 514 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 515 Procedures for Message Header Fields", BCP 90, RFC 3864, 516 DOI 10.17487/RFC3864, September 2004, 517 . 519 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 520 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 521 . 523 Appendix A. Acknowledgements 525 The author would like to thank the following people for their various 526 contributions to the specification: Vinod Anupam, Dirk Balfanz, John 527 Bradley, William Denniss, Nick Harper, Jeff Hodges, Subodh Iyengar, 528 Leif Johansson, Michael B. Jones, Yoav Nir, James Manger, Andrei 529 Popov, Eric Rescorla, Piotr Sikora, Martin Thomson, and Hans Zandbelt 531 Appendix B. Document History 533 [[ to be removed by the RFC Editor before publication as an RFC ]] 535 draft-ietf-tokbind-ttrp-07 537 o Update TLS 1.3 reference to RFC 8446. 539 o Update the references to the core token binding specs, which are 540 now RFCs 8471, 8472, and 8473. 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 o Add a header to allow for additional token binding types other 569 than provided and referred to be conveyed. 571 o Reword the Abstract somewhat for (hopefully) improved readability. 573 o Minor editorial and formatting updates. 575 draft-ietf-tokbind-ttrp-02 577 o Add to the Acknowledgements. 579 o Update references for Token Binding negotiation, protocol, and 580 https. 582 o Use the boilerplate from RFC 8174. 584 o Reformat the "HTTP Header Fields and Processing Rules" section to 585 make the header names more prominent and move the encoding 586 definitions earlier. 588 draft-ietf-tokbind-ttrp-01 590 o Prefix the header names with "Sec-" so that they are denoted as 591 forbidden header names by Fetch https://fetch.spec.whatwg.org/ 593 o Removed potentially confusing sentence from Security 594 Considerations per 595 https://mailarchive.ietf.org/arch/msg/unbearable/ 596 O0IpppyyEqMrQjEkyEi8p8CeBGA 598 o Editorial fixes. 600 draft-ietf-tokbind-ttrp-00 602 o Initial WG draft from draft-campbell-tokbind-ttrp. 604 draft-campbell-tokbind-ttrp-01 606 o Minor editorial fixes. 608 o Add to the Acknowledgements. 610 draft-campbell-tokbind-ttrp-00 611 o Initial draft based on 'consensus to work on the problem' from the 612 Seoul meeting [1][2] and reflecting the consensus approach from 613 discussions at the Chicago meeting [3]. 615 [1] https://www.ietf.org/proceedings/97/minutes/minutes-97- 616 tokbind-01.txt (minutes from Seoul) 617 [2] https://www.ietf.org/proceedings/97/slides/slides-97-tokbind- 618 reverse-proxies-00.pdf (slides from Seoul) 619 [3] https://mailarchive.ietf.org/arch/msg/ 620 unbearable/_ZHI8y2Vs5WMP8VMRr7zroo_sNU (summary of discussion) 622 Author's Address 624 Brian Campbell 625 Ping Identity 627 Email: brian.d.campbell@gmail.com