INTERNET-DRAFT Magnus Nystrom
November, 2001 RSA Security
Expires: May, 2001 Robert Zuccherato
Intended category: Standards track Entrust Technologies
Alexey Melnikov
ACI WorldWide/MessagingDirect
SASL in http/1.1
draft-nystrom-http-sasl-01.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 (2001). 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 list.
Nystrom & Zuccherato Expires: May 2001 [Page 1]
INTERNET DRAFT SASL in http/1.1 November 2001
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.
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>>.
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].
2.2 Examples
Examples in this memo are for the http/1.1 profile of this
specification. Encodings of challenges and responses are part of the
http/1.1 profile.
3 Relationship with the http/1.1 specification
This memo relies on the http/1.1 [RFC2616] specification. As with RFC
2617, 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.
Nystrom & Zuccherato Expires: May 2001 [Page 2]
INTERNET DRAFT SASL in http/1.1 November 2001
4 SASL Framework
4.1 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 productions are:
challenge = auth-scheme 1*SP 1#auth-param
auth-scheme = token
auth-param = token "=" (token | quoted-string)
The authentication parameter "realm" is defined for all
authentication schemes:
realm = "realm" "=" realm-value
realm-value = 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 are defined
as follows:
credentials = auth-scheme #auth-param
The response will be found in an Authorization or a Proxy-
Authorization header field.
4.2 Supporting SASL in http/1.1 - syntax
4.2.1 Recognition of the scheme
The use of a SASL authentication scheme is indicated by the auth-
scheme token "SASL". A server MUST use this auth-scheme token if it
supports SASL and is willing to perform a SASL-based mechanism.
4.2.2 ABNF Grammar for SASL mechanisms
See [RFC2616] for a definition of the augmented BNF grammar.
sasl-token = SASL 1*SP 1#sasl-parameter
Nystrom & Zuccherato Expires: May 2001 [Page 3]
INTERNET DRAFT SASL in http/1.1 November 2001
sasl-parameter = sasl-mechanism | sasl-sid | realm
| sasl-challenge | sasl-credential
; Note: realm is defined in [RFC2617]
SASLCHAR = UPALPHA | DIGIT | "-" | "_"
; Characters allowed in SASL mechanism name
sasl-mech-name = 1*20 SASLCHAR
; Name must be from IANA set of registered SASL mechanisms,
; e.g. "SECURID"
sasl-mechanism = "mechanism" "=" <"> 1#sasl-mech-name <">
sasl-sid = "id" "=" quoted-string
sasl-challenge = "challenge" "=" base64-string
sasl-credential = "credential" "=" base64-string | "*"
base64-string = *BASE64 *2"="
; Encoding must be in accordance with [RFC2045], except not
; limited to 76 chars/line
BASE64 = DIGIT | ALPHA | "+" | "/"
Note: All directives ("mechanism", "id", "realm", "challenge", and
"credentials" are case-insensitive. All directive values are case-
sensitive.
4.3 Usage model
4.3.1 SASL handshake initiation
When a server, which requires SASL-based authentication, is about to
respond with a 401 - Unauthorized (407 - Proxy Authentication
Required) response, it SHALL include a <sasl-token> value in a WWW-
Authenticate (or Proxy-Authenticate) header field. The server MUST
list all supported and acceptable SASL mechanisms in <sasl-mechanism>
directives. If the server only supports one SASL mechanism, it MAY
include a <sasl-challenge> directive in order to reduce the number of
roundtrips. 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].
A client, which is about to issue a request to a server, and knows
Nystrom & Zuccherato Expires: May 2001 [Page 4]
INTERNET DRAFT SASL in http/1.1 November 2001
that the server requires a certain SASL mechanism, MAY include a
<sasl-credential> directive in a <sasl-token> in an Authorization (or
Proxy-Authorization) field in its request. This is useful to minimize
the number of roundtrips when a server does not explicitly have to
send the client a challenge (or information about the realm in
question). In this situation the client MUST also include a value in
a <sasl-sid> directive to identify the secure session being
negotiated. This value MUST be the same for all messages associated
with that session. Only one <sasl-sid> directive must be sent.
Note: C.f. the "initial response" in [RFC2222].
4.3.2 Client response
A client, which receives a <sasl-token> value in a WWW-Authenticate
(Proxy-Authenticate) header in a 401 - Unauthorized (407 - Proxy
Authentication Required) response, SHALL choose one of the available
mechanisms and respond with a suitable <sasl-credential> directive in
a <sasl-token> in a Authorization (Proxy-Authorization) header field
in its next request. If the chosen mechanism allows for "initial
response" type messages, the client MUST include the initial response
in its request. The client MUST also return the <sasl-sid> value in
the corresponding field of <sasl-token>.
4.3.3 Server behaviour upon receiving a <sasl-token>
The server (proxy), upon receiving a <sasl-token> value containing 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 in a <sasl-
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, but 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 - Unauthenticated (407 - Proxy Authentication Required)
response containing a <sasl-credential> directive in a <sasl-token>
in a WWW-Authenticate (or Proxy-Authenticate) header. The client MUST
reply to this with the original request if any. (<<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-token>. In this
Nystrom & Zuccherato Expires: May 2001 [Page 5]
INTERNET DRAFT SASL in http/1.1 November 2001
situation, no <sasl-credential>, <sasl-challenge> or <sasl-mechanism>
directive shall be present. In all cases, the server MUST also
return the <sasl-sid> value in the corresponding field.
The presence of the WWW-Authenticate (or Proxy-Authenticate) header
containing a <sasl-credential> directive in a <sasl-token> on a
message that is not a 401 - Unauthenticated response indicates
successful authentication of the client.
4.3.4 Final part of handshake
The client, upon receiving a <sasl-challenge> directive in a <sasl-
token> 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 in a <sasl-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. However, if the client is going to
make any further requests within the given realm, it SHOULD include a
<sasl-token> in an Authorization (Proxy-Authorization) header that
does not contain a <sasl-credential> directive. In all cases, the
client MUST return the <sasl-sid> directive in <sasl-token>.
4.3.5 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
encryption block when a SASL security layer has been negotiated.
4.3.6 Other considerations
Clients MAY abort authentication exchanges at any time, by specifying
"*" in <sasl-credential> and including <sasl-sid> of the
authentication exchange being canceled. 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-
Nystrom & Zuccherato Expires: May 2001 [Page 6]
INTERNET DRAFT SASL in http/1.1 November 2001
Authenticate field containing a <sasl-token> in a respone.
There MUST NOT be more than one Authorization or Proxy-Authorization
header field containing a <sasl-token> in a request.
4.4 Request/Response Encoding
4.4.1 SASL Challenge/Response Encoding
The <sasl-challenge> directive and the <sasl-credential> directive
contains 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 Integrity/Privacy protection
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. The protection takes
effect immediately following the <message-body> that concludes the
authentication exchange for the client, and the <message-body> of the
success reply for the server.
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 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.
4.5.2 Server errors
Nystrom & Zuccherato Expires: May 2001 [Page 7]
INTERNET DRAFT SASL in http/1.1 November 2001
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 may
not correspond to the authorization identities used to express a
server's access control policy, requiring a server-specific mapping
to be done.
4.7 Examples
4.7.1 Example 1
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.
<TBW>
4.7.2 Example 2
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.
Nystrom & Zuccherato Expires: May 2001 [Page 8]
INTERNET DRAFT SASL in http/1.1 November 2001
<TBW>
4.8 Interoperability with existing http/1.1 clients and servers
A client supporting SASL-based authentication MUST NOT include a
<sasl-credential> directive in a <sasl-token> value in an
Authorization or Proxy-Authorization header unless it knows that the
server supports this SASL mechanism. 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
proper interworking with clients only capable of performing a "Basic"
or "Digest Access" authentication.
4.9 Preferences
Servers MUST list authentication mechanisms in WWW-Authenticate
(Proxy-Authenticate) header field in preferred order.
4.10 Other considerations
<<Perhaps a discussion on caching at proxies, c.f. RFC 2616 Section
13.6 and 13.7?>>
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 Man-in-the-middle attacks
Users of this protocol SHOULD be recognize that certain man-in-the-
middle attacks are possible since the negotiation of the particular
SASL security mechanism to be used is not protected. For example, if
the server suggests SASL mechansims A, B and C in a <sasl-token>
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
Nystrom & Zuccherato Expires: May 2001 [Page 9]
INTERNET DRAFT SASL in http/1.1 November 2001
forces the client to choose a "weaker" mechanism and neither side
will detect the changes made by the attacker.
Thus 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, it is
recommended to use this authentication mechanism in conjunction with
an existing underlying TLS session.
6.2 Replay attacks
<TBW>
6.3 Other considerations
<TBW>
7 Acknowledgements
Text for Section 4.6 was borrowed from [RFC2829].
8 Copyright
Copyright (C) The Internet Society (2001). 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
Nystrom & Zuccherato Expires: May 2001 [Page 10]
INTERNET DRAFT SASL in http/1.1 November 2001
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
[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
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.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
"Authentication Methods for LDAP," IETF RFC 2829, May 2000.
10 Authors' Addresses
Magnus Nystrom
RSA Security
Box 10704
121 29 Stockholm
Sweden
Phone: +46 8 725 0900
Email: magnus@rsasecurity.com
Robert Zuccherato
Entrust Technologies
1000 Innovation Drive
Ottawa, Ontario
Nystrom & Zuccherato Expires: May 2001 [Page 11]
INTERNET DRAFT SASL in http/1.1 November 2001
Canada K2K 3E7
Phone: +1 613 270 2598
Email: robert.zuccherato@entrust.com
Alexey Melnikov
ACI WorldWide/Messaging
10117 Jasper Avenue,
Edmonton, Alberta,
Canada T5J1W8
Phone: +1 780 424-4922 Ext. 357
Email: mel@messagingdirect.com
Nystrom & Zuccherato Expires: May 2001 [Page 12]
