INTERNET-DRAFT Magnus Nystrom February, 2003 RSA Security Expires: August, 2003 Alexey Melnikov Intended category: Standards track ACI WorldWide/MessagingDirect Robert Zuccherato Entrust, Inc. SASL in HTTP/1.1 draft-nystrom-http-sasl-06.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 (2003). 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: August 2003 FORMFEED[Page 1] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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.2.4 New Expect header value used for authentication ........ 7 4.3 Usage model .............................................. 7 4.3.1 SASL handshake initiation .............................. 7 4.3.2 Client response ........................................ 8 4.3.3 Server behavior upon receiving a "SASL" token .................................................. 9 4.3.4 Final part of handshake ............................... 11 4.3.5 Subsequent requests ................................... 11 4.3.6 Example sequence diagram .............................. 12 4.3.7 Pipelining considerations ............................. 12 4.3.8 Caching considerations................................. 13 4.3.9 "Web farm" considerations ............................. 13 4.3.10 Other considerations ................................. 13 4.4 Request/response encoding ............................... 14 4.4.1 SASL challenge/response encoding ...................... 14 4.4.2 Security layer......................................... 14 4.4.3 Interaction with TLS....................................14 4.5 Error handling .......................................... 15 4.5.1 Client errors ......................................... 15 4.5.2 Server errors ......................................... 16 4.6 Authorization identity .................................. 16 4.7 Examples ................................................ 17 4.7.1 Example 1 - Server requires authentication ............ 17 4.7.2 Example 2 - Initial response .......................... 18 4.7.3 Example 3 - One mechanism only ........................ 19 4.7.4 Example 4 - Server sends additional data .............. 20 4.7.5 Example 5 - Abort ..................................... 21 4.7.6 Example 6 - Client requires authentication ............ 22 4.7.7 Example 7 - Client uses POST request .................. 24 4.8 Interoperability with existing HTTP/1.1 clients and servers ................................................. 25 4.9 Preferences ............................................. 26 5 IANA considerations ...................................... 26 5.1 GSSAPI/SASL service name ................................ 26 6 Security considerations .................................. 26 6.1 Introduction ............................................ 26 Nystrom et al. Expires: August 2003 FORMFEED[Page 2] INTERNET DRAFT SASL in HTTP/1.1 February 2003 6.2 Active attacks .......................................... 26 6.2.1 Man-in-the-middle ..................................... 26 6.2.2 Denial of service ..................................... 27 6.2.3 Replay ................................................ 27 6.3 Passive attacks ......................................... 27 6.4 Other considerations .................................... 27 7 Acknowledgements ......................................... 28 8 Copyright ................................................ 28 9 References ............................................... 28 9.1 Normative references .................................... 28 9.2 Informative references .................................. 29 10 Authors' addresses ...................................... 29 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]." Neither of these can be considered to be strong authentication schemes. The former is extremely insecure unless used in conjunction with a lower-level protocol offering security services, since it sends cleartext passwords. The latter is an improvement, but is still vulnerable to man-in-the-middle attacks. 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 (e.g. those based on one-time-passwords, public key technology or password- based public-key cryptography) 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. This memo suggests a method to use SASL in HTTP/1.1 and solicit comments on the suggested approach. <>. Nystrom et al. Expires: August 2003 FORMFEED[Page 3] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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 requires 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 1*SP 1#auth-param The response will be found in an Authorization or a Proxy- Authorization header field. Nystrom et al. Expires: August 2003 FORMFEED[Page 4] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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" , 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 <"> 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 Note: All directives ("mechanism", "id", "realm", "challenge", etc.) are case-insensitive. All directive values are case-sensitive. Nystrom et al. Expires: August 2003 FORMFEED[Page 5] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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 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] sasl-mechanism = "mechanism" "=" <"> sasl-mech-name <"> The meanings of the values of the directives used above are as follows: sasl-mechanism A SASL mechanism acceptable to the client, chosen from the list Nystrom et al. Expires: August 2003 FORMFEED[Page 6] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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" token). sasl-credentials Base64-encoded credentials in accordance with a selected SASL mechanism. MUST be sent if a directive has been received by the client. 4.2.4 New Expect header value used for authentication The new value "102-continue" of the Expect header is introduced by this document and is used solely for SASL authentication. It allows the client to perform authentication exchange without the need to send the body of the message with each request. expectation-extension =/ expect-sasl-exchange expect-sasl-exchange = "102-continue" ;; this conforms to the syntax ;; of expectation-extension 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" . The server MUST list all supported and acceptable SASL mechanisms in the directive. If the server only supports one SASL mechanism, it MAY include a directive in order to reduce the number of roundtrips (see the example in Section 4.7.3). The server MUST include a directive to identify the secure session being negotiated. This value MUST be the same for all Nystrom et al. Expires: August 2003 FORMFEED[Page 7] INTERNET DRAFT SASL in HTTP/1.1 February 2003 messages associated with that session. Multiple directives MUST NOT be mixed on the same connection. However, there is one exception to this rule. If the client starts authentication exchange with the target server and than a proxy server asks the client to authenticate, than the client must perform authentication exchange to the proxy first and than resume authentication to the end server. Further, the server MUST include a 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 a "SASL" token in an Authorization (or Proxy- Authorization) header field in its request. If the client chooses to do so, it MUST include a directive identifying the used SASL mechanism, but MUST NOT include a directive, as session identifiers are chosen by the server. If the chosen SASL mechanism requires that the client sends data first, the client MUST also include a directive, c.f. the "initial response" in [RFC2222] (see the example in Section 4.7.2). This minimizes the number of roundtrips, otherwise the server would be required to send an empty challenge. If the client requires authentication, but doesn't know which mechanisms are supported by the server, the client MUST issue an OPTION request that includes a Request-URI header for the desired resource and Authorization (or Proxy-Authorization) header field containing "SASL" token that is not followed by any sasl-request-parameters. This provides a way for the client to query the server about supported SASL mechanisms for the requested resource. After the request the session continues as if the server initiated an authentication exchange. 4.3.2 Client response A client, which receives a "SASL" 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 construct a new request as described below. This request MAY contain the headers from the original request (except for Content-Length which should be either removed or be 0), MUST contain Authorization (Proxy-Authorization) header containing a "SASL" token and MUST NOT contain the body of the original request (if any). We will reference any such request as a "SASL request". The "SASL" token MUST include value provided by the server and Nystrom et al. Expires: August 2003 FORMFEED[Page 8] INTERNET DRAFT SASL in HTTP/1.1 February 2003 directive with the chosen SASL mechanism name. If the chosen mechanism allows for "initial response" type messages, the client MUST also include the initial response in a directive. Note that unless noted otherwise, all authentication requests sent by the client MUST include "Expect: 102-continue" header as described in 4.2.4, unless the client knows that the authentication exchange is complete (successfully or not). The client MAY also include "Cache- Control: no-store" and "Pragma: no-cache" as described in 4.3.8. If the client is able and willing to negotiate a SASL security layer, it MUST establish an end-to-end tunnel using the CONNECT method as described in section 5.3 of [RFC2817] before starting an authentication exchange. The Authorization header MUST NOT be used in a CONNECT request. However, in order to save round trips, Proxy- Authorization header MAY be used in a CONNECT request. 4.3.3 Server behavior upon receiving a "SASL" token The server (proxy), upon receiving an authorization request containing a "SASL" token with a directive, checks if it supports/accept the authentication mechanism. If the provided mechanism is not supported or accepted, the server MUST reply with 406 - Not Acceptable response. The server (proxy), upon receiving an authorization request containing a "SASL" token with a directive, checks if the client is authenticated. If the client is not authenticated, the server responds with a 102 - Authentication Required (407 - Proxy Authentication Required) response containing a new directive with a "SASL" authentication response token in a WWW-Authenticate (or Proxy- Authenticate) header. The server MAY also choose to reply with 401 - Unauthorized response that contains WWW-Authenticate (or Proxy- Authenticate) header without the directive, in which case the client shall interpret the response in accordance with Section 10.4.2 of [RFC2616]. The server MAY also choose to reply with 432 - Transition Needed response, that indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified SASL mechanism. If the client is authenticated, the server MUST at least include the directive with its "SASL" authentication response token. If the chosen SASL mechanism requires that further challenge/response data (i.e. "server returns success with additional data" in [RFC2222]) be sent by the server, the server MUST respond Nystrom et al. Expires: August 2003 FORMFEED[Page 9] INTERNET DRAFT SASL in HTTP/1.1 February 2003 with a 102 - Authentication Required (407 - Proxy Authentication Required) response containing also a directive with its "SASL" authentication response token in a WWW- Authenticate (or Proxy-Authenticate) header. Unless the server fails authentication, the client MUST reply to this with a new SASL request containing Authorization header with just a directive with the value provided by the server. The server will reply to this with 235 - Authentication Completed (236 - Proxy Authentication Completed) response and at this point authentication is complete and SASL security layer may be in effect (see Section 4.4.2). <> If the client is authenticated and the server does not need to send any further challenge information, the server replies with 235 - Authentication Completed (236 - Proxy Authentication Completed) response. Upon receipt of a 235/236 response the client shall consider authentication successful and may retry the original request (with the body of the request, if any) that would be protected by the negotiated security session (see Section 4.4.2). The client MAY include WWW-Authenticate (or Proxy-Authenticate) header containing a "SASL" token, however no , or directive shall be included. <> The presence of the WWW-Authenticate (or Proxy-Authenticate) header in a response message, that contains a "SASL" token with a directive, indicates successful authentication of the client. In particular, the presence of the WWW- Authenticate (or the Proxy-Authenticate) in a 4xx (except 401) or 5xx response indicates that the authentication was successfully completed, but the request itself failed. Nystrom et al. Expires: August 2003 FORMFEED[Page 10] INTERNET DRAFT SASL in HTTP/1.1 February 2003 <> However, the presence of the WWW-Authenticate (or Proxy-Authenticate) header with directive in a reply with status code 102 - Authentication Required, 401 - Unauthorized or 407 - Proxy Authentication Required is a silly state and must be treated as a server error by the client. <> 4.3.4 Final part of handshake The client, upon receipt of a 432 - Transition Needed response, MAY retry authentication using SASL PLAIN mechanism. This SHOULD be done with appropriate TLS protection in place. An interactive client MUST not perform PLAIN authentication automatically and MUST warn the user before proceeding. The client, upon receipt of a "SASL" authentication response and a directive in a WWW-Authenticate (Proxy-Authenticate) header for a 102 - Authentication Required (407 - Proxy Authentication Required) response, calculates its credentials and responds with a new SASL request containing a directive and 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 102 - Authentication Required (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" authorization request in an Authorization (Proxy-Authorization) header that does not contain a directive. The client MUST include the directive in the SASL authorization requests. The same HTTP server may serve data governed by multiple realms that may have separate associated authentication databases. If the client left the authentication realm it was originally authenticated in, the server may force the client to re-authenticate in the new realm. In this case a new authentication exchange is started as described in 4.3.1. However there is a change in how the security layer is established (see section 4.4.2). If a security layer is currently active and the new authentication exchange negotiate no security layer, the current security layer MUST NOT be removed. However, if a new security layer is negotiated, it MUST replace the existing one. Nystrom et al. Expires: August 2003 FORMFEED[Page 11] INTERNET DRAFT SASL in HTTP/1.1 February 2003 <> <> 4.3.6 Example sequence diagram Client Server ----------------- Initial Request -----------------------> <------ 401 WWW-Authenticate SASL (mechanisms,realm,id) -- --- Authorization (mechanism,id),Expect (102-continue) --> <------ 102 WWW-Authenticate SASL (id,challenge) --------- --- Authorization (id,credential),Expect (102-continue) -> <------ 102 WWW-Authenticate SASL (id,credential) -------- --- Authorization (id,credential),Expect (102-continue) -> (0 or more times depending on the SASL mechanism) <------ 235 WWW-Authenticate SASL (id) ------------------- ----------------- Initial Request (retry) ---------------> <------ 200 WWW-Authenticate SASL (id) ------------------- Subsequent 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 Nystrom et al. Expires: August 2003 FORMFEED[Page 12] INTERNET DRAFT SASL in HTTP/1.1 February 2003 pipelining until any on-going authentication exchanges are completed (whether successful or not). Clients MAY put multiple HTTP requests inside a single SASL block when a SASL security layer has been negotiated (see also section 4.4.2). 4.3.8 Caching 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-store" and "Pragma: no-cache" (for compatibility with older proxy servers) together with an "Authorization" header in all intermediate request. There are two exception to this rule: 1). the client is sending a OPTIONS/POST/PUT/DELETE request, that have non cacheable responses. 2). the client established end-to-end tunnel with CONNECT. <> For the same reason, the server MUST send a "Cache-Control: no-store" 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 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 and including of the authentication exchange being cancelled. If the server receives such a request, it MUST reject the exchange with a 401 - Unauthorized Nystrom et al. Expires: August 2003 FORMFEED[Page 13] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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 directive and the 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 that concludes the authentication exchange for the client, and the of 235/236 response 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. 4.4.3 Interaction with TLS A client may not perform an HTTP/1.1 "Upgrade" to TLS [RFC2817] while conducting a SASL negotiation, but is free to do so after, or before, the SASL negotiation takes place. This document allows for both TLS and SASL security layer to be active at the same time. No matter in which order they were negotiated, any data would be converted by SASL security layer first and than by TLS, i.e. the protocol stack would look like this Nystrom et al. Expires: August 2003 FORMFEED[Page 14] INTERNET DRAFT SASL in HTTP/1.1 February 2003 +---------+ | SASL | +---------+ | TLS | +---------+ | TCP | +---------+ 4.5 Error handling 4.5.1 Client errors HTTP/1.1 status codes which apply to SASL-based mechanisms are: -102 - Authentication Required This is a new status code introduced by this document that is used to perform SASL authentication exchange. It signifies that SASL authentication is in progress and the client is required to send more authentication data to the server. See section 4.3 for more details. -235 - Authentication Completed This status code indicates that SASL authentication with the server is complete and the client may retry sending the original request. -236 - Proxy Authentication Completed This status code indicates that SASL authentication with the proxy is complete and the client may retry sending the original request. -401 - Unauthorized An HTTP/1.1 server will use this status code when credentials supplied by a client could not be validated. -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. -432 - Transition Needed This status codes indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified SASL mechanism. This typically is done by authenticating once using the PLAIN authentication mechanism. This SHOULD be done with appropriate TLS protection in place. An interactive client MUST warn the user before proceeding with PLAIN authentication. This status code can be sent, for example if a user has an entry in Nystrom et al. Expires: August 2003 FORMFEED[Page 15] INTERNET DRAFT SASL in HTTP/1.1 February 2003 a system authentication database such as Unix /etc/passwd, but does not have credentials suitable for use by the specified mechanism. 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. (In the latter case instead of closing connection the client MAY also cancel SASL exchange by specifying "*" in as described in section 4.3.10). 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: August 2003 FORMFEED[Page 16] INTERNET DRAFT SASL in HTTP/1.1 February 2003 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 directive. The server then issues a directive back to the client which once again responds with a 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-store 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-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="CRAM-MD5", id="jfkasdgru42705" Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705", challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u Lm1jaS5uZXQ+ C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="jfkasdgru42705", credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ Nystrom et al. Expires: August 2003 FORMFEED[Page 17] INTERNET DRAFT SASL in HTTP/1.1 February 2003 zODkw S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" Client retries original request after that: C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 200 OK Cache-Control: no-store 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 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-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="SECURID", credentials=AG1hZ251cwAxMjM0NTY3OAA= Expect: 102-continue The client doesn't know if authentication is complete at this point, as certain SASL mechanisms have variable number of steps. S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 200 OK Nystrom et al. Expires: August 2003 FORMFEED[Page 18] INTERNET DRAFT SASL in HTTP/1.1 February 2003 Cache-Control: no-store 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-store 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-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="jfkasdgru42705", credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ zODkw S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 200 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" ...Requested Document follows... Nystrom et al. Expires: August 2003 FORMFEED[Page 19] INTERNET DRAFT SASL in HTTP/1.1 February 2003 4.7.4 Example 4 - Server sends 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 SASL security layer active. C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 401 Unauthorized Cache-Control: no-store 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-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="DIGEST-MD5", id="0001" Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA== C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Nystrom et al. Expires: August 2003 FORMFEED[Page 20] INTERNET DRAFT SASL in HTTP/1.1 February 2003 Authorization: SASL id="0001", credentials=Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJ lYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT 0iT0E2TUc5dEVRR20yaGgiLG5jPTAwMDAwMDAxLGNub 25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9 ImltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9 uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxND NhZjcscW9wPWF1dGg= Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="0001", credentials=cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM 4YzkyMjcyNQ== C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001" S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="0001" CP: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com SP: HTTP/1.1 200 OK WWW-Authenticate: SASL id="0001" ...Requested Document follows... CP: ...Any subsequent request for a data on the same server, unless the server requests reauthentication... 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: August 2003 FORMFEED[Page 21] INTERNET DRAFT SASL in HTTP/1.1 February 2003 S: HTTP/1.1 401 Unauthorized Cache-Control: no-store 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-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="DIGEST-MD5", id="0001" Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA== C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001", credentials=* S: HTTP/1.1 401 Authentication Canceled ... 4.7.6 Example 6 - Client requires authentication The following example is almost identical to Example 1, but here the client requires authentication to the server. C: OPTIONS http://classified.example.com/classified.html HTTP/1.1 Authorization: SASL Host: classified.example.com S: HTTP/1.1 401 Unauthorized Cache-Control: no-store WWW-Authenticate: SASL mechanism="DIGEST-MD5,GSSAPI,CRAM-MD5", Nystrom et al. Expires: August 2003 FORMFEED[Page 22] INTERNET DRAFT SASL in HTTP/1.1 February 2003 realm="testrealm@host.com", id="jfkasdgru42705" C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="CRAM-MD5", id="jfkasdgru42705" Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705", challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u Lm1jaS5uZXQ+ C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="jfkasdgru42705", credentials=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ zODkw S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" Upon receipt of a 235 response the client submits the request it originally intended to submit: C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 200 OK Cache-Control: no-store WWW-Authenticate: SASL id="jfkasdgru42705" ...Requested Document follows... Nystrom et al. Expires: August 2003 FORMFEED[Page 23] INTERNET DRAFT SASL in HTTP/1.1 February 2003 4.7.7 Example 7 - Client uses POST request In this example the client is willing to perform a POST request but the server requires authentication. In examples, "CP:" and "SP:" indicate lines sent by a client and a server respectively with SASL security layer active. C: POST http://classified.example.com/update_classified.php HTTP/1.1 Host: classified.example.com Content-Type: ... Content-Length: ... ...request body... <> S: HTTP/1.1 401 Unauthorized Cache-Control: no-store WWW-Authenticate: SASL mechanisms="DIGEST-MD5,GSSAPI,OTP", 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: POST http://classified.example.com/update_classified.php HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="OTP",id="0001",credentials=AHRpbQ== Expect: 102-continue S: HTTP/1.1 102 Authentication Required Cache-Control: no-store WWW-Authenticate: SASL id="0001",challenge=b3RwLW1kNSAxMjMga2UxMjM0IGV4dA== C: POST http://classified.example.com/update_classified.php Nystrom et al. Expires: August 2003 FORMFEED[Page 24] INTERNET DRAFT SASL in HTTP/1.1 February 2003 HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001",credentials=aGV4OjExZDRjMTQ3ZTIyN2MxZjE= S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="0001" CP: POST http://classified.example.com/update_classified.php HTTP/1.1 Host: classified.example.com Content-Type: ... Content-Length: ... ...request body... SP: HTTP/1.1 200 OK WWW-Authenticate: SASL id="0001" ...Response to POST, if any... CP: ...Any subsequent request for a data on the same server, unless the server requests reauthentication... 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 directive with a "SASL" authorization request in an Authorization or Proxy-Authorization header unless it knows that the server supports the SASL mechanism in question. The client MAY use an OPTIONS request to find out about the server's SASL capabilities. 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. 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]). Nystrom et al. Expires: August 2003 FORMFEED[Page 25] INTERNET DRAFT SASL in HTTP/1.1 February 2003 4.9 Preferences Servers MUST list authentication mechanisms in WWW-Authenticate (Proxy-Authenticate) header field in preferred order. 4.10 SASL mechanism recommendations 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. 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" 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 Nystrom et al. Expires: August 2003 FORMFEED[Page 26] INTERNET DRAFT SASL in HTTP/1.1 February 2003 from the list. This forces the client to choose a "weaker" mechanism 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 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-store" 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: August 2003 FORMFEED[Page 27] INTERNET DRAFT SASL in HTTP/1.1 February 2003 7 Acknowledgements Text for Section 4.6 was borrowed from [RFC2829]. Thanks to Keith Burdis, Raif S. Naffah, Mark Nottingham, Joe Orton and John P Speno for providing useful feedback and suggestions. 8 Copyright Copyright (C) The Internet Society (2003). 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. Nystrom et al. Expires: August 2003 FORMFEED[Page 28] INTERNET DRAFT SASL in HTTP/1.1 February 2003 [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. [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 59 Clarendon Road, Watford, Herts, United Kingdom, WD17 1FQ Robert Zuccherato Email: robert.zuccherato@entrust.com Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario Canada, K2K 3E7 Nystrom et al. Expires: August 2003 FORMFEED[Page 29] INTERNET DRAFT SASL in HTTP/1.1 February 2003 Appendix A. Changes since previous revisions Changes since -05 Replaced "Cache-Control: no-cache" with "Cache-Control: no-store" as per Mark Nottingham comment. ABNF corrections from Joe Orton and John P Speno. More corrections from Joe Orton. Changed 401 to a new status code 102 used solely for authentication. Added Transition Needed status code (432). Should check if this code conflicts with anything. Added new "Expect: 102-continue" header. Reworked section 4.3 to describe more error cases and more detailed implementation instructions. Disallow TLS Upgrade during SASL authentication (it is fine before or after). Clarified order of security layers. Clarified that Authorization header with SASL response MUST NOT be used with CONNECT. Relaxed restriction for mixing SASL session ids on the same connection in certain cases. Added new 235/236 status codes for successfully completed authentication. Clarified that the body of the original request MUST NOT be sent until authentication is complete. Updated examples to reflect that. Added an example with a POST request. Changes since -04 Reworked the Introduction section. Updated example 4.7.4 to include Authorization header in CONNECT request. This saves a round trip. Added text that the client must use OPTIONS to find out which SASL mechanisms are supported by the server. Added an example. Nystrom et al. Expires: August 2003 FORMFEED[Page 30] INTERNET DRAFT SASL in HTTP/1.1 February 2003 Added text regarding the server requiring reauthentication when the client leaves the realm it authenticated in. Some clarification about the CONNECT method. Added text that a CONNECT request should start the authentication exchange. Incorporated comments from Raif S. Naffah and Keith Burdis. Changes since -03 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. Appendix B. Major Open Issues 235/236 status codes for successful authentication. 401 vs. new 1xx response code for authentication exchange. Use "Expect" header to avoid sending request body with every authentication step for POST/PUT methods. When using a security layer, the status line should be transmitted Nystrom et al. Expires: August 2003 FORMFEED[Page 31] INTERNET DRAFT SASL in HTTP/1.1 February 2003 twice: in cleartext and in encrypted block? (Another proposal is to return 100/failure response code in the clear and the success in the encrypted block). (The following issue is actually closed, but additional information may reopen it) Persistent connection is required when negotiating a security layer. Not requiring it when a security layer is not required adds additional complexity. Not requiring persistent connections will also change how session ids are being used and when they are destroyed. Nystrom et al. Expires: August 2003 FORMFEED[Page 32]