INTERNET-DRAFT Magnus Nystrom
September, 2003 RSA Security
Expires: March, 2002 Alexey Melnikov
Intended category: Standards track ACI WorldWide/MessagingDirect
Robert Zuccherato
Entrust, Inc.
SASL in HTTP/1.1
draft-nystrom-http-sasl-04.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 (2002). 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 defines one approach to accomplish this.
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 RFC 2119 [RFC2119].
Please send comments on this document to the relevant mailing lists,
e.g. ietf-sasl@imc.org.
Nystrom et al. Expires: March 2003 [Page 1]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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 ...................... 6
4.3 Usage model .............................................. 7
4.3.1 SASL handshake initiation .............................. 7
4.3.2 Client response ........................................ 8
4.3.3 Server behaviour upon receiving a "SASL" <auth-scheme>
token .................................................. 8
4.3.4 Final part of handshake ................................ 9
4.3.5 Subsequent requests .................................... 9
4.3.6 Example sequence diagram ............................... 9
4.3.7 Pipelining considerations ............................. 10
4.3.8 Proxy considerations .................................. 10
4.3.9 "Web farm" considerations ............................. 10
4.3.10 Other considerations ................................. 11
4.4 Request/response encoding ............................... 11
4.4.1 SASL challenge/response encoding ...................... 11
4.4.2 Security layer......................................... 11
4.5 Error handling .......................................... 12
4.5.1 Client errors ......................................... 12
4.5.2 Server errors ......................................... 12
4.6 Authorization identity .................................. 12
4.7 Examples ................................................ 13
4.7.1 Example 1 - Server requires authentication ............ 13
4.7.2 Example 2 - Initial response .......................... 14
4.7.3 Example 3 - One mechanism only ........................ 14
4.7.4 Example 4 - Server additional data .................... 15
4.7.5 Example 5 - Abort ..................................... 16
4.8 Interoperability with existing HTTP/1.1 clients and
servers ................................................. 17
4.9 Preferences ............................................. 18
5 IANA considerations ...................................... 18
5.1 GSSAPI/SASL service name ................................ 18
6 Security considerations .................................. 18
6.1 Introduction ............................................ 18
6.2 Active attacks .......................................... 18
6.2.1 Man-in-the-middle ..................................... 18
6.2.2 Denial of service ..................................... 19
6.2.3 Replay ................................................ 19
Nystrom et al. Expires: March 2003 [Page 2]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
6.3 Passive attacks ......................................... 19
6.4 Other considerations .................................... 19
7 Acknowledgements ......................................... 20
8 Copyright ................................................ 20
9 References ............................................... 20
9.1 Normative references .................................... 20
9.2 Informative references .................................. 21
10 Authors' addresses ...................................... 21
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]." The
former of these two cannot be considered a secure authentication
scheme since it is based on passwords or passphrases, which
furthermore are unprotected unless used in conjunction with a lower-
level protocol offering security services. The latter, while
protecting against users transmitting passwords in clear, does not
provide a strong authentication mechanism as it is based on passwords
or passphrases.
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 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.
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.
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>>.
Nystrom et al. Expires: March 2003 [Page 3]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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.
The key words "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].
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 assumes persistent connections.
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
as follows:
credentials = auth-scheme #auth-param
The response will be found in an Authorization or a Proxy-
Authorization header field.
Nystrom et al. Expires: March 2003 [Page 4]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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-credentials)]
sasl-mechanisms = "mechanisms" "=" <"> 1#sasl-mech-name <">
sasl-mechanism = "mechanism" "=" <"> sasl-mech-name <">
realm = "realm" "=" quoted-string
; See RFC 2617
sasl-sid = "id" "=" quoted-string
sasl-challenge = "challenge" "=" base64-string
sasl-credentials = "credentials" "=" base64-string
; Only sent if mutual authentication
sasl-mech-name = 1*20 SASLCHAR
; Name must be from IANA set of registered SASL mechanisms,
; e.g. "SECURID"
base64-string = *BASE64 *2"="
; Encoding must be in accordance with [RFC2045], except not
; limited to 76 chars/line
SASLCHAR = UPALPHA | DIGIT | "-" | "_"
; Characters allowed in SASL mechanism name
BASE64 = DIGIT | ALPHA | "+" | "/"
WSAC = *LWS "," *LWS
Nystrom et al. Expires: March 2003 [Page 5]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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 MUST be unique for each connection. The state associated with
a particular sasl-sid MUST be deleted once the connection goes away
or otherwise becomes invalid.
sasl-challenge
A Base64-encoded challenge in accordance with a selected SASL
mechanism. MUST NOT be sent unless there is exactly one SASL
mechanism in the <sasl-mechanisms> directive.
sasl-credentials
Base64-encoded credentials in accordance with a selected SASL
mechanism. This is only sent when the server is authenticating to
the client, see Section 4.3.3 below.
4.2.3 SASL authorization request header
For the SASL scheme, the authorization request header is as follows:
credentials = SASL 1*SP sasl-request-parameters
sasl-request-parameters
= [sasl-mechanism WSAC] [sasl-sid WSAC]
[realm WSAC] [sasl-credentials]
The meanings of the values of the directives used above are as
follows:
sasl-mechanism
Nystrom et al. Expires: March 2003 [Page 6]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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 (see
below), 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 when a <sasl-challenge> directive has been
received by the server.
4.3 Usage model
4.3.1 SASL handshake initiation
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
including a WWW-Authenticate (or Proxy-Authenticate) header field
that contains "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. Multiple <sasl-sid> directives
MUST NOT be mixed on the same connection. 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 an
authentication exchange, the mechanism specific version of "realm"
must be used by the mechanism.
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
<sasl-credential> directive with a "SASL" <auth-scheme> token in an
Authorization (or Proxy-Authorization) header field in its request.
This is useful to minimize the number of roundtrips when a server
Nystrom et al. Expires: March 2003 [Page 7]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
does not explicitly have to send the client a challenge (or
information about the realm in question), c.f. the "initial response"
in [RFC2222] (see the example in Section 4.7.2). In this situation
the client MUST include a <sasl-mechanism> directive identifying the
used SASL mechanism, but MUST NOT include a <sasl-sid> directive
(session identifiers are to be chosen by servers).
4.3.2 Client response
A client, which receives a "SASL" <auth-scheme> authentication
response in a WWW-Authenticate (Proxy-Authenticate) header in a 401 -
Unauthorized (407 - Proxy Authentication Required) response, MUST
choose one of the available mechanisms and respond with an
Authorization (Proxy-Authorization) header containing a "SASL" <auth-
scheme> token with the chosen SASL mechanism in a <sasl-mechanism>
directive in its next request. If the chosen mechanism allows for
"initial response" type messages, the client MUST include the initial
response in a <sasl-credential> directive in its request. The client
MUST also return the <sasl-sid> value provided by the server.
If the client is able and willing to negotiate integrity and/or
privacy protection and the server supports a SASL mechanism that
provides for it, the client, before starting an authentication
exchange, MUST establish an end-to-end tunnel using the CONNECT
method as described in section 5.3 of [RFC2817]. Once the tunnel is
established, the client proceeds as described in the previous
paragraph.
4.3.3 Server behaviour upon receiving a "SASL" <auth-scheme> token
The server (proxy), upon receiving an authorization request
containing a "SASL" <auth-scheme> token with a <sasl-credential>
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 (possibly 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 not include the <sasl-challenge>
directive, in which case the client shall interpret the response in
accordance with Section 10.4.2 of [RFC2616].
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 (e.g. the final part of a three-way
handshake) be sent by the server, the server MUST respond with a 401
- Unauthorized (407 - Proxy Authentication Required) response
containing also a <sasl-credential> directive with its "SASL" <auth-
Nystrom et al. Expires: March 2003 [Page 8]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
scheme> authentication response token in a WWW-Authenticate (or
Proxy-Authenticate) header. The client MUST reply to this with the
original authorization request if any containing just a <sasl-sid>
directive (using the value for provided by the server). (<<What
about POST requests?>>) If the client is authenticated and the server
does not need to send any further challenge information, the server
MUST respond with the requested message-body, protected by the
negotiated security session (see Section 4.4), but including a WWW-
Authenticate (or Proxy-Authenticate) header containing a "SASL"
<auth-scheme> token. In this situation, no <sasl-credential>, <sasl-
challenge> or <sasl-mechanisms> directive shall be present in the
<auth-param> field.
The presence of the WWW-Authenticate (or Proxy-Authenticate) header
containing a "SASL" <auth-scheme> token and a <sasl-credential>
directive with an authentication response on a message that is not a
401 - Unauthorized (407 - Proxy Authentication Required) response
indicates successful authentication of the client.
4.3.4 Final part of handshake
The client, upon receiving a "SASL" <auth-scheme> authentication
response and 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 request containing a <sasl-credential> directive
and a "SASL" <auth-scheme> token in an Authorization (Proxy-
Authorization) header. If a WWW-Authenticate (Proxy-Authenticate)
header is received on a message that is not a 401 - Unauthorized (407
- Proxy Authentication Required) response, no further credentials are
required.
4.3.5 Subsequent requests
When making any further requests within the given realm, the client
SHOULD include a "SASL" <auth-scheme> authorization request in an
Authorization (Proxy-Authorization) header that does not contain a
<sasl-credential> directive. In all cases, the client MUST also
return the <sasl-sid> directive with its SASL authorization requests.
4.3.6 Example sequence diagram
Client Server
----------------- Initial Request ----------------------->
<------ 401 WWW-Authenticate SASL (mechanisms,realm,id) --
Nystrom et al. Expires: March 2003 [Page 9]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
--- Authorization (mechanism,id) ------------------------>
<------ 401 WWW-Authenticate SASL (id,challenge) ---------
--- Authorization (id,credential) ----------------------->
<------ 401 WWW-Authenticate SASL (id,credential) --------
--- Authorization (id,credential) ----------------------->
(0 or more times depending on the SASL mechanism)
<------ 200 WWW-Authenticate SASL (id) -------------------
Subsquent requests:
Client Server
--- Authorization (id) ---------------------------------->
<------ 200 WWW-Authenticate SASL (id) -------------------
4.3.7 Pipelining considerations
Clients MUST NOT send any other data until the authentication
exchange is complete. As a consequence, clients MUST NOT use
pipelining until any on-going authentication exchanges are completed
(whether successful or not).
Server MUST process all received requests before replying to a SASL
exchange initiation.
Clients MAY put multiple HTTP requests inside a single SASL block
when a SASL security layer has been negotiated.
4.3.8 Proxy 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-cache" and "Pragma: no-cache" (for compatibility with older proxy
servers) together with an "Authorization:" header in all intermediate
request. For the same reason, the server MUST send a "Cache-Control:
no-cache" 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
Nystrom et al. Expires: March 2003 [Page 10]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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, if a persistent connection to a particular server cannot
be guaranteed, 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-credential> 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.
4.4 Request/response encoding
4.4.1 SASL challenge/response Encoding
The <sasl-challenge> directive and the <sasl-credential> directive
contain SASL challenges and responses respectively. The challenges
and responses MUST be base64 [RFC2045] 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 client. Any negotiated
security layer takes effect immediately following the <message-body>
that concludes the authentication exchange for the client, and the
Status-Line of the success reply for the server. I.e., for later
requests (and responses) all data - including the status line and
headers - will be protected by the security layer.
Nystrom et al. Expires: March 2003 [Page 11]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
4.5 Error handling
4.5.1 Client errors
HTTP/1.1 status codes which applies to SASL-based mechanisms are:
-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.
-406 - Not Acceptable
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.
-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.
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.
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
An authorization identity is one kind of access control factor. It
is the name of the entity that requests that operations be performed.
Access control policies are often expressed in terms of authorization
identities; e.g., entity X can perform operation Y on resource Z.
The authorization identity bound to an association is often exactly
the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying. Also, the
form of authentication identity supplied by a service like TLS
[RFC2246] may not correspond to the authorization identities used to
express a server's access control policy, requiring a server-specific
mapping to be done.
Nystrom et al. Expires: March 2003 [Page 12]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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-credential> directive. The server then
issues a <sasl-challenge> directive back to the client which once
again responds with a <sasl-credential> 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-cache
WWW-Authenticate: SASL
mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5",
realm="testrealm@host.com",
id="jfkasdgru42705"
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="CRAM-MD5",
id="jfkasdgru42705"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
WWW-Authenticate: SASL
id="jfkasdgru42705",
challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
Lm1jaS5uZXQ+
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="jfkasdgru42705",
credential=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
zODkw
Nystrom et al. Expires: March 2003 [Page 13]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
S: HTTP/1.1 200 OK
WWW-Authenticate: SASL
id="jfkasdgru42705"
...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-credential>
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-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="SECURID",
credential=AG1hZ251cwAxMjM0NTY3OAA=
S: HTTP/1.1 200 OK
Cache-Control: no-cache
WWW-Authenticate: SASL
id="jfkasdgru42705"
...Requested Document follows...
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-cache
WWW-Authenticate: SASL
mechanisms="CRAM-MD5",
realm="testrealm@host.com",
id="jfkasdgru42705",
challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
Lm1jaS5uZXQ+
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Nystrom et al. Expires: March 2003 [Page 14]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
Authorization: SASL
id="jfkasdgru42705",
credential=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
zODkw
S: HTTP/1.1 200 OK
WWW-Authenticate: SASL
id="jfkasdgru42705"
...Requested Document follows...
4.7.4 Example 4 - Server additional data
In this example a server sends additional data with end-of-
authentication response. (C.f. the "success with additional data" in
[RFC2222]) The example also 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.
In examples, "CP:" and "SP:" indicate lines sent by a client and a
server respectively with integrity protection enabled.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
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-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="DIGEST-MD5",
id="0001"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
WWW-Authenticate: SASL
Nystrom et al. Expires: March 2003 [Page 15]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
id="0001",
challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001",
credential=Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJ
lYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT
0iT0E2TUc5dEVRR20yaGgiLG5jPTAwMDAwMDAxLGNub
25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9
ImltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9
uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxND
NhZjcscW9wPWF1dGg=
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
WWW-Authenticate: SASL
id="0001",
credential=cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM
4YzkyMjcyNQ==
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001"
S: HTTP/1.1 200 OK
SP: WWW-Authenticate: SASL
id="0001"
...Requested Document follows...
CP: ...Any subsequent request for a data in the same authentication
realm...
4.7.5 Example 5 - Abort
The following example shows how a client can abort authentication
exchange.
C: GET http://classified.example.com/classified.html HTTP/1.1
Host: classified.example.com
Nystrom et al. Expires: March 2003 [Page 16]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
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-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
mechanism="DIGEST-MD5",
id="0001"
S: HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
WWW-Authenticate: SASL
id="0001",
challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==
C: GET http://classified.example.com/classified.html HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
Host: classified.example.com
Authorization: SASL
id="0001",
credential=*
S: HTTP/1.1 401 Authentication Canceled
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-credential>
directive with a "SASL" <auth-scheme> authorization request in an
Authorization or Proxy-Authorization header unless it knows that the
server supports the SASL mechanism in question. The way the client
finds out about the server's capabilities in this respect is out of
scope for this memo. This ensures proper interworking with existing
HTTP/1.1 servers.
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
Nystrom et al. Expires: March 2003 [Page 17]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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 WWW-Authenticate
(Proxy-Authenticate) header field in preferred order.
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".
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
Nystrom et al. Expires: March 2003 [Page 18]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
and neither side will 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 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-cache" 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 Other considerations
Section 8.2 of [RFC2817] contains relevant security considerations
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.
Nystrom et al. Expires: March 2003 [Page 19]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
7 Acknowledgements
Text for Section 4.6 was borrowed from [RFC2829]. Thanks to Keith
Burdis for providing useful feedback and suggestions.
8 Copyright
Copyright (C) The Internet Society (2002). 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.
9 References
9.1 Normative references
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3," IETF RFC 2026, October 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies," IETF
RFC 2045, November 1996.
[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
Nystrom et al. Expires: March 2003 [Page 20]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
RFC 2222, October 1997.
[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.
9.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.
10 Authors' addresses
Magnus Nystrom Email: magnus@rsasecurity.com
RSA Security
Box 10704
121 29 Stockholm
Sweden
Alexey Melnikov Email: mel@messagingdirect.com
ACI WorldWide/Messaging
22 The Quadrant,
Richmond, Surrey,
United Kingdom, TW9 1BP
Robert Zuccherato Email: robert.zuccherato@entrust.com
Entrust, Inc.
1000 Innovation Drive
Ottawa, Ontario
Canada, K2K 3E7
Appendix A. Changes since previous revisions
Changes since -03
Nystrom et al. Expires: March 2003 [Page 21]
INTERNET DRAFT SASL in HTTP/1.1 September 2002
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.
Nystrom et al. Expires: March 2003 [Page 22]