idnits 2.17.1 draft-ietf-tokbind-ttrp-03.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 (February 25, 2018) is 2246 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 522 -- Looks like a reference, but probably isn't: '2' on line 524 -- Looks like a reference, but probably isn't: '3' on line 526 == 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 February 25, 2018 5 Expires: August 29, 2018 7 HTTPS Token Binding with TLS Terminating Reverse Proxies 8 draft-ietf-tokbind-ttrp-03 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. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 29, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 54 2. HTTP Header Fields and Processing Rules . . . . . . . . . . . 3 55 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. Token Binding ID . . . . . . . . . . . . . . . . . . 4 57 2.1.2. Token Binding Type . . . . . . . . . . . . . . . . . 4 58 2.2. Token Binding ID HTTP Header Fields . . . . . . . . . . . 4 59 2.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.1. Provided Token Binding ID . . . . . . . . . . . . . . 6 62 2.4.2. Provided and Referred Token Binding IDs . . . . . . . 7 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. HTTP Message Header Field Names Registration . . . . . . 9 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 5.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 70 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism 76 that enables HTTP servers to cryptographically bind cookies and other 77 security tokens to a key held by the browser or other HTTP client, 78 possession of which is proven on the TLS [RFC5246] connections over 79 which the tokens are used. When Token Binding is negotiated in the 80 TLS handshake [I-D.ietf-tokbind-negotiation] the client sends an 81 encoded Token Binding Message [I-D.ietf-tokbind-protocol] as a header 82 in each HTTP request, which proves possession of one or more private 83 keys held by the client. The public portion of the keys are 84 represented in the Token Binding IDs of the Token Binding Message and 85 for each one there is a signature over some data, which includes the 86 exported keying material [RFC5705] of the TLS connection. An HTTP 87 server issuing cookies or other security tokens can associate them 88 with the Token Binding ID, which ensures those tokens cannot be used 89 successfully over a different TLS connection or by a different client 90 than the one to which they were issued. 92 A fairly common deployment architecture for HTTPS applications is to 93 have the backend HTTP application servers sit behind a reverse proxy 94 that terminates TLS. The proxy is accessible to the internet and 95 dispatches client requests to the appropriate backend server within a 96 private or protected network. The backend servers are not directly 97 accessible outside the private network and are only reachable through 98 the reverse proxy. The details of such deployments are typically 99 opaque to clients who make requests to the proxy server and see 100 responses as though they originated from the proxy server itself. 101 TLS connections for HTTPS are established between each client and the 102 reverse proxy server. 104 Token Binding facilitates a binding of security tokens to a key held 105 by the client by way of the TLS connection between that client and 106 the server. In a deployment where TLS is terminated by a reverse 107 proxy, however, the TLS connection is between the client and the 108 proxy while the backend server is likely the system that will issue 109 and validate cookies or other security tokens. Additional steps are 110 therefore needed to enable the use of Token Binding in such 111 deployment architectures. In the absence of a standardized approach, 112 different implementations will address it differently, which will 113 make interoperability between such implementations difficult or 114 impossible without complex configurations or custom integrations. 116 This document standardizes HTTP header field names that a TLS 117 terminating reverse proxy (TTRP) adds to requests that it sends to 118 the backend servers. The headers contain information from the 119 validated Token Binding Message sent by the client to the proxy, thus 120 enabling the backend server to bind, or verify the binding of, 121 cookies and other security tokens to the client's Token Binding key. 122 The usage of the headers, both the reverse proxy adding it and the 123 application server using them to bind cookies or other tokens, are to 124 be configuration options of the respective systems as they will not 125 always be applicable. 127 1.1. Requirements Notation and Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. HTTP Header Fields and Processing Rules 137 2.1. Encoding 139 The field-values of the HTTP headers defined herein utilize the 140 following encoded forms. 142 2.1.1. Token Binding ID 144 A Token Binding ID is represented as an "EncodedTokenBindingID", 145 which is thea base64url encoding of the TokenBindingID byte sequence 146 (see section 3 of [I-D.ietf-tokbind-protocol]) using the URL and 147 filename safe alphabet described in Section 5 of [RFC4648], with all 148 trailing pad characters '=' omitted and without the inclusion of any 149 line breaks, whitespace, or other additional characters. ABNF 150 [RFC5234] syntax for "EncodedTokenBindingID" is shown in Figure 1 151 below. 153 EncodedTokenBindingID = *( DIGIT / ALPHA / "-" / "_" ) 155 DIGIT = 156 ALPHA = 158 Figure 1: Encoded Token Binding ID ABNF 160 2.1.2. Token Binding Type 162 A Token Binding type can be represented as an 163 "EncodedTokenBindingType", which is the base16 encoding (Section 8 of 164 [RFC4648]) of the single TokenBindingType byte. ABNF [RFC5234] 165 syntax for "EncodedTokenBindingType" is shown in Figure 2 below. 167 EncodedTokenBindingType = 1*2( DIGIT / 168 "A" / "B" / "C" / "D" / "E" / "F" / 169 "a" / "b" / "c" / "d" / "e" / "f" ) 171 Figure 2: Encoded Token Binding Type ABNF 173 2.2. Token Binding ID HTTP Header Fields 175 The Token Binding Protocol [I-D.ietf-tokbind-protocol] recommends 176 that implementations make Token Binding IDs available to the 177 application as opaque byte sequences, enabling those applications to 178 use the Token Binding IDs when generating and verifying bound tokens. 179 In the context of a TLS terminating reverse proxy (TTRP) deployment, 180 the TTRP makes the Token Binding ID(s) available to the backend 181 application with the following header fields. 183 Sec-Provided-Token-Binding-ID 184 The Token Binding ID of the provided Token Binding represented as 185 an "EncodedTokenBindingID". 187 Sec-Referred-Token-Binding-ID 188 The Token Binding ID of the referred Token Binding represented as 189 an "EncodedTokenBindingID". 191 Sec-Other-Token-Binding-ID 192 Additional Token Bindings, other than provided and referred, that 193 are sent by the client and validated by the TTRP are represented 194 as a comma-separated list of the concatenation of the 195 "EncodedTokenBindingType", a period (".") character, and the 196 "EncodedTokenBindingID" of each. 198 Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding- 199 ID" are single HTTP header field-valued as defined in Section 3.2 of 200 [RFC7230], which MUST NOT have a list of values or occur multiple 201 times in a request. 203 All header fields defined herein are only for use in HTTP requests 204 and MUST NOT to be used in HTTP responses. 206 2.3. Processing Rules 208 This section defines the applicable processing rules for a TLS 209 terminating reverse proxy (TTRP) and backend server(s) to provide 210 server side support of Token Binding over HTTP 211 [I-D.ietf-tokbind-https] using the HTTP headers described in 212 Section 2.2. Use of the technique is to be a configuration or 213 deployment option and the processing rules described herein are for 214 servers operating with that option enabled. 216 A TTRP negotiates the use of Token Binding with the client per 217 [I-D.ietf-tokbind-negotiation] and validates the Token Binding 218 Message as defined in The Token Binding Protocol 219 [I-D.ietf-tokbind-protocol] and Token Binding over HTTP 220 [I-D.ietf-tokbind-https] for each HTTP request on the underlying TLS 221 connection. Requests with a valid Token Binding Message (and meeting 222 any other authorization or policy requirements of the TTRP) are 223 dispatched to the backend server with the following modifications. 225 1. The "Sec-Token-Binding" header in the original incoming request 226 MUST be removed from the request that is dispatched to the 227 backend server. 229 2. The Token Binding ID of the provided Token Binding of the Token 230 Binding Message MUST be placed in the "Sec-Provided-Token- 231 Binding-ID" header field of the dispatched request using the 232 format defined in Section 2.2. 234 3. If the Token Binding Message contains a referred Token Binding, 235 the referred Token Binding ID MUST be placed in the "Sec- 236 Referred-Token-Binding-ID" header field of the dispatched request 237 using the format defined in Section 2.2. Otherwise, the "Sec- 238 Referred-Token-Binding-ID" header field MUST NOT be present in 239 the dispatched request. 241 4. If the Token Binding Message contains any additional validated 242 Token Bindings, they are placed in the "Sec-Other-Token-Binding- 243 ID" header field using the format defined in Section 2.2. If the 244 Token Binding Message contains no additional valid Token 245 Bindings, the "Sec-Referred-Token-Binding-ID" header field MUST 246 NOT be present in the dispatched request. 248 5. Any occurrence of the "Sec-Provided-Token-Binding-ID", "Sec- 249 Referred-Token-Binding-ID", and "Sec-Other-Token-Binding-ID" 250 headers in the original incoming request MUST be removed or 251 overwritten before forwarding the request. 253 Requests made over a connection where the use of Token Binding was 254 not negotiated MUST be sanitized by removing any occurrences of the 255 "Sec-Provided-Token-Binding-ID", "Sec-Referred-Token-Binding-ID", and 256 "Sec-Other-Token-Binding-ID" header fields prior to dispatching the 257 request to the backend server. 259 Forward proxies and other intermediaries MUST NOT add the "Sec- 260 Provided-Token-Binding-ID" "Sec-Referred-Token-Binding-ID", or "Sec- 261 Other-Token-Binding-ID" header to requests. 263 2.4. Examples 265 Extra line breaks and whitespace have been added to the following 266 examples for display and formatting purposes only. 268 2.4.1. Provided Token Binding ID 270 The following "Sec-Token-Binding" header is from an HTTP request made 271 over a TLS connection between the client and the TTRP where the use 272 of Token Binding has been negotiated (The base64url-encoded 273 representation of the exported keying material, which can be used to 274 validate the Token Binding Message, for that connection is 275 "AYVUayPTP9RmELNpGjFl6Ykm2CUx7pUMxe35yb11dgU"). The encoded Token 276 Binding Message has the provided Token Binding the client uses with 277 the server. 279 Sec-Token-Binding: AIkAAgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_YKTZfFJv 280 6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKkAQEtxe4jeUJU0WezxlQ 281 XWVSBFeHxFMdXRBIH_LKOSAuSMOJ0XEw1Q8DE248qkOiRKzw3KdSNYukYEPmO21bQi 282 3YYAAA 284 Figure 3: Header in HTTP Request to TTRP 286 After validating the Token Binding Message, the TTRP removes the 287 "Sec-Token-Binding" header and adds the following "Sec-Provided- 288 Token-Binding-ID" header with the provided Token Binding ID to the 289 request that is dispatched to the backend server. 291 Sec-Provided-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 292 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 294 Figure 4: Header in HTTP Request to Backend Server 296 2.4.2. Provided and Referred Token Binding IDs 298 The following "Sec-Token-Binding" header is from an HTTP request made 299 over a TLS connection between the client and the TTRP where the use 300 of Token Binding has been negotiated (The base64url-encoded 301 representation of the exported keying material, which can be used to 302 validate the Token Binding Message, for that connection is 303 "wEWWCP1KPxfq-QL4NxYII_P4ti_9YYqrTpGs28BZEqE"). The encoded Token 304 Binding Message has the provided Token Binding the client uses with 305 the server as well as the referred Token Binding that it uses with a 306 different server. 308 Sec-Token-Binding: ARIAAgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGjHPJchPav 309 NbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-psAQMyYIqXj7djGPev1dk 310 jV9XxLYGCyqOrBVEtBHrMUCeo22ymLg3OiFcl_fmOPxJbjxI6lKcF0lyfy-dSQmPIe 311 zQ0AAAECAEFArPIiuZxj9gK0dWhIcG63r2-sZ8V3LX9gpNl8Um_oGOtmwoP1v0VHNI 312 HEOzW3BOqcBLvUzVEG6a6KGEj3GrFcqQBAHQm0pzgUTXKLRamuKE1pmmP9I3UBVpoe 313 1DBCe9H2l1VPpsImakUa6crAqZ-0CGBmji7bYzQogpKcyxTTFk5zdwAA 315 Figure 5: Header in HTTP Request to TTRP 317 After validating the Token Binding Message, the TTRP removes the 318 "Sec-Token-Binding" header and adds the following "Sec-Provided- 319 Token-Binding-ID" and "Sec-Referred-Token-Binding-ID" headers, with 320 the provided and referred Token Binding IDs respectively, to the 321 request that is dispatched to the backend server. 323 Sec-Provided-Token-Binding-ID: AgBBQCfsI1D1sTq5mvT_2H_dihNIvuHJCHGj 324 HPJchPavNbGrOo26-2JgT_IsbvZd4daDFbirYBIwJ-TK1rh8FzrC-ps 325 Sec-Referred-Token-Binding-ID: AgBBQKzyIrmcY_YCtHVoSHBut69vrGfFdy1_ 326 YKTZfFJv6BjrZsKD9b9FRzSBxDs1twTqnAS71M1RBumuihhI9xqxXKk 328 Figure 6: Headers in HTTP Request to Backend Server 330 3. Security Considerations 332 The headers described herein enable a reverse proxy and backend 333 server to function together as though they are single logical server 334 side deployment of HTTPS Token Binding. Use of the headers outside 335 that intended use case, however, may undermine the protections 336 afforded by Token Binding. Therefore steps MUST be taken to prevent 337 unintended use, both in sending the headers and in relying on their 338 value. 340 Producing and consuming the headers SHOULD be a configurable option, 341 respectively, in a reverse proxy and backend server (or individual 342 application in that server). The default configuration for both 343 should be to not use the headers thus requiring an "opt-in" to the 344 functionality. 346 Backend servers MUST only accept the headers from trusted reverse 347 proxies. And reverse proxies MUST sanitize the incoming request 348 before forwarding it on by removing or overwriting any existing 349 instances of the headers. Otherwise arbitrary clients can control 350 the header values as seen and used by the backend server. 352 The communication between a reverse proxy and backend server needs to 353 be secured against eavesdropping and modification by unintended 354 parties. 356 The configuration options and request sanitization are necessarily 357 functionally of the respective servers. The other requirements can 358 be met in a number of ways, which will vary based on specific 359 deployments. The communication between a reverse proxy and backend 360 server, for example, might be over a mutually authenticated TLS with 361 the insertion and consumption headers occurring only on that 362 connection. Alternatively the network topology might dictate a 363 private network such that the backend application is only able to 364 accept requests from the reverse proxy and the proxy can only make 365 requests to that server. Other deployments that meet the 366 requirements set forth herein are also possible. 368 Employing the "Sec-" header field prefix for the headers defined 369 herein denotes them as forbidden header names (see [fetch-spec]), 370 which means they cannot be set or modified programmatically by script 371 running in-browser. 373 4. IANA Considerations 374 4.1. HTTP Message Header Field Names Registration 376 This document specifies the following new HTTP header fields, 377 registration of which is requested in the "Permanent Message Header 378 Field Names" registry defined in [RFC3864]. 380 o Header Field Name: "Sec-Provided-Token-Binding-ID" 381 o Applicable protocol: HTTP 382 o Status: standard 383 o Author/change Controller: IETF 384 o Specification Document(s): [[ this specification ]] 386 o Header Field Name: "Sec-Referred-Token-Binding-ID" 387 o Applicable protocol: HTTP 388 o Status: standard 389 o Author/change Controller: IETF 390 o Specification Document(s): [[ this specification ]] 392 o Header Field Name: "Sec-Other-Token-Binding-ID" 393 o Applicable protocol: HTTP 394 o Status: standard 395 o Author/change Controller: IETF 396 o Specification Document(s): [[ this specification ]] 398 5. References 400 5.1. Normative References 402 [I-D.ietf-tokbind-https] 403 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 404 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 405 tokbind-https-12 (work in progress), January 2018. 407 [I-D.ietf-tokbind-negotiation] 408 Popov, A., Nystrom, M., Balfanz, D., and A. Langley, 409 "Transport Layer Security (TLS) Extension for Token 410 Binding Protocol Negotiation", draft-ietf-tokbind- 411 negotiation-10 (work in progress), October 2017. 413 [I-D.ietf-tokbind-protocol] 414 Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. 415 Hodges, "The Token Binding Protocol Version 1.0", draft- 416 ietf-tokbind-protocol-16 (work in progress), October 2017. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 424 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 425 . 427 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 428 Specifications: ABNF", STD 68, RFC 5234, 429 DOI 10.17487/RFC5234, January 2008, 430 . 432 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 433 (TLS) Protocol Version 1.2", RFC 5246, 434 DOI 10.17487/RFC5246, August 2008, 435 . 437 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 438 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 439 March 2010, . 441 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 442 Protocol (HTTP/1.1): Message Syntax and Routing", 443 RFC 7230, DOI 10.17487/RFC7230, June 2014, 444 . 446 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 447 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 448 May 2017, . 450 5.2. Informative References 452 [fetch-spec] 453 WhatWG, "Fetch", Living Standard , 454 . 456 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 457 Procedures for Message Header Fields", BCP 90, RFC 3864, 458 DOI 10.17487/RFC3864, September 2004, 459 . 461 Appendix A. Acknowledgements 463 The author would like to thank the following people for their various 464 contributions to the specification: Vinod Anupam, Dirk Balfanz, John 465 Bradley, William Denniss, Nick Harper, Jeff Hodges, Subodh Iyengar, 466 Leif Johansson, Michael B. Jones, Yoav Nir, Andrei Popov, Eric 467 Rescorla, Piotr Sikora, Martin Thomson, Hans Zandbelt and others 468 (please let me know, if you've contributed and I've forgotten you). 470 Appendix B. Document History 472 [[ to be removed by the RFC Editor before publication as an RFC ]] 474 draft-ietf-tokbind-ttrp-03 476 o Add a header to allow for additional token binding types other 477 than provided and referred to be conveyed. 479 o Reword the Abstract somewhat for (hopefully) improved readability. 481 o Minor editorial and formatting updates. 483 draft-ietf-tokbind-ttrp-02 485 o Add to the Acknowledgements. 487 o Update references for Token Binding negotiation, protocol, and 488 https. 490 o Use the boilerplate from RFC 8174. 492 o Reformat the "HTTP Header Fields and Processing Rules" section to 493 make the header names more prominent and move the encoding 494 definitions earlier. 496 draft-ietf-tokbind-ttrp-01 498 o Prefix the header names with "Sec-" so that they are denoted as 499 forbidden header names by Fetch https://fetch.spec.whatwg.org/ 501 o Removed potentially confusing sentence from Security 502 Considerations per 503 https://mailarchive.ietf.org/arch/msg/unbearable/ 504 O0IpppyyEqMrQjEkyEi8p8CeBGA 506 o Editorial fixes. 508 draft-ietf-tokbind-ttrp-00 510 o Initial WG draft from draft-campbell-tokbind-ttrp. 512 draft-campbell-tokbind-ttrp-01 514 o Minor editorial fixes. 516 o Add to the Acknowledgements. 518 o Initial draft based on 'consensus to work on the problem' from the 519 Seoul meeting [1][2] and reflecting the consensus approach from 520 discussions at the Chicago meeting [3]. 522 [1] https://www.ietf.org/proceedings/97/minutes/minutes-97- 523 tokbind-01.txt (minutes from Seoul) 524 [2] https://www.ietf.org/proceedings/97/slides/slides-97-tokbind- 525 reverse-proxies-00.pdf (slides from Seoul) 526 [3] https://mailarchive.ietf.org/arch/msg/ 527 unbearable/_ZHI8y2Vs5WMP8VMRr7zroo_sNU (summary of discussion) 529 Author's Address 531 Brian Campbell 532 Ping Identity 534 Email: brian.d.campbell@gmail.com