[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         J. Silvera
Internet-Draft                                                    M. Cox
Expires: January 4, 2013                                       I. Pashov
                                                              O. Mazahir
                                                           G. Montenegro
                                                               Microsoft
                                                            July 3, 2012


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

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 January 4, 2013.

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 January 4, 2013                [Page 1]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 2]

Internet-Draft            HTTP Multilegged Auth                July 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's architecture requires that messages be stateless; that is,
   that they are able to be interpreted in isolation, without relying
   upon state from "lower" layers, such as association between requests
   using the same TCP connection.  To enable better support of
   multilegged authentication, we propose that the shared state for
   which some authentication schemes rely upon the TCP connection
   (thereby making messages stateful) be moved into 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 January 4, 2013                [Page 3]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 4]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 5]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 6]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 7]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 8]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013                [Page 9]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013               [Page 10]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013               [Page 11]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013               [Page 12]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013               [Page 13]

Internet-Draft            HTTP Multilegged Auth                July 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 January 4, 2013               [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/