Internet DRAFT - draft-loreto-httpbis-explicitly-auth-proxy

draft-loreto-httpbis-explicitly-auth-proxy







Network Working Group                                     S. Loreto, Ed.
Internet-Draft                                               J. Mattsson
Intended status: Standards Track                                 R. Skog
Expires: January 4, 2015                                        H. Spaak
                                                                Ericsson
                                                                G. Bourg
                                                                D. Druta
                                                               M. Hafeez
                                                                    AT&T
                                                            July 3, 2014


               Explicitly Authenticated Proxy in HTTP/2.0
             draft-loreto-httpbis-explicitly-auth-proxy-01

Abstract

   This document proposes the definition of an Explicitly Authenticated
   Proxy as intermediary of normally unprotected "http" URI scheme
   requests and responses of HTTP2 traffic.

   An Explicitly Authenticated Proxy is a message forwarding agent that
   is selected, with explicit user's consent, and configured by the user
   agent to receive exclusively "http" URI scheme requests and attempt
   to satisfy those requests on behalf of the user agent.  A client is
   connected to an Explicitly Authenticated Proxy through an
   authenticated TLS secured connection.

   This document describes a method for a user agent to automatically
   discover and authenticate, and for an user to provide consent for an
   Explicitly Authenticated Proxy.  This enables proxied communication
   to be encrypted and authenticated, explicitly acknowledged by the
   user agent and visible to the server end point.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Loreto, et al.           Expires January 4, 2015                [Page 1]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   This Internet-Draft will expire on January 4, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Goals and non Goals . . . . . . . . . . . . . . . . . . .   4
     1.2.  Explicitly Authenticated Proxy  . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Establishing proxy connection . . . . . . . . . . . . . . . .   5
     3.1.  TLS Handshake with Proxy certificate  . . . . . . . . . .   5
   4.  Connection to a mobile network  . . . . . . . . . . . . . . .   6
     4.1.  proxy discovery in a mobile network . . . . . . . . . . .   7
   5.  Explicit Proxy behaviour  . . . . . . . . . . . . . . . . . .   7
     5.1.  Explicitly Authenticated Forward Proxy towards HTTP2
           origin server . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Explicitly Authenticated Forward Proxy towards HTTP/1.1
           Origin Server . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Explicitly Authenticated Forward Proxy and https URIs . .  10
   6.  User Consent  . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Expected behaviour if the user opts out/revokes consent .  11
   7.  Signalling the presence of a Proxy in between . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
     10.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Appendix A.  Proxy certificate  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16







Loreto, et al.           Expires January 4, 2015                [Page 2]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


1.  Introduction

   HTTP/1.1 and earlier allowed for the use of proxies and gateways to
   satisfy requests through a chain of connections.  This has made
   possible a Web ecosystem of various kinds of proxies and gateways:
   cache servers, security gateways, web accelerators, content filters,
   and many others.  In some cases their presence is explicit
   (configured proxies), and in other they are completely transparent to
   the end user (interception proxies, and gateways such as reverse
   proxies).

   The success and the presence of the proxies and gateways is also a
   problem for the evolution of the HTTP as their behaviour on protocol
   extensions, and especially on alternative wire formats of the
   protocol, is not predictable.  This unpredictable behaviour can lead
   to difficulties to deploy new versions of the protocol before the
   intermediaries are themselves updated.  As an example, see the
   difficulties in deploying the WebSocket Protocol [RFC6455] in clear.
   It can also lead to potentially problematic trust models where
   proxies are accessing traffic content without the user being aware.
   Relying on establishing an HTTPS tunnel has then become the popular
   way to bypass the intermediate proxies as it provides reliable
   deployment model for web protocols.  The encrypted tunnel obfuscates
   the data from all intermediaries and provides integrity validation.

   HTTPS tunnels, while speeding up the deployment, make it difficult
   for a forward proxy and other gateways to be used to enable caching,
   enhance anonymity for a user agent, or enhance security by scanning
   content for virus and malware.  HTTPS tunnels also remove the
   possibility to enhance delivery performance based on the knowledge of
   the network status, and this become an important limitation
   especially with HTTP2 when multiple streams are multiplexed on top of
   the same TCP connection.

   Several drafts analysing the role and the requirements for proxy have
   been submitted:

   1.  [I-D.nottingham-http-proxy-problem] discusses the use and
       configuration of proxies in HTTP, pointing out problems in the
       currently deployed Web infrastructure along the way

   2.  [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with
       HTTP proxies for TLS protected traffic and motivates the need for
       explicit proxying capability in HTTP.  It also presents the goals
       that such a solution would need to satisfy and some example
       solution directions.





Loreto, et al.           Expires January 4, 2015                [Page 3]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   3.  [I-D.rpeon-httpbis-exproxy] describes a method for connecting to
       a proxy via a secure channel, allowing, disallowing, and
       detecting any transforms that the proxy may perform, and allowing
       the proxy to connect via secure channel to another site on the
       user's behalf.

   Use cases in form of stories for proxies are also listed in the wiki
   Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy
   Use Case Analysis and Alternatives [2].

   This draft explicitly narrows down the general discussion to the role
   of Proxy as intermediary of "http" scheme URIs of HTTP2 traffic.

1.1.  Goals and non Goals

   The primary goal is to define an intermediary to 'http' traffic, that
   is TLS connected to the browser, operates with the knowledge and
   explicit consent of the user.

   Non goal is to define an intermediary for 'https' URI.  However the
   intermediary's expected behaviour for this case is listed for
   completeness.

1.2.  Explicitly Authenticated Proxy

   An "Explicitly Authenticated", as defined in this document, is an
   HTTP Proxy (see section 2.3 [I-D.ietf-httpbis-p1-messaging]) that is
   certificate authenticated, user acknowledged and connected to over a
   TLS encrypted (and possibly integrity protected) connection.  An
   Explicitly Authenticated Proxy is configured by the user agent to
   exclusively receive "http" URI scheme requests and attempt to satisfy
   those requests on behalf of the user agent.

   The presence of a configured Explicitly Authenticated Proxy MUST NOT
   change the user agent behaviour for the "https" URI scheme requests.

   To distinguish between an HTTP2 connection meant to transport "https"
   URIs resources and an HTTP2 connection meant to transport "http" URIs
   resource, this document defines the ALPN
   [I-D.ietf-tls-applayerprotoneg] identifier "h2c" to signal that HTTP2
   transports "http" URI requests and resources over TLS.

   This document describes a method for an user agent to automatically
   discover and then for an user to accept or reject (i.e. to provide
   consent for) an Explicitly Authenticated Proxy to be securely
   involved when a request to an "http" URI resource is made.





Loreto, et al.           Expires January 4, 2015                [Page 4]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   Section 3 defines a solution based on sending a proxy certificate in
   the TLS handshake.

   Section 5 describes the role of the Explicitly Authenticated Proxy in
   helping the user to fetch "http" URIs resource when the user has
   provided consent to the Explicitly Authenticated Proxy to be
   involved.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document defines the following terms:

   Explicit proxy:   an intercepting proxy (see section 2.3
      [I-D.ietf-httpbis-p1-messaging]) that communicates its presence to
      the user agent and destination server..

   Explicitly Authenticated Proxy:  an HTTP Proxy that is certificate
      authenticated, user acknowledged and connected to over a TLS
      encrypted (and possibly integrity protected) connection.  An
      Explicitly Authenticated Proxy is configured by the user agent to
      exclusively receive "http" URI scheme requests and attempt to
      satisfy those requests on behalf of the user agent.  The presence
      of a configured Explicitly Authenticated Proxy MUST NOT change the
      user agent behaviour for the "https" URI scheme requests.

3.  Establishing proxy connection

   An Explicitly Authenticated Proxy indicates its presence, identity
   and willingness to serve the user agent by intercepting TLS
   ClientHello message containing "h2c" value (a new ALPN protocol type
   assigned for this purpose) in the ALPN
   [I-D.ietf-tls-applayerprotoneg] negotiation extension field.  It
   answers the TLS initiation with a TLS ServerHello message containing
   the Proxy certificate Appendix A .

3.1.  TLS Handshake with Proxy certificate

   When a (TLS and HTTP) user agent receives a Server Certificate
   message, it checks whether the certificate contains an Extended Key
   Usage extension and if so whether the "proxyAuthentication" key
   purpose id is included.  If it is included, the user agent concludes
   that the certificate belongs to a proxy.  The user agent then SHOULD
   ensure user consent.




Loreto, et al.           Expires January 4, 2015                [Page 5]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   If the user provides consent, the user agent continues the TLS
   handshake with the proxy.

+--------------+                +------------+              +-------------+
|  User agent  |                |   Proxy    |              |   Server    |
+--------------+                +------------+              +-------------+
        |                             |                            |
        |                             |                            |
        | (1) ClientHello             |                            |
        |---------------------------->|                            |
        | ALPN Protocol Name: h2c     |                            |
        |                             |                            |
        |                             |                            |
        | (2) ServerHello, ServerCert |                            |
        |<----------------------------|                            |
        |  (Proxy cert)               |                            |
        |                             |                            |
        |                             |                            |
(3) User consent                      |                            |
        |                             |                            |
        | (4) Rest of TLS handshake   |                            |
        |<--------------------------->|                            |
        |                             |                            |
        | (5) HTTP2 over TLS          | (5) HTTP2 over TLS         |
        |<--------------------------->|<-------------------------->|
        |                             |                            |
        |                             |                            |


              Figure 1: TLS Handshake with Proxy certificate

4.  Connection to a mobile network

   When a handset connects to a mobile network it is desirable to
   preserve the integrity of its exchange with the servers which host
   the services of this network entity.  These use cases are described
   in [I-D.nottingham-http-proxy-problem] and in the [Proxy-User-
   Stories].

   This section proposes a solution for such use cases.  The proposal is
   inspired on the connection management specified in the section 9.1 of
   [I-D.ietf-httpbis-http2].  The connection with this proxy is used for
   all the servers' names listed in the "subjectAltName" field
   (http://tools.ietf.org/html/rfc5280#page-35) of the certificate of
   this proxy.






Loreto, et al.           Expires January 4, 2015                [Page 6]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


4.1.  proxy discovery in a mobile network

   At the network attachment, as usual, the network entity provides the
   handset with an IP address and with other pieces of information like
   DNS resolvers IP addresses.  The network entity additionally provides
   the handset with the server name (e.g. pr.example.com) of the
   Explicitly Authenticated Proxy in charge of the domain names this
   network entity is authoritative on.  These pieces of information are
   provided to the handset through a secure channel which preserves the
   integrity of the information.

5.  Explicit Proxy behaviour

   This section describes the role of the Explicitly Authenticated Proxy
   in helping the user to fetch http URI resources when the user has
   provided consent to the Explicitly Authenticated Proxy to be
   involved.

5.1.  Explicitly Authenticated Forward Proxy towards HTTP2 origin server
































Loreto, et al.           Expires January 4, 2015                [Page 7]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


+--------------+              +--------------+              +--------------+
|  User agent  |              |    Proxy     |              |    Server    |
+--------------+              +--------------+              +--------------+
        |                            |                              |
    (TLS Proxy announcement)         |                              |
    (mechanism has taken place)      |                              |
        |                            |                              |
        |    (1) ClientHello         |                              |
        |--------------------------->|                              |
        |    (2)  ServerHello        |                              |
        |<---------------------------|                              |
        |    (3) ChangeCipherSpec    |                              |
        |--------------------------->|                              |
        |    (4) ChangeCipherSpec    |                              |
        |<---------------------------|                              |
        |                            |                              |
        |                            |                              |
        |/========= HTTP2 ==========\|                              |
        |                            |                              |
        |--(5)-stream(X)---GET------>|                              |
        |                            |    (6) TLS ClientHello       |
        |                            |----------------------------->|
        |                            |    (7) TLS ServerHello       |
        |                            |<-----------------------------|
        |                            |    (8) ChangeCipherSpec      |
        |                            |----------------------------->|
        |                            |    (9) ChangeCipherSpec      |
        |                            |<-----------------------------|
        |                            |                              |
        |                            |/========= HTTP2 ============\|
        |                            |--(10)--stream(Z)---GET------>|
        |                            |                              |
        |                            |                              |
        |                            |<-(11)--stream(Z)---200 OK----|
        |<-(12)--stream(X)---200 OK--|                              |
        |                            |                              |
        |\======== HTTP2 ===========/|\========== HTTP2 ===========/|
        |                            |                              |


                   Figure 2: Requesting an HTTP resource

   (0)  The TLS Proxy Announcement (Section 3) mechanism has already
      taken place, so the user agent is now configured in the proxy
      mode.

   (1)...(4)  For each "http" URI resource towards a not yet contacted
      Server Origin, the user agent negotiates a new TLS session, using



Loreto, et al.           Expires January 4, 2015                [Page 8]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


      the ALPN extension containing the "h2c" tag, to establish an HTTP2
      connection.

   (5)  The user agent will then use the streams in the HTTP2 connection
      to request any resources hosted on that Origin Server.

   (6)...(9)  In the case the Proxy receives a request for a resource
      towards a not yet contacted Server Origin, the Explicitly
      Authenticated Proxy negotiates a new TLS session, using the ALPN
      extension containing the "h2c" ALPN identifier, to establish an
      HTTP2 connection.

   (10)  Once the Proxy has established the HTTP2 connection toward the
      origin, it picks one stream to forward the request

   (11), (12)  The Proxy forwards the answer it receives from the Origin
      Server to the user agent.

5.2.  Explicitly Authenticated Forward Proxy towards HTTP/1.1 Origin
      Server

   In the case the proxy has a privies knowledge about the fact that the
   "http" URI resources requested by the user agent will be only
   available over HTTP/1.1 or the proxy does not have a previous
   knowledge about it, the proxy will then attempt to contact the
   resource based on its knowledge.

























Loreto, et al.           Expires January 4, 2015                [Page 9]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


+--------------+              +--------------+              +--------------+
|  User agent  |              |    Proxy     |              |    Server    |
+--------------+              +--------------+              +--------------+
        |                            |                              |
    (TLS Proxy announcement)         |                              |
    (mechanism has taken place)      |                              |
        |                            |                              |
        |    (1) TLS ClientHello     |                              |
        |--------------------------->|                              |
        |    (2)  ServerHello        |                              |
        |<---------------------------|                              |
        |    (3) ChangeCipherSpec    |                              |
        |--------------------------->|                              |
        |    (4) ChangeCipherSpec    |                              |
        |<---------------------------|                              |
        |                            |                              |
        |/--------------------------\|                              |
        |--(5)-stream(X)---GET------>|                              |
        |                            |                              |
        |          HTTP2             |--(6)------GET /1.1---------->|
        |                            |                              |
        |                            |<-(7)-------200 OK------------|
        |<-(8)--stream(X)---200 OK---|                              |
        |                            |                              |
        |\--------------------------/|                              |
        |                            |                              |



            Figure 3: Origin server with only HTTP/1.1 support

5.3.  Explicitly Authenticated Forward Proxy and https URIs

   A user agent MUST NOT use "h2c" as ALPN extension field in request
   for https resources.

   The Proxy that intercepts the TLS ClientHello analyses the ALPN
   extension field and if it does not contain the "h2c" value it does
   not do anything and lets the TLS handshake continue and the TLS
   session be established between the user agent and the Server (see
   Figure 4).










Loreto, et al.           Expires January 4, 2015               [Page 10]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


+--------------+              +------------+                 +-------------+
|  User agent  |              |   Proxy    |                 |   Server    |
+--------------+              +------------+                 +-------------+
        |                            |                               |
        |                            |                               |
        |  (1) TLS ClientHello                                       |
        |----------------------------------------------------------->|
        | (ALPN ProtocolName: h2)                                    |
        |                                    (2)  ServerHello        |
        |<-----------------------------------------------------------|
        |  (3) ChangeCipherSpec                                      |
        |----------------------------------------------------------->|
        |                                    (4) ChangeCipherSpec    |
        |<-----------------------------------------------------------|
        |                                                            |
        |---(5)-stream(X)---GET------------------------------------->|
        |                                                            |
        |<-------------------------(6)--stream(X)---200 OK-----------|


     Figure 4: Explicitly Authenticated Proxy and https URI resources

6.  User Consent

   This document proposes an approach to making the presence of proxy
   explicit, explaining the functions it provides to users and letting
   them decide whether they accept that.  A user can opt out and choose
   to bypass the proxy.  This ensures that a proxy never acts as
   intermediary for HTTP2 traffic unless authorised by the user.

   The user selection can be cached by the user agent.  A consent SHOULD
   however be limited to the specific network access (such as APN or
   SSID) and may be limited to a single connection to that access or
   limited in time.  How the consent information is stored is
   implementation specific, but as a network may have several proxies
   (for network resilience) it is RECOMMENDED that the consent is only
   tied to the Subject field of the proxy certificate so that the
   consent applies to all proxy certificates with the same name.

6.1.  Expected behaviour if the user opts out/revokes consent

   If the user does not give consent, or decides to opt out from the
   proxy for a specific connection, the user agent will negotiate HTTP2
   connection using "h2" value in the ALPN extension field.  The proxy
   will then treat the connection as an "https" connection and will
   forward the ClientHello message to the Server, establishing an end-
   to-end TLS connection between the user agent and the destination
   server.



Loreto, et al.           Expires January 4, 2015               [Page 11]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


+--------------+              +------------+                 +-------------+
|  User agent  |              |   Proxy    |                 |   Server    |
+--------------+              +------------+                 +-------------+
        |                                                           |
        |  (1) ClientHello                                          |
        |---------------------------------------------------------->|
        | (ALPN ProtocolName: h2)                                   |
        |                                                           |
        |  (2) ServerHello, ServerCert                              |
        |<----------------------------------------------------------|
        |  (3) Rest of TLS handshake                                |
        |<--------------------------------------------------------->|
        |                                                           |
        |  (4) HTTP2  over TLS                                      |
        |<--------------------------------------------------------->|
        |                                                           |


                             Figure 5: Opt Out

7.  Signalling the presence of a Proxy in between

   The presence of Explicitly Authenticated Proxy in between an user
   agent and the origin server must be signalled to the origin server
   using an already defined HTTP header.

   The Explicitly Authenticated proxy MUST add, or update when already
   present, the Forwarded HTTP header field
   [I-D.ietf-appsawg-http-forwarded] "for" parameter.

8.  Security Considerations

   This document addresses Explicitly Authenticated proxies that act as
   intermediary for HTTP2 traffic and therefore the security and privacy
   implications of having those proxies in the path need to be
   considered.  MITM [3], [I-D.nottingham-http-proxy-problem] and
   [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and
   privacy issues associated with the use of proxies.

   It should however be noticed that the presence of the Explicitly
   Authenticated proxy as discussed in this document does not in any way
   affect "https" URI resources.  Those resources are protected end-to-
   end between user agent and origin server as usual.  Only for "http"
   URI resources the achievable security level of hop-by-hop protection
   may be different than end-to-end protection, because it is now also
   dependent on the security features/capabilities of the proxy as to
   what cipher suites it supports, which root CA certificates it trusts,
   how it checks certificate revocation status, etc.  Users should also



Loreto, et al.           Expires January 4, 2015               [Page 12]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   be made aware that the proxy has visibility to the actual content
   they exchange with Web servers, including personal and sensitive
   information.

   The TLS connection from the user agent to the Explicitly
   Authenticated proxy is always authenticated.  In case the origin
   server only offers unauthenticated TLS (e.g. by using a self-signed
   certificate) the explicit Explicitly Authenticated proxy increases
   the security in the access network (e.g. an unencrypted hotspot) by
   ensuring that there is no unwanted MITMs in this part of the network.

   To ensure the trustfulness of proxies, certification authorities
   validation procedure for issuing proxy certificates should be more
   rigorous than for issuing normal certificates and may also include
   technical details and processes relevant for the security assurance.
   The owner of the proxy could for example be obliged to apply security
   patches in a timely fashion.

   When negotiating ciphersuite with the server, the Explicitly
   Authenticated proxy SHALL offer the ciphersuite negotiated between
   the user-agent and the proxy.  Ciphersuites with a higher security
   level that the ciphersuite negotiated between the user-agent and
   proxy MAY be given a higher preference than the ciphersuite
   negotiated between the user-agent and proxy.  Ciphersuites with a
   lower security level that the ciphersuite negotiated between the
   user-agent and proxy SHALL NOT be given a higher preference than the
   ciphersuite negotiated between the user-agent and proxy.  While
   AES-256 is no weaker (an most probably much stronger) than AES-128,
   the relative security between different algorithm e.g SHA-256 vs
   Keccak-256 is not that clear.  With security level we mean the
   complexity of the best known attack on that ciphersuite.  The
   Explicitly Authenticated proxy SHOULD therefore be up to date with
   the best current practices regarding TLS.

   This document proposes an approach to making the presence of proxy
   explicit to users and letting them decide whether they accept that.
   A user can opt out and choose to bypass the proxy.  This ensures that
   a proxy never acts as intermediary for HTTP2 traffic unless
   authorised by the user.

   When the user has given consent to the presence of the proxy, the
   user agent switches to a Proxy mode in which it does not check the
   hostname of the origin server against the server's identity as
   presented in the Server Certificate message.  However if any of the
   following checks fails the user agent should immediately exit this
   Proxy mode:





Loreto, et al.           Expires January 4, 2015               [Page 13]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   1.  the server's certificate is issued by a trusted CA and the
       certificate is valid;

   2.  the Extended Key Usage extension is present in the certificate
       and indicates the owner of this certificate is a proxy;

   3.  the server possesses the private key corresponding to the
       certificate.

9.  Acknowledgments

   The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson,
   Nicolas Mailhot, Martin Nilsson, Emile Stephan (Connection with prior
   knowledge) and Salman Taj for their ideas, technical suggestions and
   comments.

10.  References

10.1.  Normative References

   [I-D.ietf-appsawg-http-forwarded]
              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              draft-ietf-appsawg-http-forwarded-10 (work in progress),
              October 2012.

   [I-D.ietf-httpbis-http2]
              Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol version 2", draft-ietf-httpbis-http2-13 (work in
              progress), June 2014.

   [I-D.ietf-httpbis-p1-messaging]
              Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", draft-ietf-
              httpbis-p1-messaging-26 (work in progress), February 2014.

   [I-D.ietf-tls-applayerprotoneg]
              Friedl, S., Popov, A., Langley, A., and S. Emile,
              "Transport Layer Security (TLS) Application Layer Protocol
              Negotiation Extension", draft-ietf-tls-applayerprotoneg-05
              (work in progress), March 2014.

   [I-D.nottingham-http-proxy-problem]
              Nottingham, M., "Problems with Proxies in HTTP", draft-
              nottingham-http-proxy-problem-00 (work in progress),
              October 2013.






Loreto, et al.           Expires January 4, 2015               [Page 14]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   [I-D.rpeon-httpbis-exproxy]
              Peon, R., "Explicit Proxies for HTTP/2.0", draft-rpeon-
              httpbis-exproxy-00 (work in progress), June 2012.

   [I-D.vidya-httpbis-explicit-proxy-ps]
              Narayanan, V., "Explicit Proxying in HTTP - Problem
              Statement And Goals", draft-vidya-httpbis-explicit-proxy-
              ps-00 (work in progress), October 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3709]  Santesson, S., Housley, R., and T. Freeman, "Internet
              X.509 Public Key Infrastructure: Logotypes in X.509
              Certificates", RFC 3709, February 2004.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

10.2.  Informative References

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

10.3.  URIs

   [1] https://github.com/http2/http2-spec/wiki/Proxy-User-Stories

   [2] https://github.com/bizzbyster/TrustedProxy/wiki/Trusted-Proxy-
       Use-Case-Analysis-and-Alternatives

   [3] Jarmoc, J., SSL/TLS Interception Proxies and Transitive Trust,
       2012 https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf

Appendix A.  Proxy certificate

   To help HTTP user agents identify and distinguish Explicitly
   Authenticated proxies from other servers (e.g. web servers),
   Explicitly Authenticated proxies should have a certification
   authority issued public key certificate.

   More specifically, the certification authority SHOULD use the
   Extended Key Usage extension as specified in [RFC5280] to indicate a
   key purpose "proxyAuthentication" (a new object identifier needs to
   be assigned by IANA for this key purpose).  The certification
   authority also marks this Extended Key Usage extension as critical.



Loreto, et al.           Expires January 4, 2015               [Page 15]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   As the user needs to have high trust in the Proxy, it is desirable
   that the validation procedure for issuing proxy certificates be more
   rigorous than for issuing ordinary SSL certificates.

   A proxy certificate MUST contain the SubjectAltName extension as
   defined in [RFC5280].  A name identifying the legal entity that is
   operating the proxy should be given in this extension.

   To help end users understand the reason why the proxy is offered (in
   other words, the benefits of having the proxy in the path), a new
   X.509 certificate extension ProxyFunctions is introduced to list the
   functions the proxy is performing.  More specifically, the
   ProxyFunction extension consists of a sequence of ProxyFunctionId
   which are object identifiers.  The user agent should check the
   presence of this extension in the proxy certificate and present the
   proxy functions in a human readable format.

   The user agent will provide the user with an opportunity to
   graphically view the results of a successful proxy certificate-based
   identification process leveraging on the usage of logotypes in public
   key certificates and attribute certificates as specified in
   [RFC3709].

Authors' Addresses

   Salvatore Loreto (editor)
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com


   John Mattsson
   Ericsson
   Kista
   Sweden

   Email: john.mattsson@ericsson.com


   Robert Skog
   Ericsson
   Kista
   Sweden

   Email: robert.skog@ericsson.com



Loreto, et al.           Expires January 4, 2015               [Page 16]

Internet-Draft       Explicitly Authenticated Proxy            July 2014


   Hans Spaak
   Ericsson
   Kista
   Sweden

   Email: hans.spaak@ericsson.com


   Gus Bourg
   AT&T

   Email: gb3635@att.com


   Dan Druta
   AT&T

   Email: dd5826@att.com


   Mohammad Hafeez
   AT&T

   Email: mh2897@att.com



























Loreto, et al.           Expires January 4, 2015               [Page 17]