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+/ [ ] where: is a valid SASL mechanism name is the optional base64-encoded initial response 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 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]