INTERNET-DRAFT Magnus Nystrom
October, 2003 RSA Security
Expires: April, 2004 Alexey Melnikov
Intended category: Standards track Isode Ltd.
SASL in HTTP/1.1
draft-nystrom-http-sasl-08.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo suggest the use of SASL [RFC2222] as a framework to enable
the use of strong authentication mechanisms in HTTP/1.1 [RFC2616],
and describes one approach to accomplish this.
Please send comments on this document directly to authors or to the
relevant mailing lists, e.g. ietf-sasl@imc.org.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 1]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Table of contents
1 Introduction .............................................. 3
2 Document conventions and examples ......................... 4
2.1 Conventions used in this memo ............................ 4
3 Relationship with the HTTP/1.1 specification .............. 4
4 SASL framework ............................................ 4
4.1 The HTTP/1.1 challenge-response framework ................ 4
4.2 SASL authentication scheme ............................... 5
4.2.1 Recognition of the scheme .............................. 5
4.2.2 SASL authentication response header .................... 5
4.2.3 SASL authorization request header ...................... 7
4.3 Usage model .............................................. 8
4.3.1 SASL handshake initiation .............................. 8
4.3.2 Client response ........................................ 9
4.3.3 Server behavior upon receiving a "SASL" <auth-scheme>
token ................................................. 10
4.3.4 Client behavior upon receiving a "SASL" <auth-scheme>
token ................................................. 11
4.3.5 Subsequent requests ................................... 12
4.3.6 Example sequence diagrams ............................. 12
4.3.7 Pipelining considerations ............................. 13
4.3.8 Caching considerations................................. 14
4.3.9 "Web farm" considerations ............................. 14
4.3.10 Other considerations ................................. 14
4.4 Request/response encoding ............................... 15
4.4.1 SASL challenge/response encoding ...................... 15
4.4.2 Security layer......................................... 15
4.4.3 Interaction with TLS....................................16
4.5 Status codes and error handling ......................... 16
4.5.1 Client errors ......................................... 16
4.5.2 Server errors ......................................... 17
4.6 Authorization identity .................................. 17
4.7 Examples ................................................ 18
4.7.1 Example 1 - Server requires authentication ............ 18
4.7.2 Example 2 - Initial response .......................... 19
4.7.3 Example 3 - One mechanism only ........................ 20
4.7.4 Example 4 - Server sends additional data .............. 20
4.7.5 Example 5 - Abort ..................................... 22
4.7.6 Example 6 - Client requires authentication ............ 23
4.7.7 Example 7 - Client uses POST request .................. 24
4.8 Interoperability with existing HTTP/1.1 clients and
servers ................................................. 25
4.9 Preferences ............................................. 26
5 IANA considerations ...................................... 26
5.1 GSSAPI/SASL service name ................................ 26
5.2 HTTP/1.1 Status codes ................................... 26
6 Security considerations .................................. 27
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 2]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
6.1 Introduction ............................................ 27
6.2 Active attacks .......................................... 27
6.2.1 Man-in-the-middle ..................................... 27
6.2.2 Denial of service ..................................... 27
6.2.3 Replay ................................................ 28
6.3 Passive attacks ......................................... 28
6.4 Protecting body of POST/PUT requests .................... XX
6.5 Other considerations .................................... 28
7 Implementation considerations ............................ XX
7.1 SASL context ............................................ XX
7.2 SASL security layer ..................................... XX
8 Acknowledgements ......................................... 28
9 Copyright ................................................ 28
10 References .............................................. 29
10.1 Normative references ................................... 29
10.2 Informative references ................................. 30
11 Authors' addresses ...................................... 30
1 Introduction
The Hypertext Transfer Protocol, HTTP/1.1 [RFC2616], supports only
two authentication schemes, namely the "Basic Access Authentication
Scheme" and the "Digest Access Authentication Scheme" [RFC2617].
Neither of these can be considered to be strong authentication
schemes. The former is extremely insecure unless used in conjunction
with a lower-level protocol offering security services, since it
sends cleartext passwords. The latter is an improvement, but is still
vulnerable to man-in-the-middle attacks.
The Simple Authentication and Security Layer Protocol (SASL
[RFC2222]) provides a method for adding authentication and security
services to connection-oriented protocols in a flexible manner,
enabling a variety of authentication and security mechanisms (e.g.
those based on one-time-passwords, public key technology or password-
based public-key cryptography) to be used with any protocol
supporting SASL. One major benefit of using SASL with HTTP is that
since the security technology is not built in to HTTP it is possible
to easily remove support for mechanisms based on technology that has
been proven to be vulnerable, and to easily add mechanisms that
support the latest and greatest security technology.
This memo suggests a method to use SASL in HTTP/1.1 and solicit
comments on the suggested approach.
<<Editorial comments are in angle brackets, like this. See also
appendix B for the list of major Open Issues>>.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 3]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
2 Document conventions and examples
2.1 Conventions used in this memo
In examples, "C:" and "S:" indicate lines sent by a client and a
server respectively; "CP:" and "SP:" indicate lines sent by a client
and a server respectively with a SASL security layer active.
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
this document are to be interpreted as defined in "Key words for use
in RFCs to Indicate Requirement Levels" [RFC2119].
[RFC222] defines several terms used through out this document, in
particular "authorization identity" and "security layer". Section
4.2.2 defines the term "SASL context".
3 Relationship with the HTTP/1.1 specification
This memo relies on the HTTP/1.1 [RFC2616] specification. As with RFC
2616, it uses the ABNF [RFC2234] grammar of that document and relies
on both non-terminals and other aspects of it.
Further, this memo REQUIRES persistent connections whenever a SASL
security layer (see Section 4.4.2) is negotiated. It is also
RECOMMENDED to use persistent connection while performing a SASL
authentication exchange. See also Section 4.3.10 for additional
discussions of this issue.
4 SASL framework
4.1 The HTTP/1.1 challenge-response framework
HTTP/1.1 provides a simple challenge-response mechanism that can be
used by a server or proxy to challenge a client request and by a
client to provide authentication information. The reader is referred
to [RFC2616] and [RFC2617] for a more detailed description of this
mechanism. The relevant ABNF productions are:
challenge = auth-scheme 1*SP 1#auth-param
auth-scheme = token
auth-param = token "=" (token | quoted-string)
The challenge will be found in a WWW-Authenticate or a Proxy-
Authenticate header field.
The client response, containing the client's credentials is defined
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 4]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
as follows:
credentials = auth-scheme 1*SP 1#auth-param
The response will be found in an Authorization or a Proxy-
Authorization header field.
4.2 SASL authentication scheme
4.2.1 Recognition of the scheme
A server MUST use the auth-scheme token "SASL" if it supports SASL
and is willing to perform authentication using a SASL-based
mechanism.
4.2.2 SASL authentication response header
For the "SASL" <auth-scheme>, the authentication response header is
as follows:
challenge = SASL 1*SP sasl-response-parameters
sasl-response-parameters
= [sasl-mechanisms WSAC] [realm WSAC] sasl-sid
[WSAC sasl-challenge]
sasl-mechanisms = "mechanisms" "=" <"> 1#sasl-mech-name <">
realm = "realm" "=" quoted-string
; See RFC 2617
sasl-sid = "id" "=" quoted-string
sasl-challenge = "challenge" "=" base64-string
sasl-mech-name = 1*20 SASLCHAR
; Name must be from IANA set of registered SASL mechanisms,
; e.g. "SECURID"
base64-string = *base64-group [base64-fingroup]
; Encoding must be in accordance with section 3 of [BASE64] ,
; except not limited to 76 chars/line
base64-group = 4*BASE64
base64-fingroup = 4*BASE64 | (3*BASE64 "=") | (2*BASE64 "==")
SASLCHAR = UPALPHA | DIGIT | "-" | "_"
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 5]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
; Characters allowed in SASL mechanism name
BASE64 = DIGIT | ALPHA | "+" | "/"
WSAC = *LWS "," *LWS
Note: All directives ("mechanism", "id", "realm", "challenge", etc.)
are case-insensitive. All directive values are case-sensitive.
The meanings of the values of the directives used above are as
follows:
sasl-mechanisms
A list of registered SASL mechanisms acceptable to the
server. MUST be sent by the server unless a mechanism already has
been agreed upon (see example 2 in Section 4.7.2). Servers MUST
list supported SASL mechanisms in their preferred order.
realm
As defined in [RFC2617]. The directive MUST be present in initial
challenges and when the realm otherwise would not be known by the
client.
sasl-sid
A session identifier identifying a particular SASL context (see
below). MUST always be present. Sasl-sids are chosen by the server
and at any given point in time MUST be unique for each established
connection.
sasl-challenge
A Base64-encoded challenge (or server credentials, at the end
of an authentication exchange) in accordance with a selected SASL
mechanism. MUST NOT be sent unless there is exactly one SASL
mechanism in the <sasl-mechanisms> directive.
SASL context
This memo assumes the existence of a SASL handshake context during
the lifetime of a SASL handshake. SASL context is a SASL structure
that represents all SASL state associated with the SASL mechanism
that is being used in the authentication exchange identified by
sasl-sid. It may include (but not limited to) current step in
authentication exchange, an authentication id, any material derived
from password, private key, etc. See Section 7.1 for implementation
considerations.
4.2.3 SASL authorization request header
For the SASL scheme, the authorization request header is as
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 6]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
follows:
credentials = SASL [1*SP sasl-request-parameters]
sasl-request-parameters
= [sasl-mechanism WSAC] [sasl-sid WSAC]
[realm WSAC] [sasl-credentials]
sasl-mechanism = "mechanism" "=" <"> sasl-mech-name <">
sasl-credentials = "credentials" "="
(base64-string | cancel-token)
cancel-token = "*"
The meanings of the values of the directives used above are as
follows:
sasl-mechanism
A SASL mechanism acceptable to the client, chosen from the list
provided by the server or set by some configuration. MUST be sent
by the client unless a mechanism already has been agreed upon.
sasl-sid
A session identifier identifying a particular SASL context,
previously set by a server. MUST always be sent by the
client except for the case of "initial responses," see Section
4.3.1 below.
realm
As defined in [RFC2617]. MUST always be sent by the client unless
the realm is possible to determine by other means (e.g. server
provided only one realm in its "SASL" <auth-scheme> token).
sasl-credentials
Base64-encoded credentials in accordance with a selected SASL
mechanism. MUST be sent if a <sasl-challenge> directive has been
received by the client.
4.3 Usage model
4.3.1 SASL handshake initiation
4.3.1.1 Server initiated authentication
When a client makes a request for a resource on a server that
requires SASL-based authentication, the server MUST respond with a
401 - Unauthorized (407 - Proxy Authentication Required) response
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 7]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
including a WWW-Authenticate (or Proxy-Authenticate) header field
that contains a "SASL" <auth-scheme>.
The server MUST list all supported and acceptable SASL mechanisms
in the <sasl-mechanisms> directive. If the server only supports one
SASL mechanism, it MAY include a <sasl-challenge> directive in
order to reduce the number of roundtrips (see the example in
Section 4.7.3). The server MUST include a <sasl-sid> directive to
identify the secure session being negotiated. This value MUST be
the same for all messages associated with that session.
When two or more authentication exchanges are performed in parallel
on the same connection ("mixed"), the client MUST NOT negotiate a
security layer on more than one of them. Multiple <sasl-sid>
directives SHOULD NOT be "mixed" on the same connection, except for
the case when a client starts an authentication exchange with the
target server and an intervening proxy server asks the client to
authenticate to it first. In this case, the client must perform an
authentication exchange to the proxy first and then resume
authentication to the end server.
Further, the server MUST include a <realm> directive in accordance
with [RFC2617], however if a particular SASL mechanism defines its
own "realm" as a part of its authentication exchange, the mechanism
specific version of "realm" MUST be used by the mechanism.
4.3.1.2 Client initiated authentication
A client, which is about to issue a request to a server, and knows
that the server requires a certain SASL mechanism, MAY include a a
"SASL" <auth-scheme> token in an Authorization (or Proxy-
Authorization) header field in its request. If the client chooses
to do so, it MUST include a <sasl-mechanism> directive identifying
the used SASL mechanism, but MUST NOT include a <sasl-sid>
directive, as session identifiers are chosen by the server. If the
chosen SASL mechanism requires that the client sends data first,
the client MUST also include a <sasl-credentials> directive, c.f.
the "initial response" in [RFC2222] (see the example in Section
4.7.2). This minimizes the number of roundtrips, since otherwise
the server would be required to send an empty challenge.
If the client requires authentication, but doesn't know which
mechanisms are supported by the server, the client SHOULD issue an
OPTION request that includes a Request-URI header for the desired
resource and an Authorization (or Proxy-Authorization) header field
containing a "SASL" <auth-scheme> token that MAY contain <realm>,
but MUST NOT contain any of the <sasl-mechanism>, <sasl-sid> or
<sasl-credentials>. This provides a way for the client to query
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 8]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
the server about supported SASL mechanisms for the requested
resource.
This document REQUIRES that a compliant SASL-aware server handles
an OPTIONS request with the "SASL" <auth-scheme> token described in
the previous paragraph by listing all supported and acceptable SASL
mechanisms in the <sasl-mechanisms> directive as described in
Section 4.3.1.1.
<<Should we say that the server selects the appropriate realm (or
realms?) and returns data for them. Also, if the client specified a
realm and the request URL is not governed by the realm, should the
server return an error?>>
4.3.2 Client response
A client, which receives a "SASL" <auth-scheme> authentication
response containing the <sasl-mechanisms> directive in a WWW-
Authenticate (Proxy-Authenticate) header in a 401 - Unauthorized
(407 - Proxy Authentication Required) response, MUST choose one of
the available mechanisms and construct a new request as described
below. This request MAY contain the headers from the original
request, MUST contain an Authorization (Proxy-Authorization) header
containing a "SASL" <auth-scheme> token and SHOULD NOT contain the
body of the original request (if any). We will reference any such
request as a "SASL request". The purpose of SASL requests is to
avoid sending the body of a request with each authentication step.
The "SASL" <auth-scheme> token in the SASL request MUST include the
<sasl-sid> value provided by the server and a <sasl-mechanism>
directive with the chosen SASL mechanism name. If the chosen
mechanism allows for "initial response" type messages, the client
MUST also include the initial response in a <sasl-credentials>
directive.
If the client is able and willing to negotiate a SASL security
layer, it MUST establish an end-to-end tunnel using the CONNECT
method as described in Section 5.3 of [RFC2817] before starting an
authentication exchange. The Authorization header MUST NOT be used
in a CONNECT request. However, in order to save round trips, a
Proxy-Authorization header MAY be used in a CONNECT request.
Note: A direct connection (any intermediate proxies operating in
tunnel mode) is required whenever a security layer is in effect,
since at that point complete HTTP/1.1 messages may be encrypted.
If the client receives a "SASL" <auth-scheme> authentication
response containing a <sasl-challenge> directive in a WWW-
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 9]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Authenticate (Proxy-Authenticate) header for a 401 - Unauthorized
(407 - Proxy Authentication Required) response, the client should
behave as described in Section 4.3.4.
4.3.3 Server behavior upon receiving a "SASL" <auth-scheme> token
The server (proxy), upon receiving an authorization request
containing a "SASL" <auth-scheme> token with a <sasl-sid>
directive, checks if the SASL context identified by <sasl-sid> is
still valid. If it is not, the server SHALL reply with a 401 -
Unauthorized (407 - Proxy Authentication Required) response, that
contains a new <sasl-sid> value and the session continues as
described in Section 4.3.1.1, i.e. the server MUST list all
supported and acceptable SASL mechanisms in the <sasl-mechanisms>
directive.
The server (proxy), upon receiving an authorization request
containing a "SASL" <auth-scheme> token with a <sasl-mechanism>
directive, checks if it supports/accept the authentication
mechanism. If the provided mechanism is not supported or accepted,
the server MUST reply with a 450 - "Authentication mechanism not
accepted" response and, if the request included <sasl-sid>
directive, delete the SASL session identified by the <sasl-sid>.
The server (proxy), upon receiving an authorization request
containing a "SASL" <auth-scheme> token with a <sasl-credentials>
directive, checks if the client is authenticated. If the client is
not authenticated, the server responds with a 401 - Unauthorized
(407 - Proxy Authentication Required) response containing a new
<sasl-challenge> directive with a "SASL" <auth-scheme>
authentication response token in a WWW-Authenticate (or Proxy-
Authenticate) header. The server MAY also choose to reply with 401
- Unauthorized response that contains WWW-Authenticate (or Proxy-
Authenticate) header without the <sasl-challenge> directive, in
which case the client shall interpret the response in accordance
with Section 10.4.2 of [RFC2616]. The server MAY also choose to
reply with 432 - Transition Needed response, that indicates that
the user name is valid, but the entry in the authentication
database needs to be updated in order to permit authentication with
the specified SASL mechanism.
If the client is authenticated, the server MUST at least include
the <sasl-sid> directive with its "SASL" <auth-scheme>
authentication response token. If the chosen SASL mechanism
requires that further challenge/response data (i.e. "server returns
success with additional data" in [RFC2222]) be sent by the server,
the server MUST respond with a 401 - Unauthorized (407 - Proxy
Authentication Required) response containing also a <sasl-
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 10]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
challenge> directive with its "SASL" <auth-scheme> authentication
response token in a WWW-Authenticate (or Proxy-Authenticate)
header. Unless the server fails authentication, the client MUST
reply to this with a new SASL request containing an Authorization
header with a <sasl-sid> directive and an empty <sasl-credentials>
directive. The server will reply to this with a 235 -
Authentication Completed (236 - Proxy Authentication Completed)
response and at this point authentication is complete, and a SASL
security layer may take effect (see Section 4.4.2).
If the client is authenticated and the server does not need to send
any further challenge information, the server replies with 235 -
Authentication Completed (236 - Proxy Authentication Completed)
response.
Upon receipt of a 235/236 response the client shall consider
authentication successful and may retry the original request (with
the body of the request, if any) that would be protected by the
negotiated security session (see Section 4.4.2).
4.3.4 Client behavior upon receiving a "SASL" <auth-scheme> token
The client, upon receipt of a 432 - Transition Needed response, MAY
retry authentication using the SASL PLAIN mechanism. This SHOULD be
done with appropriate TLS protection in place. An interactive
client MUST not perform PLAIN authentication automatically and MUST
warn the user before proceeding.
The client, upon receipt of a "SASL" <auth-scheme> authentication
response containing a <sasl-challenge> directive in a WWW-
Authenticate (Proxy-Authenticate) header for a 401 - Unauthorized
(407 - Proxy Authentication Required) response, calculates its
credentials and responds with a new SASL request containing a
(possibly empty, see previous section) <sasl-credentials> directive
and a "SASL" <auth-scheme> token in an Authorization (Proxy-
Authorization) header. The client repeats this until the
authentication exchange is successful or the server responds with a
401 (407) message without the <sasl-challenge> directive (see
previous section).
4.3.5 Subsequent requests
The same HTTP server may serve data governed by multiple realms
that may have separate associated authentication databases. If the
client left the authentication realm it was originally
authenticated in, the server MAY force the client to re-
authenticate in the new realm. In this case a new authentication
exchange is started as described in 4.3.1. However there is a
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 11]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
change in how the security layer is established (see Section
4.4.2). If a security layer is currently active and the new
authentication exchange negotiate a new security layer, it MUST
replace the existing one. However, if no security layer is
negotiated, the existing one MUST be dropped (i.e. the connection
reverts to a state where no SASL security layer is present). See
Section 4.4.2 for description when the security layer is being
replaced/dropped.
4.3.6 Example sequence diagrams
Server initiated authentication:
Client Server
----------------- Initial Request ----------------------->
<------ 401 WWW-Authenticate SASL (mechanisms,realm,id) --
--- Authorization (mechanism,id[,realm]) ---------------->
<------ 401 WWW-Authenticate SASL (id,challenge) ---------
--- Authorization (id,credential)------------------------>
<------ 401 WWW-Authenticate SASL (id,challenge) ---------
--- Authorization (id,credential)------------------------>
(0 or more times depending on the SASL mechanism)
<------ 235 WWW-Authenticate SASL (id) -------------------
----------------- Initial Request (retry) --------------->
<------ 200 Server performs the requested operation ------
Client initiated authentication:
Client Server
--- OPTIONS request with Authorization ([realm]) -------->
<------ 401 WWW-Authenticate SASL (mechanisms,realm,id) --
--- Authorization (mechanism,id) ------------------------>
<------ 401 WWW-Authenticate SASL (id,challenge) ---------
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 12]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
--- Authorization (id,credential)------------------------>
<------ 401 WWW-Authenticate SASL (id,challenge) ---------
--- Authorization (id,credential)------------------------>
(0 or more times depending on the SASL mechanism)
<------ 235 WWW-Authenticate SASL (id) -------------------
----------------- Initial Request ----------------------->
<------ 200 Server performs the requested operation ------
All subsequent requests are carried out as usual.
4.3.7 Pipelining considerations
When pipelining multiple authentication requests (or authentication
requests together with other requests), the client MUST observer
the rules established in Section 4.4.2. This means that an
authentication request that completes a SASL authentication
exchange and turns on SASL security layer, MUST be the last request
in the group. If this rule is not followed, the client will start
sending cleartext data that may be interpreted by the server as
encrypted. This can lead to a packet decode error on the server
side and connection would be dropped.
Clients MAY put multiple HTTP requests inside a single SASL block
when a SASL security layer has been negotiated (see also Section
4.4.2).
4.3.8 Caching considerations
In order to prevent caching of a HTTP response containing a piece
of a multistep SASL exchange, the client MUST send both "Cache-
Control: no-store" and "Pragma: no-cache" (for compatibility with
older proxy servers) together with an "Authorization" header in all
intermediate request. There are two exception to this rule:
1). the client is sending a OPTIONS/POST/PUT/DELETE request, that
have non cacheable responses.
2). the client established an end-to-end tunnel with CONNECT.
<<From HTTP 1.1 document:
Note that Section 14.8 normally prevents a shared cache from
saving and returning a response to a previous request if that
request included an Authorization header.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 13]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
So, everything discussed in this section might not be
required.>>
For the same reason, the server MUST send a "Cache-Control: no-
store" header together with the "WWW-Authenticate" header in all
intermediate responses.
4.3.9 "Web farm" considerations
Implementation and configuration of the SASL negotiation mechanism
described in this memo requires special considerations in the case
of "web farm" environments where several servers may serve user
requests since authentication state information otherwise may be
lost. In particular, means for sharing of authentication
negotiation state must be available.
4.3.10 Other considerations
Clients MAY abort authentication exchanges at any time, by
specifying "*" in <sasl-credentials> and including <sasl-sid> of
the authentication exchange being cancelled. If the server receives
such a request, it MUST reject the exchange with a 401 -
Unauthorized reply. After this, both the client and the server MUST
return to their previous state.
There MUST NOT be more than one WWW-Authenticate or Proxy-
Authenticate header field containing a SASL authentication response
in a response.
There MUST NOT be more than one Authorization or Proxy-
Authorization header field containing a SASL authorization request
in a request.
Servers not supporting persistent connections MUST implement a
method for management of existing SASL sessions. This may include
(but not limited to) session caching, session expiration, dealing
with duplicated authentication requests and keeping track of
authenticated clients using some state management technique. When a
client makes a request using a session identifier for an expired
session, the server MUST reply with a 401 - Unauthorized (407 -
Proxy Authentication Required) response possibly containing a
"SASL" <auth-scheme> with a new <sasl-sid> value, starting a new
authentication exchange.
<<This document doesn't specify how a server can track an
authenticated client after successful authentication when the
client doesn't use persistent connection>>
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 14]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
4.4 Request/response encoding
4.4.1 SASL challenge/response Encoding
The <sasl-challenge> directive and the <sasl-credentials> directive
contain SASL challenges and responses respectively. The challenges
and responses MUST be base64 ([BASE64], section 3) encoded before
being placed in these fields. The base64 string may in general be
arbitrarily long. Clients and servers MUST be able to support
challenges and responses that are as long as are generated by the
authentication mechanisms they support, independent of any line
length limitations the client or server may have in other parts of
its protocol implementation.
4.4.2 Security layer
If a protection mechanism is negotiated as part of the SASL
security session, then it MUST be applied to all subsequent
requests and responses sent between the server and the client. Any
negotiated security layer takes effect immediately following the
<message-body> that concludes the authentication exchange for the
client, and the <message-body> of 235 (236) response for the
server. I.e., for later requests (and responses) all data -
including the status line and headers - will be protected by the
new security layer.
The same rules apply in a case of reauthentication. Whenever a new
security layer (including the empty one) is negotiated due to
reauthentication, the current layer gets replaced (dropped)
immediately after transmission (receipt) of the 235 (236) response.
Note that a security layer requires HTTP/1.1 persistent connection.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 15]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
4.4.3 Interaction with TLS
A client may not perform an HTTP/1.1 "Upgrade" to TLS [RFC2817]
while conducting a SASL negotiation, but is free to do so after, or
before, the SASL negotiation takes place.
This document allows for both a TLS and a SASL security layer to be
active at the same time. No matter in which order they were
negotiated, any data will be transformed by the SASL security layer
first and then by TLS, i.e. the relevant protocol stack will be as
follows:
+---------+
| HTTP |
+---------+
| SASL |
+---------+
| TLS |
+---------+
| TCP |
+---------+
4.5 Status codes and error handling
4.5.1 Client errors
HTTP/1.1 status codes which apply to SASL-based mechanisms are:
-235 - Authentication Completed
This status code indicates that SASL authentication with the server
is complete and the client may retry sending the original request.
-236 - Proxy Authentication Completed
This status code indicates that SASL authentication with the proxy
is complete and the client may retry sending the original request.
-401 - Unauthorized
An HTTP/1.1 server will use this status code when credentials
supplied by a client could not be validated, in addition to the use
described in Section 4.3 above.
-407 - Proxy Authentication Required
An HTTP/1.1 server (proxy) will use this status code when credentials
supplied by a client could not be validated, in addition to the use
described in Section 4.3 above.
-432 - Transition Needed
This status codes indicates that the user name is valid, but the
entry in the authentication database needs to be updated in
order to permit authentication with the specified SASL mechanism.
This typically is done by authenticating once using the PLAIN
authentication mechanism. This SHOULD be done with appropriate TLS
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 16]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
protection in place.
An interactive client MUST warn the user before proceeding with PLAIN
authentication.
This status code can be sent, for example, if a user has an entry in
a system authentication database such as Unix /etc/passwd, but does
not have credentials suitable for use by the specified mechanism.
-450
- Authentication mechanism not accepted
An HTTP/1.1 server will use this status code when a client suggests
an authentication mechanism which is not supported or accepted by
the server.
4.5.2 Server errors
When a client does not support any of the security mechanisms
suggested by a server, or is otherwise unable to complete a SASL
mechanism handshake with a server, it shall close the connection.
(instead of closing connection the client MAY also cancel SASL
exchange by specifying "*" in <sasl-credentials> as described in
Section 4.3.10). User-oriented clients SHOULD provide the user with
information about the failed handshake, and MUST fail in a
controlled, predictable manner.
4.6 Authorization identity
This document defines that an authorization identity in HTTP
profile of SASL is a sequence of Unicode characters (excluding
NUL), encoded in UTF-8. This sequence is further prepared using
"SASLPrep" profile [SASLPrep] of the "stringprep" algorithm
[StringPrep]. The latter restriction is required in order to have
a predictable result when comparing two authorization identities
entered by two different people, potentially using different input
mechanisms. This is also required as many SASL mechanisms use
authorization identities to produce hashes.
Clients MUST use the algorithm described above on authorization
identities entered by a user (for interactive clients) or read from
a configuration file. Servers MUST verify that a received
authorization identity is in the correct form. If the preparation
of the authorization identity fails or results in an empty string,
the server MUST fail the authentication exchange. The only
exception to this rule is when the received authorization identity
is already the empty string.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 17]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
4.7 Examples
Note: In the examples, some lines are wrapped for readability
reasons.
4.7.1 Example 1 - Server requires authentication
This example illustrates a client requesting a URL and a server
responding with a list of supported SASL mechanisms. The client
selects one of these and responds with a new request containing an
initial-response type <sasl-credentials> directive. The server then
issues a <sasl-challenge> directive back to the client which once
again responds with a <sasl-credentials> directive in the
Authorization header field.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5",
realm="testrealm@example.com",
id="jfkasdgru42705"
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="CRAM-MD5",
id="jfkasdgru42705"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705",
challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
Lm1jaS5uZXQ+
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="jfkasdgru42705",
credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
zODkw
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 18]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705"
Client retries original request after that:
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 200 OK
Cache-Control: no-store
...Requested Document follows...
4.7.2 Example 2 - Initial response
In this example a client knows in advance that a certain SASL
mechanism is required. The mechanism allows for an initial-response
type message and the client therefore includes a <sasl-credentials>
directive in its Authorization header. The server accepts the
credentials and responds with the requested information.
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="SECURID",
credentials=AG1hZ251cwAxMjM0NTY3OAA=
The client doesn't know if authentication is complete at this
point, as certain SASL mechanisms have variable number of steps.
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705"
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 200 OK
Cache-Control: no-store
...Requested Document follows...
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 19]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
4.7.3 Example 3 - One mechanism only
In this example a server supports only one SASL mechanism, that
allows for sending of initial challenge to a client.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanisms="CRAM-MD5",
realm="testrealm@example.com",
id="jfkasdgru42705",
challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
Lm1jaS5uZXQ+
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="jfkasdgru42705",
credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
zODkw
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705"
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 200 OK
Cache-Control: no-store
...Requested Document follows...
4.7.4 Example 4 - Server sends additional data
This example demonstrates the use of an integrity/privacy layer.
Note that the client is using the CONNECT method, as it is willing
to negotiate integrity/privacy protection provided by the DIGEST-
MD5 SASL mechanism.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 20]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5",
realm="testrealm@example.com",
id="0001"
C: CONNECT classified.example.com:80 HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 200 OK
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="DIGEST-MD5",
id="0001"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="0001",
challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001",
credentials=Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJ
lYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT
0iT0E2TUc5dEVRR20yaGgiLG5jPTAwMDAwMDAxLGNub
25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9
ImltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9
uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxND
NhZjcscW9wPWF1dGg=
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="0001",
challenge=cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM
4YzkyMjcyNQ==
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 21]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001"
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL
id="0001"
CP: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
SP: HTTP/1.1 200 OK
...Requested Document follows...
CP: ...Any subsequent request for a data on the same server,
unless the server requests reauthentication...
4.7.5 Example 5 - Abort
The following example shows how a client can abort an
authentication exchange.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5",
realm="testrealm@example.com",
id="0001"
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="DIGEST-MD5",
id="0001"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="0001",
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 22]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001",
credentials=*
S: HTTP/1.1 401 Authentication Canceled
...
4.7.6 Example 6 - Client requires authentication
The following example is almost identical to Example 1, but here
the client requires authentication to the server.
C: OPTIONS http://classified.example.com/classified.html HTTP/1.1
Authorization: SASL
Host: classified.example.com
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanism="DIGEST-MD5,GSSAPI,CRAM-MD5",
realm="testrealm@example.com",
id="jfkasdgru42705"
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="CRAM-MD5",
id="jfkasdgru42705"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705",
challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
Lm1jaS5uZXQ+
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-store
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 23]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="jfkasdgru42705",
credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
zODkw
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL
id="jfkasdgru42705"
Upon receipt of a 235 response the client submits the request it
originally intended to submit:
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 200 OK
Cache-Control: no-store
...Requested Document follows...
4.7.7 Example 7 - Client uses POST request
In this example the client is willing to perform a POST request but
the server requires authentication and the establishment of a
security layer.
Note that since the client sends its information unprotected in the
initial POST message, in effect only the server's response (and any
later messages) will benefit from this security layer.
C: POST http://classified.example.com/update_classified.php
HTTP/1.1
Host: classified.example.com
Content-Type: ...
Content-Length: ...
...request body...
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
mechanisms="DIGEST-MD5,GSSAPI,OTP",
realm="testrealm@example.com",
id="0001"
C: CONNECT classified.example.com:80 HTTP/1.1
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 24]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Host: classified.example.com
S: HTTP/1.1 200 OK
C: POST http://classified.example.com/update_classified.php
HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="OTP",id="0001",credentials=AHRpbQ==
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: SASL
id="0001",challenge=b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
C: POST http://classified.example.com/update_classified.php
HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001",credentials=aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
S: HTTP/1.1 235 OK
Cache-Control: no-store
WWW-Authenticate: SASL id="0001"
CP: POST http://classified.example.com/update_classified.php
HTTP/1.1
Host: classified.example.com
Content-Type: ...
Content-Length: ...
...request body...
SP: HTTP/1.1 200 OK
...Response to POST, if any...
CP: ...Any subsequent request for a data on the same server,
unless the server requests reauthentication...
4.8 Interoperability with existing HTTP/1.1 clients and servers
A client supporting a certain SASL-based authentication mechanism
allowing for initial responses MUST NOT include a <sasl-
credentials> directive with a "SASL" <auth-scheme> authorization
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 25]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
request in an Authorization or Proxy-Authorization header unless it
knows that the server supports the SASL mechanism in question. The
client MAY use an OPTIONS request to find out about the server's
SASL capabilities.
A server supporting SASL-based authentication SHOULD include a
"Basic" and a "Digest Access" <auth-scheme> token in a WWW-
Authenticate or Proxy-Authenticate header field, if these
authentication methods are acceptable to the server. This ensures
proper interworking with clients only capable of performing a
"Basic" or "Digest Access" authentication. Since these
authentication mechanisms does not offer strong security, the risk
of downgrading attacks should be carefully considered (see also the
"Security Considerations" section in this memo and Section 4.1 and
4.2 in [RFC2617]).
4.9 Preferences
Servers MUST list authentication mechanisms in the WWW-Authenticate
(Proxy-Authenticate) header field in preferred order.
4.10 SASL mechanism recommendations
It is RECOMMENDED that an SASL mechanism that supports the
negotiation of a security layer with integrity protection be used,
and that this protection be enabled to avoid the connection being
hijacked after authentication has taken place. [RFC2222] discusses
some of the security issues related to SASL mechanisms.
5 IANA considerations
5.1 GSSAPI/SASL service name
For use with SASL [RC2222], a protocol must specify a service name
to be used with various SASL mechanisms, such as GSSAPI. For HTTP,
the service name shall be "http".
5.2 HTTP/1.1 Status codes
This memo defines the following HTTP/1.1 status codes:
-235 "Authentication Completed"
-236 "Proxy Authentication Completed"
-432 "Transition Needed"
-450 "Authentication mechanism not accepted"
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 26]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
6 Security considerations
6.1 Introduction
This memo describes a method to integrate the SASL framework in
HTTP/1.1. SASL as such allows a wide variety of mechanism, each
with their own security characteristics. Being descriptive rather
than prescriptive, this memo does not mandate any particular SASL
mechanism, and a complete threat analysis can therefore not be
given. The following sections represent an attempt to discuss
threats that can be regarded to be generic in the sense that they
apply to the integration itself rather than specific SASL
mechanisms. Security services offered by, and security
considerations applying to, particular SASL mechanisms can be found
through the IANA SASL mechanism registry.
6.2 Active attacks
6.2.1 Man-in-the-middle
Users of SASL in HTTP/1.1 SHOULD recognize that certain man-in-the-
middle attacks are possible since the negotiation of the particular
SASL security mechanism to be used is not necessarily protected.
For example, if the server suggests SASL mechanisms A, B and C in a
"SASL" <auth-scheme> message where A is a "strong" mechanism (for
some definition of "strong") but B and C are "weak" or provide
fewer security attributes than A, then an attacker could simply
remove A from the list. This forces the client to choose a
"weaker" mechanism and neither side will necessarily detect the
changes made by the attacker.
To mitigate these attacks, servers SHOULD only suggest SASL
mechanisms that will provide adequate security for the task at
hand.
Similarly, the SASL <auth-scheme> token may be removed from the
WWW-Authenticate (Proxy-Authenticate) header, thus forcing use of
either the Basic or Digest Access method. For this reason, and
unless other precautions (such as only accepting certain SASL
mechanisms) are taken, it is RECOMMENDED that this authentication
mechanism be used only in conjunction with a transport, e.g. TLS,
providing protection against these attacks (server authentication
and integrity protection of messages).
6.2.2 Denial of service
Since HTTP/1.1 requests and responses are not protected against
modification per se, an attacker may, by removing SASL elements
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 27]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
from HTTP/1.1 headers hinder a client from accessing a certain
service. This is however a generic threat and not specific to the
mechanism described herein.
6.2.3 Replay
Use of the "Cache-Control: no-store" and "Pragma: no-cache" headers
when indicated in requests and responses ensures that proxies do
not inadvertently store and/or deliver SASL handshake messages that
otherwise could be used in replay attacks.
6.3 Passive attacks
Unless a transport security providing confidentiality is employed,
the method described in this memo is susceptible to passive attacks
where an attacker wants to find out about the mechanisms that are
supported by a particular client.
6.4 Protecting body of POST/PUT requests
When the client performs a POST/PUT request in the clear and gets
Unauthorized response back from the server it is already too late
to protect the body of the POST/PUT request, as it was already sent
in the clear. Arguably, if the client sent some data in the clear
with user's permission, the user doesn't find the information being
sent worth protecting. However, existing web clients are able to
warn users about sending data in the clear, but don't have an
option to establish a secure connection first.
The described problem is not specific to this document. HTTP over
TLS uses a different URL schema to notify the client that it has to
establish a secure connection first with TLS.
So, one way to mitigate the problem would be to define a new URL
schema (or extension to the existing URL schema) for SASL in HTTP.
Authors felt that this solution would be too radical and thus
outside of the scope for this document. A separate document might
be defined in the future.
A client wishing to protect body of a POST/PUT request from
modification and/or disclosure should first establish a channel
protection using TLS and/or SASL. In general, an interactive client
SHOULD ask a user (or be configurable) to establish channel
protection before performing any POST/PUT.
6.5 Other considerations
Section 8.2 of [RFC2817] contains relevant security considerations
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 28]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
for the CONNECT method.
Note that SASL mechanisms offering confidentiality and integrity
protection of messages are only usable in conjunction with the
CONNECT method as described, since a proxy otherwise would be
unable to handle the messages properly.
Section 6.3 ("Multiple authentications") of [RFC2222] contains
security considerations regarding replacing a SASL security layer
with no layer on reauthentication.
7 Implementation considerations
7.1 SASL context
SASL context SHOULD be kept for some period of time after the
connection goes away. The period is implementation defined. The
SASL context SHOULD be deleted once the session expires, and MUST
be deleted once the authentication exchange completes with success
or failure, or the session becomes otherwise invalid (e.g. when a
duplicated authentication exchange was received for the same
session).
Although, a particular implementation may choose to store any SASL
security layer state (e.g. encryption/decryption keys) as a part of
the SASL context, this document will consider a SASL security layer
state to be a separate entity from the corresponding SASL context.
The SASL security layer state is deleted when the connection it is
protecting is closed or the corresponding authentication exchange
fails. In the latter case we are talking about partially created
SASL security layer state. However, as opposed to the SASL context,
the SASL security layer state is not deleted when the
authentication exchange completes successfully.
7.2 SASL security layer
The following section attempts to summarize a client/server
behaviour when it wants/doesn't want to negotiate a SASL security
layer.
A client willing to negotiate a SASL security layer must perform
all of the following steps:
a). Use persistent connection to perform a SASL authentication
exchange (Section 4.4.2). A SASL security layer (if supported
by the server and negotiated) can be only used on the TCP
connection that was used for the final "round" (i.e. C->S:
client response, S->C: server confirms that authentication
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 29]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
was successful) of the authentication exchange. Note, that some
SASL mechanisms use IP addresses in authentication exchange,
which effectively requires the use of persistent connection
during the whole authentication exchange.
b). Use CONNECT to establish end to end tunnel through proxies,
unless the client has a prior knowledge that it talks directly
to the target server (Section 4.3.2).
c). Notify the SASL layer/library being used that it supports
channel integrity and/or confidentiality.
As SASL security layer is an optional feature of SASL, the rules
a)-c) don't guaranty that a security layer will be negotiated. The
client that requires a security layer MUST check after successful
authentication that the one was indeed negotiated.
If a client "B" is not able and/or not willing to negotiate a SASL
security layer it MUST notify the SASL layer/library being used
that it doesn't support channel integrity or confidentiality.
Failure to do so may result in a situation when both ends negotiate
a SASL security layer, but the client is unable to use it. The
client "B" doesn't have to do step b) and MAY not do the step a).
Similarly, a server willing to negotiate a SASL security layer must
perform all of the following steps:
a). Use persistent connection to perform a SASL authentication
exchange (Section 4.4.2). A SASL security layer (if supported
by the client and negotiated) can be only used on the TCP
connection that was used for the final "round" of the
authentication exchahge.
b). Support CONNECT method (Section 4.3.2).
c). Notify the SASL layer/library being used that it supports
channel integrity and/or confidentiality.
Same as above, the rules a)-c) don't guaranty that a security layer
will be negotiated. The server that requires a security layer MUST
check after successful authentication that the one was indeed
negotiated.
If a server is not able and/or not willing to negotiate a SASL
security layer it MUST notify the SASL layer/library being used
that it doesn't support channel integrity or confidentiality.
Failure to do so may result in a situation when both ends negotiate
a SASL security layer, but the server is unable to use it.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 30]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
8 Acknowledgements
Text for Section 4.6 was borrowed from [RFC2829]. Thanks to Keith
Burdis, Raif S. Naffah, Mark Nottingham, Joe Orton and John P Speno
for providing useful feedback and suggestions.
Robert Zuccherato, Entrust Inc., made significant contributions to
earlier drafts of this work.
Big part of this document was written while Alexey was working for
MessagingDirect.
9 Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10 References
10.1 Normative references
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," IETF RFC 2026, October 1996.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 31]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", IETF RFC 3548, July 2003
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," IETF RFC 2119, March 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer,"
IETF RFC 2222, October 1997, also being revised by draft-ietf-sasl-
sasl-XX.txt, Work in progress
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF," IETF RFC 2234, November 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer
Protocol -- HTTP/1.1," IETF RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., Stewart, L., "HTTP Authentication:
Basic and Digest Access Authentication," IETF RFC 2617, June 1999.
[RFC2817] Khare, R., Lawrence, S., "Upgrading to TLS Within
HTTP/1.1," IETF RFC 2817, May 2000.
[Stringprep] P. Hoffman, M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user
names and passwords", Work in progress, draft-ietf-sasl-saslprep-
XX.txt.
10.2 Informative references
[RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0,"
IETF RFC 2246, January 1999.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
"Authentication Methods for LDAP," IETF RFC 2829, May 2000.
11 Authors' addresses
Magnus Nystrom Email: magnus@rsasecurity.com
RSA Security
Box 10704
121 29 Stockholm
Sweden
Alexey Melnikov Email: Alexey.Melnikov@isode.com
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 32]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Isode Limited
5 Castle Business Village,
36 Station Road,
Hampton, Middlesex,
United Kingdom, TW12 2BX
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 33]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Appendix A. Changes since previous revisions
Changes since -07
Added "Implementation consideration" section with big discussion on
how to correctly implement a SASL security layer. (Comment by Keith
Burdis)
Moved the biggest part of "SASL Context" definition to the
"Implementation consideration".
Added text describing that SASLPrep should be used on authorization
identities.
Added section describing ways to protect/help protect body of a
POST/PUT request. (Comment by Keith Burdis)
Several minor fixes.
Changes since -06
Changed 102 status code back to 401.
"credentials" directive is no longer returned by the server, only
"challenge" is used.
Added text about SASL context.
Split "SASL handshake initiation" section into Client and Server
initiated.
Added text about performing multiple authentications in parallel.
Clarified the use of persistent connection with SASL. Added
warnings about session caching and expiration. Updated text to
tell when SASL context is destroyed.
Added new status codes: 450 "Authentication mechanism not
accepted".
Expired session is denoted by a 401 (407) response with a new
<sasl-sid> value.
Clarified when security layer is replaced/dropped on
reauthentication.
Added warning that the server is required to keep track of
authenticated clients. Removed the text that was saying that the
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 34]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
server must return sasl-sid in 200 responses when authentication is
complete.
Updated examples as a result of the changes mentioned above.
Other minor clarifications.
Changes since -05
Replaced "Cache-Control: no-cache" with "Cache-Control: no-store"
as per Mark Nottingham comment.
ABNF corrections from Joe Orton and John P Speno.
More corrections from Joe Orton.
Changed 401 to a new status code 102 used solely for
authentication.
Added Transition Needed status code (432). Should check if this
code conflicts with anything.
Added new "Expect: 102-continue" header.
Reworked Section 4.3 to describe more error cases and more detailed
implementation instructions.
Disallow TLS Upgrade during SASL authentication (it is fine before
or after). Clarified order of security layers.
Clarified that Authorization header with SASL response MUST NOT be
used with CONNECT.
Relaxed restriction for mixing SASL session ids on the same
connection in certain cases.
Added new 235/236 status codes for successfully completed
authentication.
Clarified that the body of the original request MUST NOT be sent
until authentication is complete. Updated examples to reflect that.
Added an example with a POST request.
Changes since -04
Reworked the Introduction section.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 35]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
Updated example 4.7.4 to include Authorization header in CONNECT
request. This saves a round trip.
Added text that the client must use OPTIONS to find out which SASL
mechanisms are supported by the server. Added an example.
Added text regarding the server requiring reauthentication when the
client leaves the realm it authenticated in.
Some clarification about the CONNECT method. Added text that a
CONNECT request should start the authentication exchange.
Incorporated comments from Raif S. Naffah and Keith Burdis.
Changes since -03
Fixed several errors in examples due to change from "sasl-
mechanism" to "sasl-mechanisms".
More comments from Keith Burdis.
Changes since -02
Added discussions about CONNECT and session protection.
Added "Proxy servers considerations" Section. Updated examples to
include headers that prevent caching.
Added Web farm considerations section that talks about a next
response going to a different backend web-server.
Incorporated many suggestions/corrections from Keith Burdis.
Editorial changes. Cleanup some SHOULDs and MUSTs.
Changes since -01
Added examples
Split ABNF into client and server side. ABNF cleanup.
Many editorial changes.
Appendix B. Major Open Issues
235/236 status codes for successful authentication, and related to
this: When using a security layer, should the status line be
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 36]
INTERNET DRAFT SASL in HTTP/1.1 October 2003
transmitted twice: once in cleartext and once in the encrypted
block? (Another proposal is to return 100/failure response code in
the clear and the success in the encrypted block).
401 vs. new 1xx response code for authentication exchange.
Nystrom & Melnikov Expires: April 2004 FORMFEED[Page 37]