[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12                        
INTERNET-DRAFT                                            Magnus Nystrom
November, 2002                                              RSA Security
Expires: May, 2003                                       Alexey Melnikov
Intended category: Standards track         ACI WorldWide/MessagingDirect
                                                       Robert Zuccherato
                                                           Entrust, Inc.


                            SASL in HTTP/1.1

                     draft-nystrom-http-sasl-05.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 (2002). 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: May 2003           FORMFEED[Page 1]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   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.3 Usage model .............................................. 7
   4.3.1 SASL handshake initiation .............................. 7
   4.3.2 Client response ........................................ 8
   4.3.3 Server behaviour upon receiving a "SASL" <auth-scheme>
         token .................................................. 8
   4.3.4 Final part of handshake ................................ 9
   4.3.5 Subsequent requests .................................... 9
   4.3.6 Example sequence diagram .............................. 10
   4.3.7 Pipelining considerations ............................. 10
   4.3.8 Proxy considerations .................................. 11
   4.3.9 "Web farm" considerations ............................. 11
   4.3.10 Other considerations ................................. 11
   4.4 Request/response encoding ............................... 11
   4.4.1 SASL challenge/response encoding ...................... 11
   4.4.2 Security layer......................................... 12
   4.4.3 Interaction with TLS....................................12
   4.5 Error handling .......................................... 13
   4.5.1 Client errors ......................................... 13
   4.5.2 Server errors ......................................... 13
   4.6 Authorization identity .................................. 13
   4.7 Examples ................................................ 14
   4.7.1 Example 1 - Server requires authentication ............ 14
   4.7.2 Example 2 - Initial response .......................... 15
   4.7.3 Example 3 - One mechanism only ........................ 15
   4.7.4 Example 4 - Server additional data .................... 17
   4.7.5 Example 5 - Abort ..................................... 17
   4.7.6 Example 6 - Client requires authentication............. 18
   4.8 Interoperability with existing HTTP/1.1 clients and
       servers ................................................. 19
   4.9 Preferences ............................................. 19
   5  IANA considerations ...................................... 20
   5.1 GSSAPI/SASL service name ................................ 20
   6  Security considerations .................................. 20
   6.1 Introduction ............................................ 20
   6.2 Active attacks .......................................... 20
   6.2.1 Man-in-the-middle ..................................... 20



Nystrom et al.              Expires: May 2003           FORMFEED[Page 2]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   6.2.2 Denial of service ..................................... 21
   6.2.3 Replay ................................................ 21
   6.3 Passive attacks ......................................... 21
   6.4 Other considerations .................................... 21
   7  Acknowledgements ......................................... 22
   8  Copyright ................................................ 22
   9  References ............................................... 22
   9.1 Normative references .................................... 22
   9.2 Informative references .................................. 23
   10  Authors' addresses ...................................... 23

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 and
   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.

   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.

   This memo suggests a method to use SASL in HTTP/1.1 and solicit
   comments on the suggested approach.

   <<Editorial comments are in angle brackets, like this.  See also
   appendix B for the list of major Open Issues>>.






Nystrom et al.              Expires: May 2003           FORMFEED[Page 3]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


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: May 2003           FORMFEED[Page 4]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


 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" <auth-scheme>, 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: May 2003           FORMFEED[Page 5]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   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 <sasl-mechanisms> 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: May 2003           FORMFEED[Page 6]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


     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" <auth-scheme> token).

   sasl-credentials
     Base64-encoded credentials in accordance with a selected SASL
     mechanism. MUST be sent if a <sasl-challenge> directive has been
     received by the client.

 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" <auth-scheme>.

   The server MUST list all supported and acceptable SASL mechanisms in
   the <sasl-mechanisms> directive. If the server only supports one SASL
   mechanism, it MAY include a <sasl-challenge> directive in order to
   reduce the number of roundtrips (see the example in Section 4.7.3).
   The server MUST include a <sasl-sid> directive to identify the secure
   session being negotiated.  This value MUST be the same for all
   messages associated with that session. Multiple <sasl-sid> directives
   MUST NOT be mixed on the same connection. Further, the server MUST
   include a <realm> directive in accordance with [RFC2617], 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
   <sasl-credential> directive with a "SASL" <auth-scheme> token in an
   Authorization (or Proxy-Authorization) header 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



Nystrom et al.              Expires: May 2003           FORMFEED[Page 7]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   information about the realm in question), c.f. the "initial response"
   in [RFC2222] (see the example in Section 4.7.2). In this situation
   the client MUST include a <sasl-mechanism> directive identifying the
   used SASL mechanism, but MUST NOT include a <sasl-sid> directive
   (session identifiers are to be chosen by servers).

   If the client requires authentication, it MUST issue OPTION request
   that includes Request-URI for the desired resource. This allows to
   query which SASL mechanisms are supported by the server for the
   requested resource.

  4.3.2 Client response

   A client, which receives a "SASL" <auth-scheme> 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 respond with an
   Authorization (Proxy-Authorization) header containing a "SASL" <auth-
   scheme> token with the chosen SASL mechanism in a <sasl-mechanism>
   directive in its next request. If the chosen mechanism allows for
   "initial response" type messages, the client MUST include the initial
   response in a <sasl-credential> directive in its request.  The client
   MUST also return the <sasl-sid> value provided by the server.

   If the client is able and willing to negotiate integrity and/or
   privacy protection, it MUST establish an end-to-end tunnel using the
   CONNECT method as described in section 5.3 of [RFC2817]. The CONNECT
   request MUST include Authorization (Proxy-Authorization) header as
   described in the previous paragraph.

  4.3.3 Server behaviour upon receiving a "SASL" <auth-scheme> token

   The server (proxy), upon receiving an authorization request
   containing a "SASL" <auth-scheme> token with a <sasl-credential>
   directive, checks if the client is authenticated.  If the client is
   not authenticated, the server responds with a 401 - Unauthorized (407
   - Proxy Authentication Required) response containing a (possibly new)
   <sasl-challenge> directive with a "SASL" <auth-scheme> authentication
   response token in a WWW-Authenticate (or Proxy-Authenticate) header.
   The server MAY also choose to not include the <sasl-challenge>
   directive, in which case the client shall interpret the response in
   accordance with Section 10.4.2 of [RFC2616].

   If the client is authenticated, the server MUST at least include the
   <sasl-sid> directive with its "SASL" <auth-scheme> authentication
   response token. If the chosen SASL mechanism requires that further
   challenge/response data (e.g. the final part of a three-way
   handshake) be sent by the server, the server MUST respond with a 401



Nystrom et al.              Expires: May 2003           FORMFEED[Page 8]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   - Unauthorized (407 - Proxy Authentication Required) response
   containing also a <sasl-credential> directive with its "SASL" <auth-
   scheme> authentication response token in a WWW-Authenticate (or
   Proxy-Authenticate) header. The client MUST reply to this with the
   original authorization request if any containing just a <sasl-sid>
   directive (using the value for provided by the server).  (<<What
   about POST requests?>>) If the client is authenticated and the server
   does not need to send any further challenge information, the server
   MUST respond with the requested message-body, protected by the
   negotiated security session (see Section 4.4), but including a WWW-
   Authenticate (or Proxy-Authenticate) header containing a "SASL"
   <auth-scheme> token. In this situation, no <sasl-credential>, <sasl-
   challenge> or <sasl-mechanisms> directive shall be present in the
   <auth-param> field.

   The presence of the WWW-Authenticate (or Proxy-Authenticate) header
   containing a "SASL" <auth-scheme> token and a <sasl-credential>
   directive with an authentication response on a message that is not a
   401 - Unauthorized (407 - Proxy Authentication Required) response
   indicates successful authentication of the client.

  4.3.4 Final part of handshake

   The client, upon receiving a "SASL" <auth-scheme> authentication
   response and a <sasl-challenge> directive in a WWW-Authenticate
   (Proxy-Authenticate) header for a 401 - Unauthorized (407 - Proxy
   Authentication Required) response, calculates its credentials and
   responds with a new request containing a <sasl-credential> directive
   and a "SASL" <auth-scheme> token in an Authorization (Proxy-
   Authorization) header.  If a WWW-Authenticate (Proxy-Authenticate)
   header is received on a message that is not a 401 - Unauthorized (407
   - Proxy Authentication Required) response, no further credentials are
   required.

  4.3.5 Subsequent requests

   When making any further requests within the given realm, the client
   SHOULD include a "SASL" <auth-scheme> authorization request in an
   Authorization (Proxy-Authorization) header that does not contain a
   <sasl-credential> directive.  The client MUST include the <sasl-sid>
   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 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 security layer is established



Nystrom et al.              Expires: May 2003           FORMFEED[Page 9]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   (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.

   <<Should the server remember all realms where the client is
   authenticated?>>

  4.3.6 Example sequence diagram

   Client                                              Server

   ----------------- Initial Request ----------------------->

   <------ 401 WWW-Authenticate SASL (mechanisms,realm,id) --

   --- Authorization (mechanism,id) ------------------------>

   <------ 401 WWW-Authenticate SASL (id,challenge) ---------

   --- Authorization (id,credential) ----------------------->

    <------ 401 WWW-Authenticate SASL (id,credential) --------

   --- Authorization (id,credential) ----------------------->

   (0 or more times depending on the SASL mechanism)

   <------ 200 WWW-Authenticate SASL (id) -------------------

   Subsquent 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
   pipelining until any on-going authentication exchanges are completed
   (whether successful or not).

   Server MUST process all received requests before replying to a SASL
   exchange initiation.




Nystrom et al.              Expires: May 2003          FORMFEED[Page 10]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   Clients MAY put multiple HTTP requests inside a single SASL block
   when a SASL security layer has been negotiated.

  4.3.8 Proxy 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-cache" and "Pragma: no-cache" (for compatibility with older proxy
   servers) together with an "Authorization:" header in all intermediate
   request. For the same reason, the server MUST send a "Cache-Control:
   no-cache" 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 <sasl-credential> and including <sasl-sid> of the
   authentication exchange being cancelled. If the server receives such
   a request, it MUST reject the exchange with a 401 - Unauthorized
   reply. After this, both the client and the server MUST return to
   their previous state.

   There MUST NOT be more than one WWW-Authenticate or Proxy-
   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 <sasl-challenge> directive and the <sasl-credential> 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



Nystrom et al.              Expires: May 2003          FORMFEED[Page 11]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   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 <message-body>
   that concludes the authentication exchange for the client, and the
   Status-Line of the success reply 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

   <<Order of SASL/TLS security layers. Should they be both allowed at
   the same time?>>
































Nystrom et al.              Expires: May 2003          FORMFEED[Page 12]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


 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 - 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.

  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.
   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: May 2003          FORMFEED[Page 13]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


 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 <sasl-credential> directive. The server then
   issues a <sasl-challenge> directive back to the client which once
   again responds with a <sasl-credential> directive in the
   Authorization header field.

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Host: classified.example.com

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        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-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 mechanism="CRAM-MD5",
                 id="jfkasdgru42705"

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 id="jfkasdgru42705",
                 challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
                           Lm1jaS5uZXQ+

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 id="jfkasdgru42705",
                 credential=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
                            zODkw



Nystrom et al.              Expires: May 2003          FORMFEED[Page 14]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


     S: HTTP/1.1 200 OK
        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 <sasl-credential>
   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-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 mechanism="SECURID",
                 credential=AG1hZ251cwAxMjM0NTY3OAA=

     S: HTTP/1.1 200 OK
        Cache-Control: no-cache
        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-cache
        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-cache
        Pragma: no-cache
        Host: classified.example.com



Nystrom et al.              Expires: May 2003          FORMFEED[Page 15]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


        Authorization: SASL
                 id="jfkasdgru42705",
                 credential=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
                            zODkw

     S: HTTP/1.1 200 OK
        WWW-Authenticate: SASL
                 id="jfkasdgru42705"
        ...Requested Document follows...

  4.7.4 Example 4 - Server 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 integrity protection enabled.

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Host: classified.example.com

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        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
        Authorization: SASL
                 mechanism="DIGEST-MD5",
                 id="0001"

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 id="0001",
                 challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
                           PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
                           cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache



Nystrom et al.              Expires: May 2003          FORMFEED[Page 16]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 id="0001",
                 credential=Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJ
                            lYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT
                            0iT0E2TUc5dEVRR20yaGgiLG5jPTAwMDAwMDAxLGNub
                            25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9
                            ImltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9
                            uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxND
                            NhZjcscW9wPWF1dGg=

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 id="0001",
                 credential=cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM
                            4YzkyMjcyNQ==

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 id="0001"

     S: HTTP/1.1 200 OK
    SP: WWW-Authenticate: SASL
                 id="0001"
        ...Requested Document follows...

    CP: ...Any subsequent request for a data in the same authentication
   realm...

  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

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 mechanisms="DIGEST-MD5,GSSAPI,CRAM-MD5",
                 realm="testrealm@example.com",
                 id="0001"



Nystrom et al.              Expires: May 2003          FORMFEED[Page 17]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 mechanism="DIGEST-MD5",
                 id="0001"

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 id="0001",
                 challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNl
                           PSJPQTZNRzl0RVFHbTJoaCIscW9wPSJhdXRoIixhbGdv
                           cml0aG09bWQ1LXNlc3MsY2hhcnNldD11dGYtOA==

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 id="0001",
                 credential=*

     S: HTTP/1.1 401 Authentication Canceled

  4.7.6 Example 6 - Client requires authentication

   The following example is almost identical to the 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-cache
        WWW-Authenticate: SASL
                 mechanism="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-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 mechanism="CRAM-MD5",



Nystrom et al.              Expires: May 2003          FORMFEED[Page 18]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


                 id="jfkasdgru42705"

     S: HTTP/1.1 401 Unauthorized
        Cache-Control: no-cache
        WWW-Authenticate: SASL
                 id="jfkasdgru42705",
                 challenge=PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9u
                           Lm1jaS5uZXQ+

     C: GET http://classified.example.com/classified.html HTTP/1.1
        Cache-Control: no-cache
        Pragma: no-cache
        Host: classified.example.com
        Authorization: SASL
                 id="jfkasdgru42705",
                 credential=dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQ
                            zODkw

     S: HTTP/1.1 200 OK
        WWW-Authenticate: SASL
                 id="jfkasdgru42705"
        ...Requested Document follows...

 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 <sasl-credential>
   directive with a "SASL" <auth-scheme> 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
   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" <auth-scheme> token in a WWW-
   Authenticate or Proxy-Authenticate header field, if these
   authentication methods are acceptable to the server. This ensures
   proper interworking with clients only capable of performing a "Basic"
   or "Digest Access" authentication. 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]).

 4.9 Preferences

   Servers MUST list authentication mechanisms in WWW-Authenticate
   (Proxy-Authenticate) header field in preferred order.




Nystrom et al.              Expires: May 2003          FORMFEED[Page 19]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


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" <auth-scheme> message where A is a "strong" mechanism (for
   some definition of "strong") but B and C are "weak" or provide fewer
   security attributes than A, then an attacker could simply remove A
   from the list.  This 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 <auth-scheme> token may be removed from the WWW-
   Authenticate (Proxy-Authenticate) header, thus forcing use of either
   the Basic or Digest Access method.  For this reason, 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



Nystrom et al.              Expires: May 2003          FORMFEED[Page 20]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   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-cache" 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: May 2003          FORMFEED[Page 21]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


7  Acknowledgements

   Text for Section 4.6 was borrowed from [RFC2829]. Thanks to Keith
   Burdis and Raif S. Naffah for providing useful feedback and
   suggestions.

8  Copyright

   Copyright (C) The Internet Society (2002). 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: May 2003          FORMFEED[Page 22]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


   [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
   22 The Quadrant,
   Richmond, Surrey,
   United Kingdom, TW9 1BP

   Robert Zuccherato               Email: robert.zuccherato@entrust.com
   Entrust, Inc.
   1000 Innovation Drive
   Ottawa, Ontario
   Canada, K2K 3E7







Nystrom et al.              Expires: May 2003          FORMFEED[Page 23]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


Appendix A. Changes since previous revisions

 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.

   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.



Nystrom et al.              Expires: May 2003          FORMFEED[Page 24]


INTERNET DRAFT              SASL in HTTP/1.1               November 2002


Appendix B. Major Open Issues

   401 vs. new 1xx response code for authentication

   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
   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: May 2003          FORMFEED[Page 25]