idnits 2.17.1 draft-ietf-tokbind-ttrp-04.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 (June 6, 2018) is 2143 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 572 -- Looks like a reference, but probably isn't: '2' on line 574 -- Looks like a reference, but probably isn't: '3' on line 576 == 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) Summary: 2 errors (**), 0 flaws (~~), 4 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 June 6, 2018 5 Expires: December 8, 2018 7 HTTPS Token Binding with TLS Terminating Reverse Proxies 8 draft-ietf-tokbind-ttrp-04 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 December 8, 2018. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. HTTP Message Header Field Names Registration . . . . . . 10 70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 5.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 74 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism 80 that enables HTTP servers to cryptographically bind cookies and other 81 security tokens to a key held by the browser or other HTTP client, 82 possession of which is proven on the TLS [RFC5246] connections over 83 which the tokens are used. When Token Binding is negotiated in the 84 TLS handshake [I-D.ietf-tokbind-negotiation] the client sends an 85 encoded Token Binding Message [I-D.ietf-tokbind-protocol] as a header 86 in each HTTP request, which proves possession of one or more private 87 keys held by the client. The public portion of the keys are 88 represented in the Token Binding IDs of the Token Binding Message and 89 for each one there is a signature over some data, which includes the 90 exported keying material [RFC5705] of the TLS connection. An HTTP 91 server issuing cookies or other security tokens can associate them 92 with the Token Binding ID, which ensures those tokens cannot be used 93 successfully over a different TLS connection or by a different client 94 than the one 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. The proxy is accessible to the internet and 99 dispatches client requests to the appropriate backend server within a 100 private or protected network. The backend servers are not directly 101 accessible outside the private network and are only reachable through 102 the reverse proxy. The details of such deployments are typically 103 opaque to clients who make requests to the proxy server and see 104 responses as though they originated from the proxy server itself. 105 TLS connections for HTTPS are established between each client and the 106 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 reverse proxy adding it and the 127 application server using them to bind cookies or other tokens, are to 128 be configuration options of the respective systems as they will not 129 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 [I-D.ietf-tokbind-protocol]) using the URL and 150 filename safe alphabet described in Section 5 of [RFC4648], with all 151 trailing pad characters '=' omitted and without the inclusion of any 152 line breaks, whitespace, or other additional characters. ABNF 153 [RFC5234] syntax for "EncodedTokenBindingID" is shown in Figure 1 154 below. 156 EncodedTokenBindingID = *( DIGIT / ALPHA / "-" / "_" ) 158 DIGIT = 159 ALPHA = 161 Figure 1: Encoded Token Binding ID ABNF 163 2.1.2. Token Binding Type 165 A Token Binding type value (a single byte) can be represented as an 166 "EncodedTokenBindingType", which is a case-insensitive hex (Section 8 167 of [RFC4648]) encoding. The ABNF definition is shown in Figure 2 168 below. 170 EncodedTokenBindingType = 1*2HEXDIG 172 HEXDIG = 174 Figure 2: Encoded Token Binding Type ABNF 176 2.2. Token Binding ID HTTP Header Fields 178 The Token Binding Protocol [I-D.ietf-tokbind-protocol] recommends 179 that implementations make Token Binding IDs available to the 180 application as opaque byte sequences, enabling those applications to 181 use the Token Binding IDs when generating and verifying bound tokens. 182 In the context of a TLS terminating reverse proxy (TTRP) deployment, 183 the TTRP makes the Token Binding ID(s) available to the backend 184 application with the following header fields. 186 Sec-Provided-Token-Binding-ID 187 The Token Binding ID of the provided Token Binding represented as 188 an "EncodedTokenBindingID". 190 Sec-Referred-Token-Binding-ID 191 The Token Binding ID of the referred Token Binding represented as 192 an "EncodedTokenBindingID". 194 Sec-Other-Token-Binding-ID 195 Additional Token Bindings, other than provided and referred, that 196 are sent by the client and validated by the TTRP are represented 197 as a comma-separated list of the concatenation of the 198 "EncodedTokenBindingType", a period (".") character, and the 199 "EncodedTokenBindingID" of each. 201 Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding- 202 ID" are single HTTP header field-valued as defined in Section 3.2 of 203 [RFC7230], which MUST NOT have a list of values or occur multiple 204 times in a request. 206 All header fields defined herein are only for use in HTTP requests 207 and MUST NOT to be used in HTTP responses. 209 2.3. Processing Rules 211 This section defines the applicable processing rules for a TLS 212 terminating reverse proxy (TTRP) and backend server(s) to provide 213 server side support of Token Binding over HTTP 214 [I-D.ietf-tokbind-https] using the HTTP headers described in 215 Section 2.2. Use of the technique is to be a configuration or 216 deployment option and the processing rules described herein are for 217 servers operating with that option enabled. 219 A TTRP negotiates the use of Token Binding with the client per 220 [I-D.ietf-tokbind-negotiation] and validates the Token Binding 221 Message as defined in The Token Binding Protocol 222 [I-D.ietf-tokbind-protocol] and Token Binding over HTTP 223 [I-D.ietf-tokbind-https] for each HTTP request on the underlying TLS 224 connection. Requests with a valid Token Binding Message (and meeting 225 any other authorization or policy requirements of the TTRP) are 226 dispatched to the backend server with the following modifications. 228 1. The "Sec-Token-Binding" header in the original incoming request 229 MUST be removed from the request that is dispatched to the 230 backend server. 232 2. The Token Binding ID of the provided Token Binding of the Token 233 Binding Message MUST be placed in the "Sec-Provided-Token- 234 Binding-ID" header field of the dispatched request using the 235 format defined in Section 2.2. 237 3. If the Token Binding Message contains a referred Token Binding, 238 the referred Token Binding ID MUST be placed in the "Sec- 239 Referred-Token-Binding-ID" header field of the dispatched request 240 using the format defined in Section 2.2. Otherwise, the "Sec- 241 Referred-Token-Binding-ID" header field MUST NOT be present in 242 the dispatched request. 244 4. If the Token Binding Message contains any additional validated 245 Token Bindings, they are placed in the "Sec-Other-Token-Binding- 246 ID" header field using the format defined in Section 2.2. If the 247 Token Binding Message contains no additional valid Token 248 Bindings, the "Sec-Referred-Token-Binding-ID" header field MUST 249 NOT be present in the dispatched request. 251 5. Any occurrence of the "Sec-Provided-Token-Binding-ID", "Sec- 252 Referred-Token-Binding-ID", and "Sec-Other-Token-Binding-ID" 253 headers in the original incoming request MUST be removed or 254 overwritten before forwarding the request. 256 Requests made over a connection where the use of Token Binding was 257 not negotiated MUST be sanitized by removing any occurrences of the 258 "Sec-Provided-Token-Binding-ID", "Sec-Referred-Token-Binding-ID", and 259 "Sec-Other-Token-Binding-ID" header fields prior to dispatching the 260 request to the backend server. 262 Forward proxies and other intermediaries MUST NOT add the "Sec- 263 Provided-Token-Binding-ID" "Sec-Referred-Token-Binding-ID", or "Sec- 264 Other-Token-Binding-ID" header to requests. 266 2.4. Examples 268 Extra line breaks and whitespace have been added to the following 269 examples for display and formatting purposes only. 271 2.4.1. Provided Token Binding ID 273 The following "Sec-Token-Binding" header is from an HTTP request made 274 over a TLS connection between the client and the TTRP where the use 275 of Token Binding has been negotiated (The base64url-encoded 276 representation of the exported keying material, which can be used to 277 validate the Token Binding Message, for that connection is 278 "AYVUayPTP9RmELNpGjFl6Ykm2CUx7pUMxe35yb11dgU"). The encoded Token 279 Binding Message has the provided Token Binding that the client uses 280 with the server. 282 Sec-Token-Binding: AIkAAgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_YKTZfFJv 283 6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKkAQEtxe4jeUJU0WezxlQ 284 XWVSBFeHxFMdXRBIH_LKOSAuSMOJ0XEw1Q8DE248qkOiRKzw3KdSNYukYEPmO21bQi 285 3YYAAA 287 Figure 3: Header in HTTP Request to TTRP 289 After validating the Token Binding Message, the TTRP removes the 290 "Sec-Token-Binding" header and adds the following "Sec-Provided- 291 Token-Binding-ID" header with the provided Token Binding ID to the 292 request that is dispatched to the backend server. 294 Sec-Provided-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 295 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 297 Figure 4: Header in HTTP Request to Backend Server 299 2.4.2. Provided and Referred Token Binding IDs 301 The following "Sec-Token-Binding" header is from an HTTP request made 302 over a TLS connection between the client and the TTRP where the use 303 of Token Binding has been negotiated (The base64url-encoded 304 representation of the exported keying material, which can be used to 305 validate the Token Binding Message, for that connection is 306 "wEWWCP1KPxfq-QL4NxYII_P4ti_9YYqrTpGs28BZEqE"). The encoded Token 307 Binding Message has the provided Token Binding that the client uses 308 with the server as well as the referred Token Binding that it uses 309 with a different server. 311 Sec-Token-Binding: ARIAAgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGjHPJchPav 312 NbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-psAQMyYIqXj7djGPev1dk 313 jV9XxLYGCyqOrBVEtBHrMUCeo22ymLg3OiFcl_fmOPxJbjxI6lKcF0lyfy-dSQmPIe 314 zQ0AAAECAEFArPIiuZxj9gK0dWhIcG63r2-sZ8V3LX9gpNl8Um_oGOtmwoP1v0VHNI 315 HEOzW3BOqcBLvUzVEG6a6KGEj3GrFcqQBAHQm0pzgUTXKLRamuKE1pmmP9I3UBVpoe 316 1DBCe9H2l1VPpsImakUa6crAqZ-0CGBmji7bYzQogpKcyxTTFk5zdwAA 318 Figure 5: Header in HTTP Request to TTRP 320 After validating the Token Binding Message, the TTRP removes the 321 "Sec-Token-Binding" header and adds the following "Sec-Provided- 322 Token-Binding-ID" and "Sec-Referred-Token-Binding-ID" headers, with 323 the provided and referred Token Binding IDs respectively, to the 324 request that is dispatched to the backend server. 326 Sec-Provided-Token-Binding-ID: AgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGj 327 HPJchPavNbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-ps 328 Sec-Referred-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 329 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 331 Figure 6: Headers in HTTP Request to Backend Server 333 2.4.3. Provided and Other Token Binding IDs 335 The following "Sec-Token-Binding" header is from an HTTP request made 336 over a TLS connection between the client and the TTRP where the use 337 of Token Binding has been negotiated (The base64url-encoded 338 representation of the exported keying material, which can be used to 339 validate the Token Binding Message, for that connection is 340 "Zr_1DESCcDoaltcZCK613UrEWHRf2B3w9i3bwcxpacc"). The encoded Token 341 Binding Message has the provided Token Binding and two other Token 342 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. Security Considerations 372 The headers described herein enable a reverse proxy and backend 373 server to function together as though they are a single logical 374 server side deployment of HTTPS Token Binding. Use of the headers 375 outside that intended use case, however, may undermine the 376 protections afforded by Token Binding. Therefore steps MUST be taken 377 to prevent unintended use, both in sending the headers and in relying 378 on their value. 380 Producing and consuming the headers SHOULD be a configurable option, 381 respectively, in a reverse proxy and backend server (or individual 382 application in that server). The default configuration for both 383 should be to not use the headers thus requiring an "opt-in" to the 384 functionality. 386 Backend servers MUST only accept the headers from trusted reverse 387 proxies. And reverse proxies MUST sanitize the incoming request 388 before forwarding it on by removing or overwriting any existing 389 instances of the headers. Otherwise arbitrary clients can control 390 the header values as seen and used by the backend server. 392 The communication between a reverse proxy and backend server needs to 393 be secured against eavesdropping and modification by unintended 394 parties. 396 The configuration options and request sanitization are necessarily 397 functionally of the respective servers. The other requirements can 398 be met in a number of ways, which will vary based on specific 399 deployments. The communication between a reverse proxy and backend 400 server, for example, might be over a mutually authenticated TLS with 401 the insertion and consumption headers occurring only on that 402 connection. Alternatively the network topology might dictate a 403 private network such that the backend application is only able to 404 accept requests from the reverse proxy and the proxy can only make 405 requests to that server. Other deployments that meet the 406 requirements set forth herein are also possible. 408 Employing the "Sec-" header field prefix for the headers defined 409 herein denotes them as forbidden header names (see [fetch-spec]), 410 which means they cannot be set or modified programmatically by script 411 running in-browser. 413 4. IANA Considerations 414 4.1. HTTP Message Header Field Names Registration 416 This document specifies the following new HTTP header fields, 417 registration of which is requested in the "Permanent Message Header 418 Field Names" registry defined in [RFC3864]. 420 o Header Field Name: "Sec-Provided-Token-Binding-ID" 421 o Applicable protocol: HTTP 422 o Status: standard 423 o Author/change Controller: IETF 424 o Specification Document(s): [[ this specification ]] 426 o Header Field Name: "Sec-Referred-Token-Binding-ID" 427 o Applicable protocol: HTTP 428 o Status: standard 429 o Author/change Controller: IETF 430 o Specification Document(s): [[ this specification ]] 432 o Header Field Name: "Sec-Other-Token-Binding-ID" 433 o Applicable protocol: HTTP 434 o Status: standard 435 o Author/change Controller: IETF 436 o Specification Document(s): [[ this specification ]] 438 5. References 440 5.1. Normative References 442 [I-D.ietf-tokbind-https] 443 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 444 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 445 tokbind-https-12 (work in progress), January 2018. 447 [I-D.ietf-tokbind-negotiation] 448 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 449 "Transport Layer Security (TLS) Extension for Token 450 Binding Protocol Negotiation", draft-ietf-tokbind- 451 negotiation-10 (work in progress), October 2017. 453 [I-D.ietf-tokbind-protocol] 454 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 455 Hodges, "The Token Binding Protocol Version 1.0", draft- 456 ietf-tokbind-protocol-16 (work in progress), October 2017. 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 464 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 465 . 467 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 468 Specifications: ABNF", STD 68, RFC 5234, 469 DOI 10.17487/RFC5234, January 2008, 470 . 472 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 473 (TLS) Protocol Version 1.2", RFC 5246, 474 DOI 10.17487/RFC5246, August 2008, 475 . 477 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 478 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 479 March 2010, . 481 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 482 Protocol (HTTP/1.1): Message Syntax and Routing", 483 RFC 7230, DOI 10.17487/RFC7230, June 2014, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 5.2. Informative References 492 [fetch-spec] 493 WhatWG, "Fetch", Living Standard , 494 . 496 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 497 Procedures for Message Header Fields", BCP 90, RFC 3864, 498 DOI 10.17487/RFC3864, September 2004, 499 . 501 Appendix A. Acknowledgements 503 The author would like to thank the following people for their various 504 contributions to the specification: Vinod Anupam, Dirk Balfanz, John 505 Bradley, William Denniss, Nick Harper, Jeff Hodges, Subodh Iyengar, 506 Leif Johansson, Michael B. Jones, Yoav Nir, James Manger, Andrei 507 Popov, Eric Rescorla, Piotr Sikora, Martin Thomson, and Hans Zandbelt 509 Appendix B. Document History 511 [[ to be removed by the RFC Editor before publication as an RFC ]] 513 draft-ietf-tokbind-ttrp-04 515 o Add an example with Sec-Other-Token-Binding-ID. 517 o Use the HEXDIG core ABNF rule for EncodedTokenBindingType and 518 mention case-insensitive in the text. 520 o Minor editorial fixes. 522 o Add to the Acknowledgements and remove the 'and others' bit. 524 draft-ietf-tokbind-ttrp-03 526 o Add a header to allow for additional token binding types other 527 than provided and referred to be conveyed. 529 o Reword the Abstract somewhat for (hopefully) improved readability. 531 o Minor editorial and formatting updates. 533 draft-ietf-tokbind-ttrp-02 535 o Add to the Acknowledgements. 537 o Update references for Token Binding negotiation, protocol, and 538 https. 540 o Use the boilerplate from RFC 8174. 542 o Reformat the "HTTP Header Fields and Processing Rules" section to 543 make the header names more prominent and move the encoding 544 definitions earlier. 546 draft-ietf-tokbind-ttrp-01 548 o Prefix the header names with "Sec-" so that they are denoted as 549 forbidden header names by Fetch https://fetch.spec.whatwg.org/ 551 o Removed potentially confusing sentence from Security 552 Considerations per 553 https://mailarchive.ietf.org/arch/msg/unbearable/ 554 O0IpppyyEqMrQjEkyEi8p8CeBGA 556 o Editorial fixes. 558 o Initial WG draft from draft-campbell-tokbind-ttrp. 560 draft-campbell-tokbind-ttrp-01 562 o Minor editorial fixes. 564 o Add to the Acknowledgements. 566 draft-campbell-tokbind-ttrp-00 568 o Initial draft based on 'consensus to work on the problem' from the 569 Seoul meeting [1][2] and reflecting the consensus approach from 570 discussions at the Chicago meeting [3]. 572 [1] https://www.ietf.org/proceedings/97/minutes/minutes-97- 573 tokbind-01.txt (minutes from Seoul) 574 [2] https://www.ietf.org/proceedings/97/slides/slides-97-tokbind- 575 reverse-proxies-00.pdf (slides from Seoul) 576 [3] https://mailarchive.ietf.org/arch/msg/ 577 unbearable/_ZHI8y2Vs5WMP8VMRr7zroo_sNU (summary of discussion) 579 Author's Address 581 Brian Campbell 582 Ping Identity 584 Email: brian.d.campbell@gmail.com