Internet DRAFT - draft-burdis-http-sasl
draft-burdis-http-sasl
Network Working Group K.R. Burdis
Internet-Draft None
Expires: August 24, 2001 February 23, 2001
Upgrading to SASL Within HTTP/1.1
draft-burdis-http-sasl-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of 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.
This Internet-Draft will expire on August 24, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes how to use the Upgrade mechanism in HTTP/1.1
to initiate an SASL session over an existing TCP connection,
performing authentication using a negotiated SASL mechanism and then
tunnelling subsequent HTTP messages over this protected connection.
It is based on RFC 2817 which describes how to upgrade to TLS from
within HTTP.
Burdis Expires August 24, 2001 [Page 1]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. HTTP over SASL . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Upgrade header token . . . . . . . . . . . . . . . . . . . . . 6
4.2 Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Server Advertises Upgrade . . . . . . . . . . . . . . . . . . 8
5.2 Client Requests Upgrade . . . . . . . . . . . . . . . . . . . 8
5.3 Client Requires Upgrade . . . . . . . . . . . . . . . . . . . 9
5.4 Server Requires Upgrade . . . . . . . . . . . . . . . . . . . 9
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Burdis Expires August 24, 2001 [Page 2]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
Burdis Expires August 24, 2001 [Page 3]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
2. Motivation
Transport Layer Security (TLS) is used to protect the data
transmitted on a connection. It provides authentication and the
negotiation of a session key that can be used to protect the
connection. HTTP messages are protected using TLS by tunnelling
them through the TLS connection. The entire HTTP message is
protected and this does not require any changes to the HTTP
protocol. When using the persistant connections introduced in
HTTP/1.1 many HTTP request and response messages may be tunnelled
through a single TLS connection.
However, TLS requires that each party that wishes to authenticate
itself have an asymmetric public/private keypair. Typically the
server has its public key signed by a trusted Certification
Authority, and the server authenticates itself to the client.
Mutual authentication is rare because it is unusual for the client
to have a public/private keypair.
It is desirable to be able to have the benefits of using TLS with
HTTP while not necessarily having to use public key technology or a
trusted third party. For example, using password-based technologies
that offer mutual authentication and a security layer. It is also
desirable to have stronger authentication with HTTP than the
currently available Basic and Digest authentication.
The Simple Authentication and Security Layer (SASL) is a means of
adding authentication and a security layer to connection-based
protocols. There are a number of different SASL security mechanisms
that use different security technologies and have different
strengths and weaknesses. It is possible to add new mechanisms at a
later stage without having to change the way SASL works with the
protocol, or the way the protocol itself works.
This document describes a means of using SASL with HTTP so that the
benefits of TLS are achieved with the flexibility of SASL.
Burdis Expires August 24, 2001 [Page 4]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
3. Overview
RFC 2817 describes a means of using TLS with HTTP by upgrading to
TLS from within HTTP. The advantage of this is that a separate port
is not required for a secure connection. Once the upgrade is
initiated the TLS protocol starts. If TLS authentication is
successful, a secure connection is established and subsequent HTTP
messages are tunnelled through this connection.
The same procedure can be used with SASL. An HTTP client and server
negotiate an upgrade to an SASL mechanism. Once the upgrade is
initiated, the SASL mechanism protocol starts. If the
authentication procedure using this mechanism is successful,
subsequent HTTP messages are tunnelled through this SASL connection.
If a security layer was negotiated as part of the SASL mechanism
exchange then it is used to protect any messages passing through the
connection, otherwise the messages are passed through unchanged.
Burdis Expires August 24, 2001 [Page 5]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
4. HTTP over SASL
This profile is based on RFC 2817 "Upgrading to TLS Within HTTP"
which "explains how to use the Upgrade mechanism in HTTP/1.1 to
initiate Transport Layer Security (TLS) over an existing TCP
connection." The process described can also be used to initiate a
SASL session over an existing TCP connection. To do so it is
necessary to define a new Upgrade header token to indicate support
for establishing an SASL session using a specified mechanism, and to
describe how the new protocol will interact with HTTP.
4.1 Upgrade header token
The Upgrade header token is used to indicate which SASL mechanisms
are available to be used.
Section 4 of RFC 2222 specifies that when a client indicates the
SASL mechanism that it wishes to use it SHOULD be able to include an
initial response, so that it can avoid an extra round trip when the
mechanism is defined to have the client send data first. For this
reason a client MAY include a base-64 encoded initial response in
the Upgrade header token.
The token is defined as:
SASL+<mechanism>/<version> [ <response> ]
where:
<mechanism> is a valid SASL mechanism name
<response> is the optional base64-encoded initial response
<version> is a version identifier, currently 1.0
Valid mechanism values are those defined by IANA, as described in
section 6.2 of RFC 2222[6].
Example:
Upgrade: SASL+SRP-SHA-160/1.0 U1JQ...Zvbw==, SASL+DIGEST-MD5/1.0
An Upgrade header containing this token indicates support for
switching to HTTP over SASL using the specified SASL mechanism(s).
Burdis Expires August 24, 2001 [Page 6]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
4.2 Protocol Description
Section 10.1.2 of RFC 2616[3] states that:
"The server will switch protocols to those defined by the
response's Upgrade header field immediately after the empty line
which terminates the 101 response"
The chosen SASL mechanism's authentication protocol will start at
this point. (Note that an initial client authentication response may
have been sent as part of the Upgrade header token). Authentication
protocol messages generated by the chosen SASL mechanism are
base64-encoded before being sent over the wire.
If use of a security layer is negotiated during the mechanism
exchange then any HTTP requests or responses after the
authentication protocol is complete will pass through this security
layer. If no security layer is negotiated then these requests and
responses will remain unchanged.
Burdis Expires August 24, 2001 [Page 7]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
5. Scenarios
This section illustrates possible scenarios with examples.
5.1 Server Advertises Upgrade
From RFC 2817: "As specified in HTTP/1.1 , the server MAY include an
Upgrade header in any response other than 101 or 426 to indicate a
willingness to switch to any (combination) of the protocols listed".
Example:
Upgrade: SASL+SRP-SHA-160/1.0, SASL+DIGEST-MD5/1.0, HTTP/1.1
5.2 Client Requests Upgrade
The client indicates that it would like the current request to be
processed after a switch has been made to HTTP over SASL using one
of the specified mechanisms, by including an appropriate token in
the Upgrade header field it adds to the request message.
For example, the client sends:
GET http://topsecret.example.com/classified.html HTTP/1.1
Host topsecret.example.com
Upgrade: SASL+SRP-SHA-160/1.0 U1JQ...UAA2Zvbw==, SASL+DIGEST-MD5
Connection: Upgrade
In this case the server MAY respond to the HTTP request normally, OR
switch to a new protocol. If the server decides to switch to a new
protocol, it responds with a "101 Switching Protocols" status code
and includes an Upgrade header indicating what protocol it is
switching to. Example:
HTTP/1.1 101 Switching Protocols
Upgrade: SASL+SRP-SHA-160/1.0, HTTP/1.1
Connection: Upgrade
As noted in RFC 2817 "the protocol tokens listed in the Upgrade
header of a 101 Switching Protocols response specify an ordered
'bottom-up' stack."
See Section 3 of RFC 2817[2].
Burdis Expires August 24, 2001 [Page 8]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
5.3 Client Requires Upgrade
A client indicates that an unsecured response would be unacceptable
and that it is MANDATORY for the server to switch to one of the
specified protocols by sending an OPTIONS request first. Example:
OPTIONS * HTTP/1.1
Host: topsecret.example.com
Upgrade: SASL+SRP-SHA-160/1.0 U1JQ...UAA2Zvbw==, SASL+DIGEST-MD5/1.0
Connection: Upgrade
If the server supports HTTP over SASL with one of the specified
mechanisms it responds with a "101 Switching Protocols" status code,
indicating the chosen mechanism using a token in the Upgrade header
field:
HTTP/1.1 101 Switching Protocols
Upgrade: SASL+SRP-SHA-160/1.0, HTTP/1.1
Connection: Upgrade
See Section 3 of RFC 2817[2].
5.4 Server Requires Upgrade
A server uses a "426 Upgrade Required" status code to indicate that
an SASL session must be established using one of the listed
mechanisms before the request will be processed.
For example, the client sends:
GET http://topsecret.example.com/classified.html HTTP/1.1
Host topsecret.example.com
The server responds with:
HTTP/1.1 426 Upgrade Required
Upgrade: SASL+SRP-SHA-160/1.0, SASL+DIGEST-MD5/1.0
Connection: Upgrade
If the client supports HTTP over SASL using any of the listed
mechanisms it indicates this by resending the request and including
Burdis Expires August 24, 2001 [Page 9]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
an Upgrade header field that contains the list of mechanisms it
supports:
GET http://topsecret.example.com/classified.html HTTP/1.1
Host topsecret.example.com
Upgrade: SASL+SRP-SHA-160/1.0 U1JQ...UAA2Zvbw==
Connection: Upgrade
To which the server responds with a "101 Switching Protocols" status
code, including an Upgrade header field containing a token
specifying the protocol that is being switched to:
HTTP/1.1 101 Switching Protocols
Upgrade: SASL+SRP-SHA-160/1.0, HTTP/1.1
Connection: Upgrade
See Section 4 of RFC 2817[2].
Burdis Expires August 24, 2001 [Page 10]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
6. Discussion
The benefit of tunnelling HTTP through an SASL connection, rather
than making the SASL exchange part of HTTP, is that the TCP
connection is protected. This means that the entire HTTP message is
protected when transmitted along this connection rather than just
the HTTP body. Also, as with TLS, once the upgrade has taken place,
the HTTP protocol exchanges continue unaware that they are being
protected.
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.
Section 5 of RFC 2817[2] should be consulted for details on
establishing a secure tunnel through a proxy.
Burdis Expires August 24, 2001 [Page 11]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
7. Security Considerations
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.
It is possible for an attacker to remove the Upgrade header field
from an HTTP message. If an unsecured response is unacceptable to
the client or the server, and no Upgrade header is present, then the
exchange MUST be aborted.
It is also possible for an attacker to remove any of the mechanisms
from the list advertised by the server, so the server MUST only
advertise mechanisms that it deems to have an acceptable level of
security. The client and server MUST only select mechanisms that
they deem to have an acceptable level of security. If no such
mechanism is available then the upgrade MUST be aborted.
The security of using SASL depends on the specific SASL mechanism
chosen. Documents defining these mechanisms should be consulted. RFC
2222[6] discusses some of the security issues related to SASL
mechanisms.
Section 8 of RFC 2817[2] discusses the security implications of
using the HTTP/1.1 Upgrade header field.
Burdis Expires August 24, 2001 [Page 12]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
8. Acknowledgements
The following people provided valuable feedback in the preparation
of this document:
Raif Naffah <raif@forge.com.au>
Burdis Expires August 24, 2001 [Page 13]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 0014, RFC 2119, March 1997.
[2] Khare, R. and S. Lawrence, "HTTP Upgrade to TLS", RFC 2817, May
2000.
[3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] Dierks, T. and C. Allen, "The TLS Protocol - Version 1", RFC
2246, January 1999.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2068, June 1999.
[6] Myers, J.G., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[7] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
Author's Address
K.R. Burdis
None
42 Villa Street
Pretoria 0001
ZA
EMail: keith@rucus.ru.ac.za
URI: http://www.cryptix.org/~keith/
Burdis Expires August 24, 2001 [Page 14]
Internet-Draft Upgrading to SASL Within HTTP/1.1 February 2001
Full Copyright Statement
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
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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Burdis Expires August 24, 2001 [Page 15]
