Skip to main content

Multilegged Authentication for HTTP Multiplexing
draft-montenegro-httpbis-multilegged-auth-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jonathan Silvera, Matthew Cox, Ivan Pashov, Osama Mazahir, Gabriel Montenegro
Last updated 2012-06-28
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-montenegro-httpbis-multilegged-auth-00
Network Working Group                                         J. Silvera
Internet-Draft                                                    M. Cox
Expires: December 31, 2012                                     I. Pashov
                                                              O. Mazahir
                                                           G. Montenegro
                                                               Microsoft
                                                           June 29, 2012

            Multilegged Authentication for HTTP Multiplexing
              draft-montenegro-httpbis-multilegged-auth-00

Abstract

   In line with the HTTP compatibility goal for HTTP 2.0, HTTP 2.0 must
   also be compatible with currently deployed authentication schemes.
   This draft addresses this goal in the presence of multiplexing
   (expected to be part of HTTP 2.0), while addressing some of the
   issues currently encountered when performing multilegged
   authentication.

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."

   This Internet-Draft will expire on December 31, 2012.

Copyright Notice

   Copyright (c) 2012 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

Silvera, et al.         Expires December 31, 2012               [Page 1]
Internet-Draft            HTTP Multilegged Auth                June 2012

   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.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Multilegged Authentication in HTTP 1.X . . . . . . . . . . . .  4
   3.  Multilegged Authentication in the Presence of HTTP 2.0
       Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Auth-ID Header and Security Context Lifetime . . . . . . .  8
   4.  Stateful Authentication to Proxies . . . . . . . . . . . . . . 10
     4.1.  HTTP 2.0 Client Authenticating to an HTTP 2.0 Server
           via Proxy  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  HTTP 2.0 Client Authenticating to an HTTP 1.1 Server
           via Proxy  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  HTTP 1.1 Client Connecting to an HTTP 2.0 Server via
           Proxy  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Authentication and multi-host sessions . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Silvera, et al.         Expires December 31, 2012               [Page 2]
Internet-Draft            HTTP Multilegged Auth                June 2012

1.  Overview

   This document defines multilegged authentication for HTTP
   multiplexing.

   Without reliable support for Kerberos and other multilegged 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 multilegged 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 of "connection-based authentication" can be
   implemented in HTTP 2.0 by moving the state from the 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      |      Multilegged      |       Connection     |
        | Kerberos  |      Multilegged      |Connection or Request |
        | Negotiate |      Multilegged      |Connection or Request |
        +-----------+------------------------+----------------------+

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

1.1.  Requirements Language

   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].

Silvera, et al.         Expires December 31, 2012               [Page 3]
Internet-Draft            HTTP Multilegged Auth                June 2012

2.  Multilegged Authentication in HTTP 1.X

   As implied by its name, multilegged 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: Multilegged 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

   1.  Server sends HTTP 401 response because the resource requested
       requires authentication.

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

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

   4.  Client re-issues the HTTP GET Request for the resource, including
       authentication headers with the additional information required
       to complete authentication.

   5.  If authentication succeeds, the server responds with an HTTP 200
       OK message including the requested resource.

   Multilegged authentication requires state to be communicated between
   multiple streams.  Network flows 3 and 4 in Figure 1 need to share

Silvera, et al.         Expires December 31, 2012               [Page 4]
Internet-Draft            HTTP Multilegged Auth                June 2012

   state in order for authentication to succeed.  Some multilegged
   authentication schemes (i.e.  Kerberos and Negotiate) can
   authenticate either a connection or individual requests, which has
   historically caused a lot if issues with multilegged authentication
   in HTTP 1.1.

Silvera, et al.         Expires December 31, 2012               [Page 5]
Internet-Draft            HTTP Multilegged Auth                June 2012

3.  Multilegged Authentication in the Presence of HTTP 2.0 Multiplexing

   Figure 2 below provides a detailed breakdown of proposed network
   flows to implement multilegged authentication for HTTP 2.0
   multiplexing:

        Figure 2 - Proposed multilegged authentication:

                                            Multiplexing
       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 ---->  |[Persisted-auth header
          |              w Auth header and       | generated (3.5)]
          |              Auth-ID header          |
          |                                      |
          | <------- (4) HTTP 200 OK-----------  |
          |              w optional              |
          |              PersistedAuth header    |
          |                                      |
          |                                      |
          v                                      v

   1.  Server sends HTTP 401 response because the resource requested
       requires authentication.

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

       Multilegged 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:

Silvera, et al.         Expires December 31, 2012               [Page 6]
Internet-Draft            HTTP Multilegged Auth                June 2012

       If an HTTP 2.0 session has a stream in process of authenticating
       using a multilegged authentication scheme, the client SHOULD
       queue all subsequent requests (regardless of whether they require
       authentication) on the session until the multilegged
       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 multilegged 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
       authenticated.

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

   3.  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 multilegged scheme, servers MUST 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 MUST be sent
       in its complete form to continue an authentication process.  The
       server uses this to look up the correct security context to
       process this authentication request.

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

   4.  Client re-issues the HTTP GET request for the resource and MUST
       include the required authentication headers and the "Auth-ID"
       header, to inform the server that the request is part of a
       previously initiated multilegged authentication process.

   5.  Authentication succeeds and the server returns the requested
       resource, along with level of multilegged authentication scheme:

       Some multilegged authentication schemes can result in per-request
       or per-connection (i.e., Kerberos or Negotiate) authentication.
       When a session is authenticated, servers MUST generate a
       Persistent-auth header 3.5 in Figure 2) and send it along with
       the HTTP 200 OK response.  The client MUST use the presence or

Silvera, et al.         Expires December 31, 2012               [Page 7]
Internet-Draft            HTTP Multilegged Auth                June 2012

       absence) of the Persistent-auth header to determine what action
       to take with previously queued requests due to multilegged
       authentication being in progress:

       1.  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 creates 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) always result in an authenticated session, even
           if the Persisted-auth header is not present.

       2.  If the session 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 multilegged
           authentication scheme that previously resulted in per-request
           authentication.

       A server MAY generate and add Auth-ID header as soon as it knows
       that the requested authentication scheme is multilegged.  The
       client MUST add the Auth-ID header to all subsequent requests
       required to complete the authentication process.

       A server MAY 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.  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.

Silvera, et al.         Expires December 31, 2012               [Page 8]
Internet-Draft            HTTP Multilegged Auth                June 2012

   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.

Silvera, et al.         Expires December 31, 2012               [Page 9]
Internet-Draft            HTTP Multilegged Auth                June 2012

4.  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.

4.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 Multilegged Authentication for HTTP
   multiplexing proposal section of this document.  Proxies MUST bind
   the client-to-proxy and proxy-to-server connections.

4.2.  HTTP 2.0 Client Authenticating to an HTTP 1.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 MUST 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 header.

4.3.  HTTP 1.1 Client Connecting to an HTTP 2.0 Server via Proxy

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

Silvera, et al.         Expires December 31, 2012              [Page 10]
Internet-Draft            HTTP Multilegged Auth                June 2012

5.  Authentication and multi-host sessions

   The proposed authentication mechanism works only if there is a limit
   of one unique host per HTTP 2.0 session.

Silvera, et al.         Expires December 31, 2012              [Page 11]
Internet-Draft            HTTP Multilegged Auth                June 2012

6.  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
   associations.

   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.

Silvera, et al.         Expires December 31, 2012              [Page 12]
Internet-Draft            HTTP Multilegged Auth                June 2012

7.  Acknowledgements

   Thanks to the following individuals who provided helpful feedback and
   contributed to discussions on this document: Paul Leach, Nathan Ide
   and Rob Trace.

Silvera, et al.         Expires December 31, 2012              [Page 13]
Internet-Draft            HTTP Multilegged Auth                June 2012

Authors' Addresses

   Jonathan Silvera
   Microsoft

   Email: JSilvera@microsoft.com

   Matthew Cox
   Microsoft

   Email: MaCox@microsoft.com

   Ivan Pashov
   Microsoft

   Email: IvanPash@microsoft.com

   Osama Mazahir
   Microsoft

   Email: OsamaM@microsoft.com

   Gabriel Montenegro
   Microsoft

   Email: Gabriel.Montenegro@microsoft.com

Silvera, et al.         Expires December 31, 2012              [Page 14]