idnits 2.17.1 draft-loreto-httpbis-explicitly-auth-proxy-01.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 (July 3, 2014) is 3578 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 630 -- Looks like a reference, but probably isn't: '2' on line 632 -- Looks like a reference, but probably isn't: '3' on line 635 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-13 == 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 (~~), 3 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: January 4, 2015 H. Spaak 6 Ericsson 7 G. Bourg 8 D. Druta 9 M. Hafeez 10 AT&T 11 July 3, 2014 13 Explicitly Authenticated Proxy in HTTP/2.0 14 draft-loreto-httpbis-explicitly-auth-proxy-01 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 January 4, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Goals and non Goals . . . . . . . . . . . . . . . . . . . 4 70 1.2. Explicitly Authenticated Proxy . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Establishing proxy connection . . . . . . . . . . . . . . . . 5 73 3.1. TLS Handshake with Proxy certificate . . . . . . . . . . 5 74 4. Connection to a mobile network . . . . . . . . . . . . . . . 6 75 4.1. proxy discovery in a mobile network . . . . . . . . . . . 7 76 5. Explicit Proxy behaviour . . . . . . . . . . . . . . . . . . 7 77 5.1. Explicitly Authenticated Forward Proxy towards HTTP2 78 origin server . . . . . . . . . . . . . . . . . . . . . . 7 79 5.2. Explicitly Authenticated Forward Proxy towards HTTP/1.1 80 Origin Server . . . . . . . . . . . . . . . . . . . . . . 9 81 5.3. Explicitly Authenticated Forward Proxy and https URIs . . 10 82 6. User Consent . . . . . . . . . . . . . . . . . . . . . . . . 11 83 6.1. Expected behaviour if the user opts out/revokes consent . 11 84 7. Signalling the presence of a Proxy in between . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . 15 90 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Proxy certificate . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 HTTP/1.1 and earlier allowed for the use of proxies and gateways to 97 satisfy requests through a chain of connections. This has made 98 possible a Web ecosystem of various kinds of proxies and gateways: 99 cache servers, security gateways, web accelerators, content filters, 100 and many others. In some cases their presence is explicit 101 (configured proxies), and in other they are completely transparent to 102 the end user (interception proxies, and gateways such as reverse 103 proxies). 105 The success and the presence of the proxies and gateways is also a 106 problem for the evolution of the HTTP as their behaviour on protocol 107 extensions, and especially on alternative wire formats of the 108 protocol, is not predictable. This unpredictable behaviour can lead 109 to difficulties to deploy new versions of the protocol before the 110 intermediaries are themselves updated. As an example, see the 111 difficulties in deploying the WebSocket Protocol [RFC6455] in clear. 112 It can also lead to potentially problematic trust models where 113 proxies are accessing traffic content without the user being aware. 114 Relying on establishing an HTTPS tunnel has then become the popular 115 way to bypass the intermediate proxies as it provides reliable 116 deployment model for web protocols. The encrypted tunnel obfuscates 117 the data from all intermediaries and provides integrity validation. 119 HTTPS tunnels, while speeding up the deployment, make it difficult 120 for a forward proxy and other gateways to be used to enable caching, 121 enhance anonymity for a user agent, or enhance security by scanning 122 content for virus and malware. HTTPS tunnels also remove the 123 possibility to enhance delivery performance based on the knowledge of 124 the network status, and this become an important limitation 125 especially with HTTP2 when multiple streams are multiplexed on top of 126 the same TCP connection. 128 Several drafts analysing the role and the requirements for proxy have 129 been submitted: 131 1. [I-D.nottingham-http-proxy-problem] discusses the use and 132 configuration of proxies in HTTP, pointing out problems in the 133 currently deployed Web infrastructure along the way 135 2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with 136 HTTP proxies for TLS protected traffic and motivates the need for 137 explicit proxying capability in HTTP. It also presents the goals 138 that such a solution would need to satisfy and some example 139 solution directions. 141 3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to 142 a proxy via a secure channel, allowing, disallowing, and 143 detecting any transforms that the proxy may perform, and allowing 144 the proxy to connect via secure channel to another site on the 145 user's behalf. 147 Use cases in form of stories for proxies are also listed in the wiki 148 Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy 149 Use Case Analysis and Alternatives [2]. 151 This draft explicitly narrows down the general discussion to the role 152 of Proxy as intermediary of "http" scheme URIs of HTTP2 traffic. 154 1.1. Goals and non Goals 156 The primary goal is to define an intermediary to 'http' traffic, that 157 is TLS connected to the browser, operates with the knowledge and 158 explicit consent of the user. 160 Non goal is to define an intermediary for 'https' URI. However the 161 intermediary's expected behaviour for this case is listed for 162 completeness. 164 1.2. Explicitly Authenticated Proxy 166 An "Explicitly Authenticated", as defined in this document, is an 167 HTTP Proxy (see section 2.3 [I-D.ietf-httpbis-p1-messaging]) that is 168 certificate authenticated, user acknowledged and connected to over a 169 TLS encrypted (and possibly integrity protected) connection. An 170 Explicitly Authenticated Proxy is configured by the user agent to 171 exclusively receive "http" URI scheme requests and attempt to satisfy 172 those requests on behalf of the user agent. 174 The presence of a configured Explicitly Authenticated Proxy MUST NOT 175 change the user agent behaviour for the "https" URI scheme requests. 177 To distinguish between an HTTP2 connection meant to transport "https" 178 URIs resources and an HTTP2 connection meant to transport "http" URIs 179 resource, this document defines the ALPN 180 [I-D.ietf-tls-applayerprotoneg] identifier "h2c" to signal that HTTP2 181 transports "http" URI requests and resources over TLS. 183 This document describes a method for an user agent to automatically 184 discover and then for an user to accept or reject (i.e. to provide 185 consent for) an Explicitly Authenticated Proxy to be securely 186 involved when a request to an "http" URI resource is made. 188 Section 3 defines a solution based on sending a proxy certificate in 189 the TLS handshake. 191 Section 5 describes the role of the Explicitly Authenticated Proxy in 192 helping the user to fetch "http" URIs resource when the user has 193 provided consent to the Explicitly Authenticated Proxy to be 194 involved. 196 2. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 This document defines the following terms: 204 Explicit proxy: an intercepting proxy (see section 2.3 205 [I-D.ietf-httpbis-p1-messaging]) that communicates its presence to 206 the user agent and destination server.. 208 Explicitly Authenticated Proxy: an HTTP Proxy that is certificate 209 authenticated, user acknowledged and connected to over a TLS 210 encrypted (and possibly integrity protected) connection. An 211 Explicitly Authenticated Proxy is configured by the user agent to 212 exclusively receive "http" URI scheme requests and attempt to 213 satisfy those requests on behalf of the user agent. The presence 214 of a configured Explicitly Authenticated Proxy MUST NOT change the 215 user agent behaviour for the "https" URI scheme requests. 217 3. Establishing proxy connection 219 An Explicitly Authenticated Proxy indicates its presence, identity 220 and willingness to serve the user agent by intercepting TLS 221 ClientHello message containing "h2c" value (a new ALPN protocol type 222 assigned for this purpose) in the ALPN 223 [I-D.ietf-tls-applayerprotoneg] negotiation extension field. It 224 answers the TLS initiation with a TLS ServerHello message containing 225 the Proxy certificate Appendix A . 227 3.1. TLS Handshake with Proxy certificate 229 When a (TLS and HTTP) user agent receives a Server Certificate 230 message, it checks whether the certificate contains an Extended Key 231 Usage extension and if so whether the "proxyAuthentication" key 232 purpose id is included. If it is included, the user agent concludes 233 that the certificate belongs to a proxy. The user agent then SHOULD 234 ensure user consent. 236 If the user provides consent, the user agent continues the TLS 237 handshake with the proxy. 239 +--------------+ +------------+ +-------------+ 240 | User agent | | Proxy | | Server | 241 +--------------+ +------------+ +-------------+ 242 | | | 243 | | | 244 | (1) ClientHello | | 245 |---------------------------->| | 246 | ALPN Protocol Name: h2c | | 247 | | | 248 | | | 249 | (2) ServerHello, ServerCert | | 250 |<----------------------------| | 251 | (Proxy cert) | | 252 | | | 253 | | | 254 (3) User consent | | 255 | | | 256 | (4) Rest of TLS handshake | | 257 |<--------------------------->| | 258 | | | 259 | (5) HTTP2 over TLS | (5) HTTP2 over TLS | 260 |<--------------------------->|<-------------------------->| 261 | | | 262 | | | 264 Figure 1: TLS Handshake with Proxy certificate 266 4. Connection to a mobile network 268 When a handset connects to a mobile network it is desirable to 269 preserve the integrity of its exchange with the servers which host 270 the services of this network entity. These use cases are described 271 in [I-D.nottingham-http-proxy-problem] and in the [Proxy-User- 272 Stories]. 274 This section proposes a solution for such use cases. The proposal is 275 inspired on the connection management specified in the section 9.1 of 276 [I-D.ietf-httpbis-http2]. The connection with this proxy is used for 277 all the servers' names listed in the "subjectAltName" field 278 (http://tools.ietf.org/html/rfc5280#page-35) of the certificate of 279 this proxy. 281 4.1. proxy discovery in a mobile network 283 At the network attachment, as usual, the network entity provides the 284 handset with an IP address and with other pieces of information like 285 DNS resolvers IP addresses. The network entity additionally provides 286 the handset with the server name (e.g. pr.example.com) of the 287 Explicitly Authenticated Proxy in charge of the domain names this 288 network entity is authoritative on. These pieces of information are 289 provided to the handset through a secure channel which preserves the 290 integrity of the information. 292 5. Explicit Proxy behaviour 294 This section describes the role of the Explicitly Authenticated Proxy 295 in helping the user to fetch http URI resources when the user has 296 provided consent to the Explicitly Authenticated Proxy to be 297 involved. 299 5.1. Explicitly Authenticated Forward Proxy towards HTTP2 origin server 300 +--------------+ +--------------+ +--------------+ 301 | User agent | | Proxy | | Server | 302 +--------------+ +--------------+ +--------------+ 303 | | | 304 (TLS Proxy announcement) | | 305 (mechanism has taken place) | | 306 | | | 307 | (1) ClientHello | | 308 |--------------------------->| | 309 | (2) ServerHello | | 310 |<---------------------------| | 311 | (3) ChangeCipherSpec | | 312 |--------------------------->| | 313 | (4) ChangeCipherSpec | | 314 |<---------------------------| | 315 | | | 316 | | | 317 |/========= HTTP2 ==========\| | 318 | | | 319 |--(5)-stream(X)---GET------>| | 320 | | (6) TLS ClientHello | 321 | |----------------------------->| 322 | | (7) TLS ServerHello | 323 | |<-----------------------------| 324 | | (8) ChangeCipherSpec | 325 | |----------------------------->| 326 | | (9) ChangeCipherSpec | 327 | |<-----------------------------| 328 | | | 329 | |/========= HTTP2 ============\| 330 | |--(10)--stream(Z)---GET------>| 331 | | | 332 | | | 333 | |<-(11)--stream(Z)---200 OK----| 334 |<-(12)--stream(X)---200 OK--| | 335 | | | 336 |\======== HTTP2 ===========/|\========== HTTP2 ===========/| 337 | | | 339 Figure 2: Requesting an HTTP resource 341 (0) The TLS Proxy Announcement (Section 3) mechanism has already 342 taken place, so the user agent is now configured in the proxy 343 mode. 345 (1)...(4) For each "http" URI resource towards a not yet contacted 346 Server Origin, the user agent negotiates a new TLS session, using 347 the ALPN extension containing the "h2c" tag, to establish an HTTP2 348 connection. 350 (5) The user agent will then use the streams in the HTTP2 connection 351 to request any resources hosted on that Origin Server. 353 (6)...(9) In the case the Proxy receives a request for a resource 354 towards a not yet contacted Server Origin, the Explicitly 355 Authenticated Proxy negotiates a new TLS session, using the ALPN 356 extension containing the "h2c" ALPN identifier, to establish an 357 HTTP2 connection. 359 (10) Once the Proxy has established the HTTP2 connection toward the 360 origin, it picks one stream to forward the request 362 (11), (12) The Proxy forwards the answer it receives from the Origin 363 Server to the user agent. 365 5.2. Explicitly Authenticated Forward Proxy towards HTTP/1.1 Origin 366 Server 368 In the case the proxy has a privies knowledge about the fact that the 369 "http" URI resources requested by the user agent will be only 370 available over HTTP/1.1 or the proxy does not have a previous 371 knowledge about it, the proxy will then attempt to contact the 372 resource based on its knowledge. 374 +--------------+ +--------------+ +--------------+ 375 | User agent | | Proxy | | Server | 376 +--------------+ +--------------+ +--------------+ 377 | | | 378 (TLS Proxy announcement) | | 379 (mechanism has taken place) | | 380 | | | 381 | (1) TLS ClientHello | | 382 |--------------------------->| | 383 | (2) ServerHello | | 384 |<---------------------------| | 385 | (3) ChangeCipherSpec | | 386 |--------------------------->| | 387 | (4) ChangeCipherSpec | | 388 |<---------------------------| | 389 | | | 390 |/--------------------------\| | 391 |--(5)-stream(X)---GET------>| | 392 | | | 393 | HTTP2 |--(6)------GET /1.1---------->| 394 | | | 395 | |<-(7)-------200 OK------------| 396 |<-(8)--stream(X)---200 OK---| | 397 | | | 398 |\--------------------------/| | 399 | | | 401 Figure 3: Origin server with only HTTP/1.1 support 403 5.3. Explicitly Authenticated Forward Proxy and https URIs 405 A user agent MUST NOT use "h2c" as ALPN extension field in request 406 for https resources. 408 The Proxy that intercepts the TLS ClientHello analyses the ALPN 409 extension field and if it does not contain the "h2c" value it does 410 not do anything and lets the TLS handshake continue and the TLS 411 session be established between the user agent and the Server (see 412 Figure 4). 414 +--------------+ +------------+ +-------------+ 415 | User agent | | Proxy | | Server | 416 +--------------+ +------------+ +-------------+ 417 | | | 418 | | | 419 | (1) TLS ClientHello | 420 |----------------------------------------------------------->| 421 | (ALPN ProtocolName: h2) | 422 | (2) ServerHello | 423 |<-----------------------------------------------------------| 424 | (3) ChangeCipherSpec | 425 |----------------------------------------------------------->| 426 | (4) ChangeCipherSpec | 427 |<-----------------------------------------------------------| 428 | | 429 |---(5)-stream(X)---GET------------------------------------->| 430 | | 431 |<-------------------------(6)--stream(X)---200 OK-----------| 433 Figure 4: Explicitly Authenticated Proxy and https URI resources 435 6. User Consent 437 This document proposes an approach to making the presence of proxy 438 explicit, explaining the functions it provides to users and letting 439 them decide whether they accept that. A user can opt out and choose 440 to bypass the proxy. This ensures that a proxy never acts as 441 intermediary for HTTP2 traffic unless authorised by the user. 443 The user selection can be cached by the user agent. A consent SHOULD 444 however be limited to the specific network access (such as APN or 445 SSID) and may be limited to a single connection to that access or 446 limited in time. How the consent information is stored is 447 implementation specific, but as a network may have several proxies 448 (for network resilience) it is RECOMMENDED that the consent is only 449 tied to the Subject field of the proxy certificate so that the 450 consent applies to all proxy certificates with the same name. 452 6.1. Expected behaviour if the user opts out/revokes consent 454 If the user does not give consent, or decides to opt out from the 455 proxy for a specific connection, the user agent will negotiate HTTP2 456 connection using "h2" value in the ALPN extension field. The proxy 457 will then treat the connection as an "https" connection and will 458 forward the ClientHello message to the Server, establishing an end- 459 to-end TLS connection between the user agent and the destination 460 server. 462 +--------------+ +------------+ +-------------+ 463 | User agent | | Proxy | | Server | 464 +--------------+ +------------+ +-------------+ 465 | | 466 | (1) ClientHello | 467 |---------------------------------------------------------->| 468 | (ALPN ProtocolName: h2) | 469 | | 470 | (2) ServerHello, ServerCert | 471 |<----------------------------------------------------------| 472 | (3) Rest of TLS handshake | 473 |<--------------------------------------------------------->| 474 | | 475 | (4) HTTP2 over TLS | 476 |<--------------------------------------------------------->| 477 | | 479 Figure 5: Opt Out 481 7. Signalling the presence of a Proxy in between 483 The presence of Explicitly Authenticated Proxy in between an user 484 agent and the origin server must be signalled to the origin server 485 using an already defined HTTP header. 487 The Explicitly Authenticated proxy MUST add, or update when already 488 present, the Forwarded HTTP header field 489 [I-D.ietf-appsawg-http-forwarded] "for" parameter. 491 8. Security Considerations 493 This document addresses Explicitly Authenticated proxies that act as 494 intermediary for HTTP2 traffic and therefore the security and privacy 495 implications of having those proxies in the path need to be 496 considered. MITM [3], [I-D.nottingham-http-proxy-problem] and 497 [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and 498 privacy issues associated with the use of proxies. 500 It should however be noticed that the presence of the Explicitly 501 Authenticated proxy as discussed in this document does not in any way 502 affect "https" URI resources. Those resources are protected end-to- 503 end between user agent and origin server as usual. Only for "http" 504 URI resources the achievable security level of hop-by-hop protection 505 may be different than end-to-end protection, because it is now also 506 dependent on the security features/capabilities of the proxy as to 507 what cipher suites it supports, which root CA certificates it trusts, 508 how it checks certificate revocation status, etc. Users should also 509 be made aware that the proxy has visibility to the actual content 510 they exchange with Web servers, including personal and sensitive 511 information. 513 The TLS connection from the user agent to the Explicitly 514 Authenticated proxy is always authenticated. In case the origin 515 server only offers unauthenticated TLS (e.g. by using a self-signed 516 certificate) the explicit Explicitly Authenticated proxy increases 517 the security in the access network (e.g. an unencrypted hotspot) by 518 ensuring that there is no unwanted MITMs in this part of the network. 520 To ensure the trustfulness of proxies, certification authorities 521 validation procedure for issuing proxy certificates should be more 522 rigorous than for issuing normal certificates and may also include 523 technical details and processes relevant for the security assurance. 524 The owner of the proxy could for example be obliged to apply security 525 patches in a timely fashion. 527 When negotiating ciphersuite with the server, the Explicitly 528 Authenticated proxy SHALL offer the ciphersuite negotiated between 529 the user-agent and the proxy. Ciphersuites with a higher security 530 level that the ciphersuite negotiated between the user-agent and 531 proxy MAY be given a higher preference than the ciphersuite 532 negotiated between the user-agent and proxy. Ciphersuites with a 533 lower security level that the ciphersuite negotiated between the 534 user-agent and proxy SHALL NOT be given a higher preference than the 535 ciphersuite negotiated between the user-agent and proxy. While 536 AES-256 is no weaker (an most probably much stronger) than AES-128, 537 the relative security between different algorithm e.g SHA-256 vs 538 Keccak-256 is not that clear. With security level we mean the 539 complexity of the best known attack on that ciphersuite. The 540 Explicitly Authenticated proxy SHOULD therefore be up to date with 541 the best current practices regarding TLS. 543 This document proposes an approach to making the presence of proxy 544 explicit to users and letting them decide whether they accept that. 545 A user can opt out and choose to bypass the proxy. This ensures that 546 a proxy never acts as intermediary for HTTP2 traffic unless 547 authorised by the user. 549 When the user has given consent to the presence of the proxy, the 550 user agent switches to a Proxy mode in which it does not check the 551 hostname of the origin server against the server's identity as 552 presented in the Server Certificate message. However if any of the 553 following checks fails the user agent should immediately exit this 554 Proxy mode: 556 1. the server's certificate is issued by a trusted CA and the 557 certificate is valid; 559 2. the Extended Key Usage extension is present in the certificate 560 and indicates the owner of this certificate is a proxy; 562 3. the server possesses the private key corresponding to the 563 certificate. 565 9. Acknowledgments 567 The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson, 568 Nicolas Mailhot, Martin Nilsson, Emile Stephan (Connection with prior 569 knowledge) and Salman Taj for their ideas, technical suggestions and 570 comments. 572 10. References 574 10.1. Normative References 576 [I-D.ietf-appsawg-http-forwarded] 577 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 578 draft-ietf-appsawg-http-forwarded-10 (work in progress), 579 October 2012. 581 [I-D.ietf-httpbis-http2] 582 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 583 Protocol version 2", draft-ietf-httpbis-http2-13 (work in 584 progress), June 2014. 586 [I-D.ietf-httpbis-p1-messaging] 587 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 588 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 589 httpbis-p1-messaging-26 (work in progress), February 2014. 591 [I-D.ietf-tls-applayerprotoneg] 592 Friedl, S., Popov, A., Langley, A., and S. Emile, 593 "Transport Layer Security (TLS) Application Layer Protocol 594 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 595 (work in progress), March 2014. 597 [I-D.nottingham-http-proxy-problem] 598 Nottingham, M., "Problems with Proxies in HTTP", draft- 599 nottingham-http-proxy-problem-00 (work in progress), 600 October 2013. 602 [I-D.rpeon-httpbis-exproxy] 603 Peon, R., "Explicit Proxies for HTTP/2.0", draft-rpeon- 604 httpbis-exproxy-00 (work in progress), June 2012. 606 [I-D.vidya-httpbis-explicit-proxy-ps] 607 Narayanan, V., "Explicit Proxying in HTTP - Problem 608 Statement And Goals", draft-vidya-httpbis-explicit-proxy- 609 ps-00 (work in progress), October 2013. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet 615 X.509 Public Key Infrastructure: Logotypes in X.509 616 Certificates", RFC 3709, February 2004. 618 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 619 Housley, R., and W. Polk, "Internet X.509 Public Key 620 Infrastructure Certificate and Certificate Revocation List 621 (CRL) Profile", RFC 5280, May 2008. 623 10.2. Informative References 625 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 626 6455, December 2011. 628 10.3. URIs 630 [1] https://github.com/http2/http2-spec/wiki/Proxy-User-Stories 632 [2] https://github.com/bizzbyster/TrustedProxy/wiki/Trusted-Proxy- 633 Use-Case-Analysis-and-Alternatives 635 [3] Jarmoc, J., SSL/TLS Interception Proxies and Transitive Trust, 636 2012 https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf 638 Appendix A. Proxy certificate 640 To help HTTP user agents identify and distinguish Explicitly 641 Authenticated proxies from other servers (e.g. web servers), 642 Explicitly Authenticated proxies should have a certification 643 authority issued public key certificate. 645 More specifically, the certification authority SHOULD use the 646 Extended Key Usage extension as specified in [RFC5280] to indicate a 647 key purpose "proxyAuthentication" (a new object identifier needs to 648 be assigned by IANA for this key purpose). The certification 649 authority also marks this Extended Key Usage extension as critical. 651 As the user needs to have high trust in the Proxy, it is desirable 652 that the validation procedure for issuing proxy certificates be more 653 rigorous than for issuing ordinary SSL certificates. 655 A proxy certificate MUST contain the SubjectAltName extension as 656 defined in [RFC5280]. A name identifying the legal entity that is 657 operating the proxy should be given in this extension. 659 To help end users understand the reason why the proxy is offered (in 660 other words, the benefits of having the proxy in the path), a new 661 X.509 certificate extension ProxyFunctions is introduced to list the 662 functions the proxy is performing. More specifically, the 663 ProxyFunction extension consists of a sequence of ProxyFunctionId 664 which are object identifiers. The user agent should check the 665 presence of this extension in the proxy certificate and present the 666 proxy functions in a human readable format. 668 The user agent will provide the user with an opportunity to 669 graphically view the results of a successful proxy certificate-based 670 identification process leveraging on the usage of logotypes in public 671 key certificates and attribute certificates as specified in 672 [RFC3709]. 674 Authors' Addresses 676 Salvatore Loreto (editor) 677 Ericsson 678 Hirsalantie 11 679 Jorvas 02420 680 Finland 682 Email: salvatore.loreto@ericsson.com 684 John Mattsson 685 Ericsson 686 Kista 687 Sweden 689 Email: john.mattsson@ericsson.com 691 Robert Skog 692 Ericsson 693 Kista 694 Sweden 696 Email: robert.skog@ericsson.com 697 Hans Spaak 698 Ericsson 699 Kista 700 Sweden 702 Email: hans.spaak@ericsson.com 704 Gus Bourg 705 AT&T 707 Email: gb3635@att.com 709 Dan Druta 710 AT&T 712 Email: dd5826@att.com 714 Mohammad Hafeez 715 AT&T 717 Email: mh2897@att.com