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