INTERNET-DRAFT Magnus Nystrom February, 2001 RSA Security Expires: August 2001 Robert Zuccherato Intended category: Standards track Entrust Technologies SASL in http/1.1 draft-nystrom-http-sasl-00.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: August 2001 [Page 1] INTERNET DRAFT SASL in http/1.1 February 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. <>. 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: August 2001 [Page 2] INTERNET DRAFT SASL in http/1.1 February 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: August 2001 [Page 3] INTERNET DRAFT SASL in http/1.1 February 2001 sasl-parameter = sasl-mechanism | sasl-sid | realm | sasl-challenge | sasl-credential ; Note: realm is defined in [RFC2617] sasl-mechanism = "mechanism" "=" quoted-string ; Name must be from IANA set of registered SASL mechanisms, ; e.g. "SECURID" sasl-sid = "id" "=" 8*quoted-string sasl-challenge = "challenge" "=" base64-string sasl-credential = "credential" "=" quoted-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 value in a WWW- Authenticate (or Proxy-Authenticate) header field. The server MUST list all supported and acceptable SASL mechanisms in directives. If the server only supports one SASL mechanism, it MAY include a directive in order to reduce the number of roundtrips. The server MUST include a directive to identify the secure session being negotiated. This value MUST be the same for all messages associated with that session. Further, the server MUST include a directive in accordance with [RFC2617]. Only one directive must be sent. 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 directive in a 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 Nystrom & Zuccherato Expires: August 2001 [Page 4] INTERNET DRAFT SASL in http/1.1 February 2001 a directive to identify the secure session being negotiated. This value MUST be the same for all messages associated with that session. Only one directive must be sent. Note: C.f. the "initial response" in [RFC2222]. 4.3.2 Client response A client, which receives a 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 directive in a 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 value in the corresponding field of . 4.3.3 Server behaviour upon receiving a The server (proxy), upon receiving a value containing a 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) directive in a in a WWW-Authenticate (or Proxy-Authenticate) header. The server MAY also choose to not include the 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 SHOULD respond with the requested message-body, possibly protected by the negotiated security session (see Section 4.4), but including a WWW- Authenticate (or Proxy-Authenticate) header containing a directive in the token. Alternatively, it can respond with a 401 - Unauthenticated (407 - Proxy Authentication Required) response containing a directive in a in a WWW-Authenticate (or Proxy-Authenticate) header. 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, possibly protected by the negotiated security session (see Section 4.4), but including a WWW-Authenticate (or Proxy-Authenticate) header containing a . In this situation, no , or directive shall be present. In all cases, the server MUST also return the value in the corresponding field. Nystrom & Zuccherato Expires: August 2001 [Page 5] INTERNET DRAFT SASL in http/1.1 February 2001 The presence of the WWW-Authenticate (or Proxy-Authenticate) header containing a directive in a 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 directive in a 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 directive in a 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 in an Authorization (Proxy-Authorization) header that does not contain a directive. The request MAY be protected by the negotiated security session (see Section 4.4). In all cases, the client MUST also return the value in the corresponding field of . 4.3.5 Other considerations Clients MAY abort exchanges at any time, e.g. by using the "Connection: close" header. There MUST NOT be more than one WWW-Authenticate or Proxy- Authenticate field containing a in a respone. There MUST NOT be more than one Authorization or Proxy-Authorization header field containing a in a request. 4.4 Header and Message Encoding The directive and the directive contains SASL challenges and responses. The challenges and responses MUST be base64 [RFC2045] encoded before being placed in these fields. <> If a protection mechanism is negotiated as part of the SASL security Nystrom & Zuccherato Expires: August 2001 [Page 6] INTERNET DRAFT SASL in http/1.1 February 2001 session, then it SHOULD be applied to all subsequent data sent between the server and client. The protection takes effect immediately following the CRLF that separates the 's from the . In addition, certain headers that contain sensitive information SHOULD be protected. In this case, the protection takes effect immediately following the CRLF that separates the header from the previous header or immediately following the , if it is the first header in the HTTP message. Protection ends immediately preceeding the CRLF separating the header from the next header or the . The WWW-Authenticate (Proxy-Authenticate) and Authorization (Proxy-Authorization) headers MUST NOT be protected. The protected message body and/or headers MUST be contained in an HTTP message having either a or directive in a in the appropriate header with the corresponding value. The directive MUST NOT be present unless being sent from the server to the client as the final message in session negotiation. (See Section 4.3.3) Protected 's and 's MUST be base64 encoded. 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 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. Nystrom & Zuccherato Expires: August 2001 [Page 7] INTERNET DRAFT SASL in http/1.1 February 2001 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 directive. The server then issues a directive back to the client which once again responds with a directive in the Authorization header field. 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 directive in its Authorization header. The server accepts the credentials and responds with the requested information. Nystrom & Zuccherato Expires: August 2001 [Page 8] INTERNET DRAFT SASL in http/1.1 February 2001 4.8 Interoperability with existing http/1.1 clients and servers A client supporting SASL-based authentication MUST NOT include a directive in a 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 capacities 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" 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 A client supporting both the "Basic", "Digest Access", and some SASL- based authentication mechanisms MUST choose the first supported mechanism it encounters in the first WWW-Authenticate (Proxy- Authenticate) header field it encounters in the server's response. Servers MUST therefore list authentication mechanisms in preferred order. 4.10 Other considerations <> 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 message where A is a "strong" mechanism (for some definition of Nystrom & Zuccherato Expires: August 2001 [Page 9] INTERNET DRAFT SASL in http/1.1 February 2001 "strong") but B and C are "weak" or provide fewer security attributes than A, then an attacker could simply remove A from the list. This forces the client to choose a "weaker" mechanism and neither side will 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 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 6.3 Other considerations 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 Nystrom & Zuccherato Expires: August 2001 [Page 10] INTERNET DRAFT SASL in http/1.1 February 2001 "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 [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 Nystrom & Zuccherato Expires: August 2001 [Page 11] INTERNET DRAFT SASL in http/1.1 February 2001 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7 Phone: +1 613 270 2598 Email: robert.zuccherato@entrust.com Nystrom & Zuccherato Expires: August 2001 [Page 12]