idnits 2.17.1 draft-loreto-httpbis-explicitly-auth-proxy-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 15 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2014) is 3643 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 623 -- Looks like a reference, but probably isn't: '2' on line 625 -- Looks like a reference, but probably isn't: '3' on line 628 == Unused Reference: 'I-D.ietf-httpbis-http2' is defined on line 574, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 == Outdated reference: A later version (-01) exists of draft-nottingham-http-proxy-problem-00 ** Downref: Normative reference to an Informational draft: draft-nottingham-http-proxy-problem (ref. 'I-D.nottingham-http-proxy-problem') ** Downref: Normative reference to an Informational draft: draft-rpeon-httpbis-exproxy (ref. 'I-D.rpeon-httpbis-exproxy') ** Downref: Normative reference to an Informational draft: draft-vidya-httpbis-explicit-proxy-ps (ref. 'I-D.vidya-httpbis-explicit-proxy-ps') ** Obsolete normative reference: RFC 3709 (Obsoleted by RFC 9399) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Loreto, Ed. 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track R. Skog 5 Expires: November 6, 2014 H. Spaak 6 Ericsson 7 G. Bourg 8 D. Druta 9 M. Hafeez 10 AT&T 11 May 5, 2014 13 Explicitly Authenticated Proxy in HTTP/2.0 14 draft-loreto-httpbis-explicitly-auth-proxy-00 16 Abstract 18 This document proposes the definition of an Explicitly Authenticated 19 Proxy as intermediary of normally unprotected "http://" URI scheme 20 requests and responses of HTTP2 traffic. 22 An Explicitly Authenticated Proxy is a message forwarding agent that 23 is selected, with explicit user's consent, and configured by the user 24 agent to receive exclusively "http" URI scheme requests and attempt 25 to satisfy those requests on behalf of the user agent. A client is 26 connected to an Explicitly Authenticated Proxy through an 27 authenticated TLS secured connection. 29 This document describes a method for a user agent to automatically 30 discover and authenticate, and for an user to provide consent for an 31 Explicitly Authenticated Proxy. This enables proxied communication 32 to be encrypted and authenticated, explicitly acknowledged by the 33 user agent and visible to the server end point. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 6, 2014. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Explicitly Authenticated Proxy . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Establishing proxy connection . . . . . . . . . . . . . . . . 5 72 3.1. Proxy certificate . . . . . . . . . . . . . . . . . . . . 5 73 3.2. TLS Handshake with Proxy certificate . . . . . . . . . . 6 74 3.3. Opt Out . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4. Connection with prior knowledge . . . . . . . . . . . . . 8 76 4. Explicit Proxy behaviour . . . . . . . . . . . . . . . . . . 8 77 4.1. Explicitly Authenticated Forward Proxy towards HTTP2 78 origin server . . . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Explicitly Authenticated Forward Proxy towards HTTP/1.1 80 Origin Server . . . . . . . . . . . . . . . . . . . . . . 10 81 4.3. Explicitly Authenticated Forward Proxy and https URIs . . 11 82 5. Signalling the presence of a Proxy in between . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . 15 88 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 HTTP/1.1 and earlier allowed for the use of proxies and gateways to 94 satisfy requests through a chain of connections. This has made 95 possible a Web ecosystem of various kinds of proxies and gateways: 96 cache servers, security gateways, web accelerators, content filters, 97 and many others. In some cases their presence is explicit 98 (configured proxies), and in other they are completely transparent to 99 the end user (interception proxies, and gateways such as reverse 100 proxies). 102 The success and the presence of the proxies and gateways is also a 103 problem for the evolution of the HTTP as their behaviour on protocol 104 extensions, and especially on alternative wire formats of the 105 protocol, is not predictable. This unpredictable behaviour can lead 106 to difficulties to deploy new versions of the protocol before the 107 intermediaries are themselves updated. As an example, see the 108 difficulties in deploying the WebSocket Protocol [RFC6455] in clear. 109 It can also lead to potentially problematic trust models where 110 proxies are accessing traffic content without the user being aware. 111 Relying on establishing an HTTPS tunnel has then become the popular 112 way to bypass the intermediate proxies as it provides reliable 113 deployment model for web protocols. The encrypted tunnel obfuscates 114 the data from all intermediaries and provides integrity validation. 116 HTTPS tunnels, while speeding up the deployment, make it difficult 117 for a forward proxy and other gateways to be used to enable caching, 118 enhance anonymity for a user agent, or enhance security by scanning 119 content for virus and malware. HTTPS tunnels also remove the 120 possibility to enhance delivery performance based on the knowledge of 121 the network status, and this become an important limitation 122 especially with HTTP2 when multiple streams are multiplexed on top of 123 the same TCP connection. 125 Several drafts analysing the role and the requirements for proxy have 126 been submitted: 128 1. [I-D.nottingham-http-proxy-problem] discusses the use and 129 configuration of proxies in HTTP, pointing out problems in the 130 currently deployed Web infrastructure along the way 132 2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with 133 HTTP proxies for TLS protected traffic and motivates the need for 134 explicit proxying capability in HTTP. It also presents the goals 135 that such a solution would need to satisfy and some example 136 solution directions. 138 3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to 139 a proxy via a secure channel, allowing, disallowing, and 140 detecting any transforms that the proxy may perform, and allowing 141 the proxy to connect via secure channel to another site on the 142 user's behalf. 144 Use cases in form of stories for proxies are also listed in the wiki 145 Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy 146 Use Case Analysis and Alternatives [2]. 148 This draft explicitly narrows down the general discussion to the role 149 of Proxy as intermediary of "http" scheme URIs of HTTP2 traffic. 151 1.1. Explicitly Authenticated Proxy 153 An "Explicitly Authenticated", as defined in this document, is an 154 HTTP Proxy (see section 2.3 [I-D.ietf-httpbis-p1-messaging]) that is 155 certificate authenticated, user acknowledged and connected to over a 156 TLS encrypted (and possibly integrity protected) connection. An 157 Explicitly Authenticated Proxy is configured by the user agent to 158 exclusively receive "http" URI scheme requests and attempt to satisfy 159 those requests on behalf of the user agent. 161 The presence of a configured Explicitly Authenticated Proxy MUST NOT 162 change the user agent behaviour for the "https" URI scheme requests. 163 To distinguish between an HTTP2 connection meant to transport "https" 164 URIs resources and an HTTP2 connection meant to transport "http" URIs 165 resource, this document defines the ALPN 166 [I-D.ietf-tls-applayerprotoneg] identifier "h2c" to signal that HTTP2 167 transports "http://" URI requests and resources over TLS. 169 This document describes a method for an user agent to automatically 170 discover and then for an user to accept or reject (i.e. to provide 171 consent for) an Explicitly Authenticated Proxy to be securely 172 involved when a request to an "http" URI resource is made. 174 Section 3.1 defines a solution based on sending a proxy certificate 175 in the TLS handshake. 177 Section 4 describes the role of the Explicitly Authenticated Proxy in 178 helping the user to fetch "http" URIs resource when the user has 179 provided consent to the Explicitly Authenticated Proxy to be 180 involved. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 This document defines the following terms: 190 Explicit proxy: an intercepting proxy that communicates its 191 presence to the user agent and destination server. 193 Explicitly Authenticated Proxy: a message forwarding agent that is 194 certificate authenticated, user acknowledged and connected to over 195 a TLS encrypted connection. A Explicitly Authenticated Proxy is 196 configured by the user agent to exclusively receive "http" URI 197 scheme request and attempt to satisfy those request on behalf of 198 the user agent. 200 3. Establishing proxy connection 202 An Explicitly Authenticated Proxy indicates its presence, identity 203 and willingness to serve the user agent by intercepting TLS 204 ClientHello message containing "h2c" value (a new ALPN protocol type 205 assigned for this purpose) in the ALPN 206 [I-D.ietf-tls-applayerprotoneg] negotiation extension field. It 207 answers the TLS initiation with a TLS ServerHello message containing 208 the Proxy certificate. 210 3.1. Proxy certificate 212 To help HTTP user agents identify and distinguish Explicitly 213 Authenticated proxies from other servers (e.g. web servers), 214 Explicitly Authenticated proxies should have a certification 215 authority issued public key certificate. 217 More specifically, the certification authority SHOULD use the 218 Extended Key Usage extension as specified in [RFC5280] to indicate a 219 key purpose "proxyAuthentication" (a new object identifier needs to 220 be assigned by IANA for this key purpose). The certification 221 authority also marks this Extended Key Usage extension as critical. 222 As the user needs to have high trust in the Proxy, it is desirable 223 that the validation procedure for issuing proxy certificates be more 224 rigorous than for issuing ordinary SSL certificates. 226 A proxy certificate MUST contain the SubjectAltName extension as 227 defined in [RFC5280]. A name identifying the legal entity that is 228 operating the proxy should be given in this extension. 230 To help end users understand the reason why the proxy is offered (in 231 other words, the benefits of having the proxy in the path), a new 232 X.509 certificate extension ProxyFunctions is introduced to list the 233 functions the proxy is performing. More specifically, the 234 ProxyFunction extension consists of a sequence of ProxyFunctionId 235 which are object identifiers. The user agent should check the 236 presence of this extension in the proxy certificate and present the 237 proxy functions in a human readable format. 239 The user agent will provide the user with an opportunity to 240 graphically view the results of a successful proxy certificate-based 241 identification process leveraging on the usage of logotypes in public 242 key certificates and attribute certificates as specified in 243 [RFC3709]. 245 3.2. TLS Handshake with Proxy certificate 247 When a (TLS and HTTP) user agent receives a Server Certificate 248 message, it checks whether the certificate contains an Extended Key 249 Usage extension and if so whether the "proxyAuthentication" key 250 purpose id is included. If it is included, the user agent concludes 251 that the certificate belongs to a proxy. The user agent then SHOULD 252 ensure user consent. 254 The user selection can be cached by the user agent. A consent SHOULD 255 however be limited to the specific network access (such as APN or 256 SSID) and may be limited to a single connection to that access or 257 limited in time. How the consent information is stored is 258 implementation specific, but as a network may have several proxies 259 (for network resilience) it is RECOMMENDED that the consent is only 260 tied to the Subject field of the proxy certificate so that the 261 consent applies to all proxy certificates with the same name. 263 If the user provides consent, the user agent continues the TLS 264 handshake with the proxy. 266 +--------------+ +------------+ +-------------+ 267 | User agent | | Proxy | | Server | 268 +--------------+ +------------+ +-------------+ 269 | | | 270 | | | 271 | (1) ClientHello | | 272 |---------------------------->| | 273 | ALPN Protocol Name: h2c | | 274 | | | 275 | | | 276 | (2) ServerHello, ServerCert | | 277 |<----------------------------| | 278 | (Proxy cert) | | 279 | | | 280 | | | 281 (3) User consent | | 282 | | | 283 | (4) Rest of TLS handshake | | 284 |<--------------------------->| | 285 | | | 286 | (5) HTTP2 over TLS | (5) HTTP2 over TLS | 287 |<--------------------------->|<-------------------------->| 288 | | | 289 | | | 291 Figure 1: TLS Handshake with Proxy certificate 293 3.3. Opt Out 295 If the user does not give consent, or decides to opt out from the 296 proxy for a specific connection, the user agent will negotiate HTTP2 297 connection using "h2" value in the ALPN extension field. The proxy 298 will then treat the connection as an "https" connection and will 299 forward the ClientHello message to the Server, establishing an end- 300 to-end TLS connection between the user agent and the destination 301 server. 303 +--------------+ +------------+ +-------------+ 304 | User agent | | Proxy | | Server | 305 +--------------+ +------------+ +-------------+ 306 | | 307 | (1) ClientHello | 308 |---------------------------------------------------------->| 309 | (ALPN ProtocolName: h2) | 310 | | 311 | (2) ServerHello, ServerCert | 312 |<----------------------------------------------------------| 313 | (3) Rest of TLS handshake | 314 |<--------------------------------------------------------->| 315 | | 316 | (4) HTTP2 over TLS | 317 |<--------------------------------------------------------->| 318 | | 320 Figure 2: Opt Out 322 3.4. Connection with prior knowledge 324 The HTTP2 user agent can discover the presence of a HTTP2 proxy for 325 http:// resources before it starts the creation of the TLS 326 connection. As an example, for a mobile handset, the discovery might 327 occur at the network attachment. 329 Then the user agent validates the proxy certificate as per section 330 Section 3.1 and requests "http://" resources as per Section 4. 332 4. Explicit Proxy behaviour 334 This section describes the role of the Explicitly Authenticated Proxy 335 in helping the user to fetch http URI resources when the user has 336 provided consent to the Explicitly Authenticated Proxy to be 337 involved. 339 4.1. Explicitly Authenticated Forward Proxy towards HTTP2 origin server 340 +--------------+ +--------------+ +--------------+ 341 | User agent | | Proxy | | Server | 342 +--------------+ +--------------+ +--------------+ 343 | | | 344 (TLS Proxy certificate ) | | 345 (mechanism has taken place) | | 346 | | | 347 | (1) ClientHello | | 348 |--------------------------->| | 349 | (2) ServerHello | | 350 |<---------------------------| | 351 | (3) ChangeCipherSpec | | 352 |--------------------------->| | 353 | (4) ChangeCipherSpec | | 354 |<---------------------------| | 355 | | | 356 | | | 357 |/========= HTTP2 ==========\| | 358 | | | 359 |--(5)-stream(X)---GET------>| | 360 | | (6) TLS ClientHello | 361 | |----------------------------->| 362 | | (7) TLS ServerHello | 363 | |<-----------------------------| 364 | | (8) ChangeCipherSpec | 365 | |----------------------------->| 366 | | (9) ChangeCipherSpec | 367 | |<-----------------------------| 368 | | | 369 | |/========= HTTP2 ============\| 370 | |--(10)--stream(Z)---GET------>| 371 | | | 372 | | | 373 | |<-(11)--stream(Z)---200 OK----| 374 |<-(12)--stream(X)---200 OK--| | 375 | | | 376 |\======== HTTP2 ===========/|\========== HTTP2 ===========/| 377 | | | 379 Figure 3: Requesting an HTTP resource 381 (0) The TLS Proxy Announcement (Section 3.1) mechanism has already 382 taken place, so the user agent is now configured in the proxy 383 mode. 385 (1)...(4) For each "http" URI resource towards a not yet contacted 386 Server Origin, the user agent negotiates a new TLS session, using 387 the ALPN extension containing the "h2c" tag, to establish an HTTP2 388 connection. 390 (5) The user agent will then use the streams in the HTTP2 connection 391 to request any resources hosted on that Origin Server. 393 (6)...(9) In the case the Proxy receives a request for a resource 394 towards a not yet contacted Server Origin, the Explicitly 395 Authenticated Proxy negotiates a new TLS session, using the ALPN 396 extension containing the "h2c" ALPN identifier, to establish an 397 HTTP2 connection. 399 (10) Once the Proxy has established the HTTP2 connection toward the 400 origin, it picks one stream to forward the request 402 (11), (12) The Proxy forwards the answer it receives from the Origin 403 Server to the user agent. 405 4.2. Explicitly Authenticated Forward Proxy towards HTTP/1.1 Origin 406 Server 408 In the case the "http" URI resources requested by the user agent will 409 be only available over HTTP/1.1 or the proxy does not have a previous 410 knowledge about it, the proxy will then attempt to contact the 411 resource based on its knowledge. 413 +--------------+ +--------------+ +--------------+ 414 | User agent | | Proxy | | Server | 415 +--------------+ +--------------+ +--------------+ 416 | | | 417 (TLS Proxy announcement ) | | 418 (mechanism has taken place) | | 419 | | | 420 | (1) TLS ClientHello | | 421 |--------------------------->| | 422 | (2) ServerHello | | 423 |<---------------------------| | 424 | (3) ChangeCipherSpec | | 425 |--------------------------->| | 426 | (4) ChangeCipherSpec | | 427 |<---------------------------| | 428 | | | 429 |/--------------------------\| | 430 |--(5)-stream(X)---GET------>| | 431 | | | 432 | HTTP2 |--(6)------GET /1.1---------->| 433 | | | 434 | |<-(7)-------200 OK------------| 435 |<-(8)--stream(X)---200 OK---| | 436 | | | 437 |\--------------------------/| | 438 | | | 440 Figure 4: Origin server with only HTTP/1.1 support 442 4.3. Explicitly Authenticated Forward Proxy and https URIs 444 A user agent MUST NOT use "h2c" as ALPN extension field in request 445 for https resources. 447 The Proxy that intercepts the TLS ClientHello analyses the ALPN 448 extension field and if it does not contain the "h2c" value it does 449 not do anything and lets the TLS handshake continue and the TLS 450 session be established between the user agent and the Server (see 451 Figure 5). 453 +--------------+ +------------+ +-------------+ 454 | User agent | | Proxy | | Server | 455 +--------------+ +------------+ +-------------+ 456 | | | 457 | | | 458 | (1) TLS ClientHello | 459 |----------------------------------------------------------->| 460 | (ALPN ProtocolName: h2) | 461 | (2) ServerHello | 462 |<-----------------------------------------------------------| 463 | (3) ChangeCipherSpec | 464 |----------------------------------------------------------->| 465 | (4) ChangeCipherSpec | 466 |<-----------------------------------------------------------| 467 | | 468 |---(5)-stream(X)---GET------------------------------------->| 469 | | 470 |<-------------------------(6)--stream(X)---200 OK-----------| 472 Figure 5: Explicitly Authenticated Proxy and https URI resources 474 5. Signalling the presence of a Proxy in between 476 The presence of Explicitly Authenticated Proxy in between an user 477 agent and the origin server must be signalled to the origin server 478 using an already defined HTTP header. 480 The Explicitly Authenticated proxy MUST add, or update when already 481 present, the Forwarded HTTP header field 482 [I-D.ietf-appsawg-http-forwarded] "for" parameter. 484 6. Security Considerations 486 This document addresses Explicitly Authenticated proxies that act as 487 intermediary for HTTP2 traffic and therefore the security and privacy 488 implications of having those proxies in the path need to be 489 considered. MITM [3], [I-D.nottingham-http-proxy-problem] and 490 [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and 491 privacy issues associated with the use of proxies. 493 It should however be noticed that the presence of the Explicitly 494 Authenticated proxy as discussed in this document does not in any way 495 affect "https" URI resources. Those resources are protected end-to- 496 end between user agent and origin server as usual. Only for "http" 497 URI resources the achievable security level of hop-by-hop protection 498 may be different than end-to-end protection, because it is now also 499 dependent on the security features/capabilities of the proxy as to 500 what cipher suites it supports, which root CA certificates it trusts, 501 how it checks certificate revocation status, etc. Users should also 502 be made aware that the proxy has visibility to the actual content 503 they exchange with Web servers, including personal and sensitive 504 information. 506 The TLS connection from the user agent to the Explicitly 507 Authenticated proxy is always authenticated. In case the origin 508 server only offers unauthenticated TLS (e.g. by using a self-signed 509 certificate) the explicit Explicitly Authenticated proxy increases 510 the security in the access network (e.g. an unencrypted hotspot) by 511 ensuring that there is no unwanted MITMs in this part of the network. 513 To ensure the trustfulness of proxies, certification authorities 514 validation procedure for issuing proxy certificates should be more 515 rigorous than for issuing normal certificates and may also include 516 technical details and processes relevant for the security assurance. 517 The owner of the proxy could for example be obliged to apply security 518 patches in a timely fashion. 520 When negotiating ciphersuite with the server, the Explicitly 521 Authenticated proxy SHALL offer the ciphersuite negotiated between 522 the user-agent and the proxy. Ciphersuites with a higher security 523 level that the ciphersuite negotiated between the user-agent and 524 proxy MAY be given a higher preference than the ciphersuite 525 negotiated between the user-agent and proxy. Ciphersuites with a 526 lower security level that the ciphersuite negotiated between the 527 user-agent and proxy SHALL NOT be given a higher preference than the 528 ciphersuite negotiated between the user-agent and proxy. While 529 AES-256 is no weaker (an most probably much stronger) than AES-128, 530 the relative security between different algorithm e.g SHA-256 vs 531 Keccak-256 is not that clear. With security level we mean the 532 complexity of the best known attack on that ciphersuite. The 533 Explicitly Authenticated proxy SHOULD therefore be up to date with 534 the best current practices regarding TLS. 536 This document proposes an approach to making the presence of proxy 537 explicit to users and letting them decide whether they accept that. 538 A user can opt out and choose to bypass the proxy. This ensures that 539 a proxy never acts as intermediary for HTTP2 traffic unless 540 authorised by the user. 542 When the user has given consent to the presence of the proxy, the 543 user agent switches to a Proxy mode in which it does not check the 544 hostname of the origin server against the server's identity as 545 presented in the Server Certificate message. However if any of the 546 following checks fails the user agent should immediately exit this 547 Proxy mode: 549 1. the server's certificate is issued by a trusted CA and the 550 certificate is valid; 552 2. the Extended Key Usage extension is present in the certificate 553 and indicates the owner of this certificate is a proxy; 555 3. the server possesses the private key corresponding to the 556 certificate. 558 7. Acknowledgments 560 The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson, 561 Nicolas Mailhot, Martin Nilsson, Emile Stephan (Connection with prior 562 knowledge) and Salman Taj for their ideas, technical suggestions and 563 comments. 565 8. References 567 8.1. Normative References 569 [I-D.ietf-appsawg-http-forwarded] 570 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 571 draft-ietf-appsawg-http-forwarded-10 (work in progress), 572 October 2012. 574 [I-D.ietf-httpbis-http2] 575 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 576 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 577 progress), April 2014. 579 [I-D.ietf-httpbis-p1-messaging] 580 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 581 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 582 httpbis-p1-messaging-26 (work in progress), February 2014. 584 [I-D.ietf-tls-applayerprotoneg] 585 Friedl, S., Popov, A., Langley, A., and S. Emile, 586 "Transport Layer Security (TLS) Application Layer Protocol 587 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 588 (work in progress), March 2014. 590 [I-D.nottingham-http-proxy-problem] 591 Nottingham, M., "Problems with Proxies in HTTP", draft- 592 nottingham-http-proxy-problem-00 (work in progress), 593 October 2013. 595 [I-D.rpeon-httpbis-exproxy] 596 Peon, R., "Explicit Proxies for HTTP/2.0", draft-rpeon- 597 httpbis-exproxy-00 (work in progress), June 2012. 599 [I-D.vidya-httpbis-explicit-proxy-ps] 600 Narayanan, V., "Explicit Proxying in HTTP - Problem 601 Statement And Goals", draft-vidya-httpbis-explicit-proxy- 602 ps-00 (work in progress), October 2013. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet 608 X.509 Public Key Infrastructure: Logotypes in X.509 609 Certificates", RFC 3709, February 2004. 611 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 612 Housley, R., and W. Polk, "Internet X.509 Public Key 613 Infrastructure Certificate and Certificate Revocation List 614 (CRL) Profile", RFC 5280, May 2008. 616 8.2. Informative References 618 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 619 6455, December 2011. 621 8.3. URIs 623 [1] https://github.com/http2/http2-spec/wiki/Proxy-User-Stories 625 [2] https://github.com/bizzbyster/TrustedProxy/wiki/Trusted-Proxy- 626 Use-Case-Analysis-and-Alternatives 628 [3] Jarmoc, J., SSL/TLS Interception Proxies and Transitive Trust, 629 2012 https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf 631 Authors' Addresses 633 Salvatore Loreto (editor) 634 Ericsson 635 Hirsalantie 11 636 Jorvas 02420 637 Finland 639 Email: salvatore.loreto@ericsson.com 640 John Mattsson 641 Ericsson 642 Kista 643 Sweden 645 Email: john.mattsson@ericsson.com 647 Robert Skog 648 Ericsson 649 Kista 650 Sweden 652 Email: robert.skog@ericsson.com 654 Hans Spaak 655 Ericsson 656 Kista 657 Sweden 659 Email: hans.spaak@ericsson.com 661 Gus Bourg 662 AT&T 664 Email: gb3635@att.com 666 Dan Druta 667 AT&T 669 Email: dd5826@att.com 671 Mohammad Hafeez 672 AT&T 674 Email: mh2897@att.com