- 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.>
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
process.
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
authentication.
1. Client re-issues the HTTP GET request for the resource, including authentication
headers.
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:
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 ----> |[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
authentication.
1. Client re-issues the HTTP GET request for the resource, including authentication
headers:
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
authenticated.
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
context.
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
request.
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
authentication.
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
process.
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
header.
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
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.
5. Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
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
document:
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