W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Multi-legged Authentication for HTTP Multiplexing

From: Jonathan Silvera <jsilvera@microsoft.com>
Date: Mon, 18 Jun 2012 02:41:02 +0000
To: "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>
Message-ID: <4A6008CA493DD743AF241A465C01F15F09457808@SN2PRD0310MB360.namprd03.prod.outlook.com>
While there is a call for authentication schemes proposals, we have also been thinking a lot about how to ensure HTTP 2.0 is compatible with currently deployed authentication schemes, while addressing some of the issues currently encountered when performing multi-legged authentication. The following proposal captures our thoughts on an authentication mechanism that we believe achieves this goal. We would greatly appreciate it, if you could provide us with some feedback.

Multi-legged Authentication for HTTP Multiplexing

1. Overview

     This document defines multi-legged authentication for HTTP multiplexing.

     Without reliable support for Kerberos and other multi-legged auth schemes, the
     reach of HTTP2.0 will be greatly diminished in corporations that rely on these
     authentication schemes to protect their intranet resources.

     HTTP 2.0 should be semantically compatible with HTTP 1.1, but it should not have
     the same "stateless" requirement as HTTP 1.1, as many things other than
     multi-legged authentication, require server side state. In order to preserve this
     requirement, we propose that additional state needed for HTTP 2.0, be stored at
     the session layer. The HTTP 1.1 concept on "connection based authentication" can
     be implemented in HTTP 2.0 by moving the state from TCP connection layer to
     the HTTP 2.0 session layer.

     The following table summarizes widely deployed authentication schemes,
     their authentication types and the authentication level they provide:

     Table 1:
     | Scheme    | Type of Authentication | Authentication Level |
     | Basic     |      Per Request       |       Request        |
     | Digest    |      Per Request       |       Request        |
     | NTLM      |      Multi-legged      |       Connection     |
     | Kerberos  |      Multi-legged      |Connection or Request |
     | Negotiate |      Multi-legged      |Connection or Request |

     RFC 2616 defines HTTP as a stateless protocol and dictates that RFC
     compliant authentication schemes MUST be stateless. Multi-legged
     authentication support for multiplexing, requires state to associate separate
     request/response pairs that are part of the same multi-legged authentication

2. Multi-legged Authentication:

     As implied by its name, multi-legged authentication requires multiple roundtrips
     to establish an authenticated communication channel between client and server. If
     the resource requested by a client requires authentication, the server initiates
     the authentication process as follows:

     Figure 1 - Multi-legged authentication example:
       Client                                 Server
         |                                      |
        | -------- (0) HTTP GET Request ---->  |
         |                                      |
        | <------- (1) HTTP 401 -------------  |
         |                                      |
         | -------- (2) HTTP Get Request ---->  |
         |              w Auth header           |
         |                                      |
         | <------- (3) HTTP 401 -------------  |
        |                                      |
        | -------- (4) HTTP Get Request ---->  |
         |              w Auth header           |
         |                                      |
        | <------- (5) HTTP 200 OK-----------  |
         |                                      |
         |                                      |
         v                                      v

      0.  Server sends HTTP 401 response because the resource requested requires
      1. Client re-issues the HTTP GET request for the resource, including authentication
      2. Server responds with an HTTP 401 and authentication headers requesting
         additional information.
      3. Client re-issues the HTTP GET Request for the resource, including authentication
         headers with the additional information required to complete authentication.
      4. If authentication succeeds, the server responds with an HTTP 200 OK message
         including the requested resource.

     Multi-legged authentication requires state to be communicated between multiple
     streams. Network flows 3 and 4 in Figure 1 , need to share state in order for
     authentication to succeed.  Some multi-legged authentication schemes (i.e. Kerberos
     and Negotiate) can authenticate a connection or individual requests only, which
     has historically caused a lot if issues with multi-legged authentication in HTTP 1.1.

3. Multi-legged Authentication for HTTP multiplexing proposal:

   3.1 Multi-legged authentication between multiplexing clients and servers:

       Figure 2 below provides a detailed breakdown of proposed network flows to implement
       multi-legged authentication for HTTP multiplexing:

       Figure 2 - Proposed multi-legged authentication:

      Client                           HTTP Server
         |                                      |
        | --------   HTTP GET Request ------>  |
         |                                      |
        | <------- (0) HTTP 401 -------------  |
         |                                      |
         | -------- (1) HTTP Get Request ---->  |
         |              w Auth header           |[Auth-ID header
         |                                | generated (1.5)]
         | <------- (2) HTTP 401 -------------  |
         |              w Auth-ID header        |
         |                                      |
         | -------- (3) HTTP Get Request ---->  |[Peristed-auth header
         |              w Auth header and       | generated (3.5)]
         |              Auth-ID header          |
         |                                      |
         | <------- (4) HTTP 200 OK-----------  |
         |              w optional              |
         |              PersistedAuth header    |
        |                                      |
         |                                      |
         v                                      v

       0. Server sends HTTP 401 response because the resource requested requires

       1. Client re-issues the HTTP GET request for the resource, including authentication

          Multi-legged authentication schemes could authenticate individual requests or
          the HTTP 2.0 session. Clients SHOULD NOT authenticate individual streams belonging
          to an authenticated HTTP 2.0 session. The following describes client behavior when
          attempting to authenticate streams, for which it does not know if the negotiation
          will result in request based or HTTP 2.0 session based authentication:

          If an HTTP 2.0 session has a stream in process of authenticating using a multi-
          legged authentication scheme, the client SHOULD queue all subsequent requests
          (regardless of whether they require authentication) on the session,until
          the multi-legged authentication completes.

          If a server receives multiple authenticated requests from the same client, it
          SHOULD NOT block responses. It is the client's responsibility to queue requests
          when a multi-legged stream authentication process has been initiated in the
          session. If the client does not queue the requests, then it might
          unnecessarily authenticate streams in a session that has already been

          If connection based multi-legged authentication succeeds on a previously
          authenticated session, the server SHOULD discard the previous authentication
          context and authenticate the session with the newly negotiated authentication

       2. Server responds with an HTTP 401 and authentication headers requesting
          additional information:

          A session's lifetime is not tied to the duration of a request/response pair.
          If the authentication scheme used to validate the client's identity is a multi-
          legged scheme, servers will generate a new "Auth-ID" (1.5 in Figure 2) header.
          The Auth-ID value is an opaque blob that SHOULD NOT be interpreted. It SHOULD
          be sent in its complete form to continue an authentication process. The server
          uses this to lookup the correct security context to process this authentication

          The HTTP 401 response from the server will contain the "Auth-ID" header to enable
          sharing of authentication context across streams, as required for multi-legged

       3. Client re-issues the HTTP GET request for the resource, including the required
          authentication headers and the "Auth-ID" header, to inform the server that the
          request is part of a previously initiated multi-legged authentication process.

       4. Authentication succeeds and the server returns the requested resource, along with
          level of multi-legged authentication scheme:

          Some multi-legged authentication schemes can result in per request or per
          connection (i.e. Kerberos or Negotiate) authentication. Servers will generate a
         Persistent-auth header (3.5 in Figure 2) to inform the client when an
          authentication negotiation, resulted in an authenticated session. When a
          session is authenticated, servers MUST generate a Persistent-auth header and
          send it along with the HTTP 200 OK response. The client will use the presence (or
          absence) of the Persistent-auth header to determine what action to take, with
          previously queued requests due to multi-legged authentication being in progress:

            i. If the session was authenticated, as indicated by the presence of the
               Persistent-auth header, the client does not need to authenticate new streams
               it will create to service the queued requests on the authenticated session.

               Clients should assume that successful authentication with schemes that only
               support connection based authentication (i.e. NTLM), will always result in an
                authenticated session, even if the Persisted-auth header is not present.

            ii. If the sesseion was not authenticated, as indicated by the absence of the
                Persistent-auth header, the client should remember the negotiated
                authentication scheme used for authentication.  The client SHOULD NOT block
                streams on the session when processing requests using the multi-legged
                authentication scheme that previously resulted in per request authentication.

          A server COULD generate and add Auth-ID header as soon as it knows that the
          requested authentication scheme is multi-legged. The client must add the
          Auth-ID header to all subsequent requests required to complete the authentication

          A server COULD generate a Persistent-auth request as soon as it knows that
          the requested authentication scheme will authenticate the session. The client
          CANNOT make any assumptions by the absence of the Persistent-auth header, until the
          authentication process is complete and it receives the final server response
          containing the requested resource.

         3.1.1 Auth-ID header and security context lifetime

               Servers create and store security context information when they create the
               Auth-ID header. An Auth-ID header CANNOT be reused across sessions.

               The Auth-ID mapping is destroyed when the authentication process completes.
               Completion of the authentication process can be a successful authentication
               or failure to authenticate. TBD: Should Auth-IDs be random numbers? The
               security vs look-up perf implications should be weighed.

               Servers should limit the number of incomplete security contexts per
               session, to protect against misbehaving clients that cause the server to
               create multiple authentication contexts but never complete the authentication
               process. Servers SHOULD define a maximum number of incomplete security
               contexts and ignore SYN streams from misbehaving clients.

               Per session security contexts are transient and servers SHOULD discard them
               when request processing completes. There SHOULD only be one complete security
               context open per session.

   3.2 Stateful authentication to proxies

       HTTP proxies must add a new Remote-http-version header to inform the client of the
       HTTP version of the remote host. HTTP 2.0 clients can make authentication decisions
       based on the HTTP version of the target server. Proxy and gateway applications should
       take the consideration outlined by RFC 2616 when forwarding messages between client
       and servers with different protocol version capabilities.

         3.2.1 HTTP 2.0 client authenticating to an HTTP 2.0 server via proxy

             Authentication from an HTTP 2.0 (or greater) client to an HTTP 2.0 (or
               greater) server will work without additional changes, other than those
               described in the Multi-legged Authentication for HTTP multiplexing proposal
               section of this document. Proxies MUST bind the client-to-proxy and
               proxy-to-server connections.

         3.2.2 HTTP2.0 client connecting to an HTTP1.1 server via proxy

               HTTP 2.0 (or greater) clients that establish an authenticated connection to an
               HTTP 1.1 server (via a proxy) SHOULD downgrade HTTP version to HTTP 1.1, to
               avoid serialization.

               HTTP 2.0 clients can multiplex streams within the authenticated HTTP 2.0
               client-proxy session, but the proxy will serialize requests through the
               authenticated HTTP 1.1 proxy-server connection.

               HTTP 2.0 clients COULD decide to downgrade all requests requiring
               authentication (via a proxy) to HTTP 1.1 servers or only downgrade
               authenticated sessions, as indicated by the presence of the Persisted-auth

         3.2.3 HTTP1.1 client connecting to an HTTP2.0 server via proxy

               No changes required to support this scenario as HTTP 1.1 clients will ignore
               HTTP 2.0 headers.

   3.3 Authentication and multi-host sessions
       The proposed authentication scheme will only work if there is a limit of one unique
       host per HTTP 2.0 session.

4. Security considerations:

   Implementers should be aware of the security considerations defined by the individual
   authentication schemes supported. The following are some general security considerations
   that are independent of the proposed authentication mechanism.

   The proposed authentication mechanism is only used to provide authentication of a user to
   a server.  It provides no facilities for protecting the HTTP headers or data including the
   Authorization and WWW-Authenticate headers that are used to implement this mechanism.

   Alternate mechanisms such as TLS can be used to provide confidentiality. Hashes of the TLS
   certificates can be used as channel bindings to secure the channel.  In this case clients
   would need to enforce that the channel binding information is valid.

   If an HTTP proxy is used between the client and server, it must take care to not share
   authenticated connections between different authenticated clients to the same server.  If
   this is not honored, then the server can easily lose track of security context

   A proxy that correctly honors client to server authentication integrity will supply the
   "Proxy-support:  Session-Based-Authentication" HTTP header to the client in HTTP responses
   from the proxy.

5. Conventions used in this document:

   NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to   be interpreted as described in
   [RFC 2119].

6. Acknowledgements

   Thanks to the following people for contributing to the review and creation of this

     Matthew Cox, Ivan Pashov, Osama Mazahir, Gabriel Montenegro, Paul Leach, Nathan Ide, Rob
     Trace and Jonathan Silvera.
Received on Monday, 18 June 2012 02:41:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC