INTERNET-DRAFT                                            Magnus Nystrom
February, 2001                                              RSA Security
Expires: August 2001                                   Robert Zuccherato
Intended category: Standards track                  Entrust Technologies

                            SASL in http/1.1

                     draft-nystrom-http-sasl-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This memo suggest the use of SASL [RFC2222] as a framework to enable
   the use of strong authentication mechanisms in http/1.1 [RFC2616],
   and defines one approach to accomplish this.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Please send comments on this document to the relevant mailing list.









Nystrom & Zuccherato      Expires: August 2001                  [Page 1]


INTERNET DRAFT              SASL in http/1.1               February 2001


1  Introduction

   The Hypertext Transfer Protocol, http/1.1 [RFC2616], supports only
   two authentication schemes, namely the "Basic Access Authentication
   Scheme" and the "Digest Access Authentication Scheme [RFC2617]." The
   former of these two cannot be considered a secure authentication
   scheme since it is based on passwords or passphrases, which
   furthermore are unprotected unless used in conjunction with a lower-
   level protocol offering security services. The latter, while
   protecting against users transmitting passwords in clear, does not
   provide a strong authentication mechanism as it is based on passwords
   or passphrases.

   The Simple Authentication and Security Layer Protocol (SASL
   [RFC2222]) provides a method for adding authentication and security
   services to connection-oriented protocols in a flexible manner,
   enabling a variety of authentication and security mechanisms to be
   used with any protocol supporting SASL.

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

   <<Editorial comments are in angle brackets, like this>>.

2  Document conventions and examples

 2.1 Conventions Used in this memo

   In examples, "C:" and "S:" indicate lines sent by a client and a
   server respectively.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [RFC2119].

 2.2 Examples

   Examples in this memo are for the http/1.1 profile of this
   specification. Encodings of challenges and responses, are part of the
   http/1.1 profile.

3  Relationship with the http/1.1 specification

   This memo relies on the http/1.1 [RFC2616] specification. As with RFC
   2617, it uses the ABNF [RFC2234] grammar of that document and relies
   on both non-terminals and other aspects of it.

   Further, this memo assumes persistent connections.



Nystrom & Zuccherato      Expires: August 2001                  [Page 2]


INTERNET DRAFT              SASL in http/1.1               February 2001


4  SASL Framework

 4.1 Http/1.1 challenge-response framework

   Http/1.1 provides a simple challenge-response mechanism that can be
   used by a server or proxy to challenge a client request and by a
   client to provide authentication information. The reader is referred
   to [RFC2616] and [RFC2617] for a more detailed description of this
   mechanism. The relevant productions are:

      challenge = auth-scheme 1*SP 1#auth-param

      auth-scheme = token

      auth-param = token "=" (token | quoted-string)

   The authentication parameter "realm" is defined for all
   authentication schemes:

      realm = "realm" "=" realm-value

      realm-value = quoted-string

   The challenge will be found in a WWW-Authenticate or a Proxy-
   Authenticate header field.

   The client response, containing the client's credentials are defined
   as follows:

      credentials = auth-scheme #auth-param

   The response will be found in an Authorization or a Proxy-
   Authorization header field.

 4.2 Supporting SASL in http/1.1 - syntax

  4.2.1 Recognition of the scheme

   The use of a SASL authentication scheme is indicated by the auth-
   scheme token "SASL". A server MUST use this auth-scheme token if it
   supports SASL and is willing to perform a SASL-based mechanism.

  4.2.2 ABNF Grammar for SASL mechanisms

   See [RFC2616] for a definition of the augmented BNF grammar.

     sasl-token      = SASL 1*SP 1#sasl-parameter




Nystrom & Zuccherato      Expires: August 2001                  [Page 3]


INTERNET DRAFT              SASL in http/1.1               February 2001


     sasl-parameter  = sasl-mechanism | sasl-sid | realm
                     | sasl-challenge | sasl-credential
        ; Note: realm is defined in [RFC2617]

     sasl-mechanism  = "mechanism" "=" quoted-string
        ; Name must be from IANA set of registered SASL mechanisms,
        ; e.g. "SECURID"

     sasl-sid        = "id" "=" 8*quoted-string

     sasl-challenge  = "challenge" "=" base64-string

     sasl-credential = "credential" "=" quoted-string

     base64-string   = *BASE64 *2"="
        ; Encoding must be in accordance with [RFC2045], except not
        ; limited to 76 chars/line

     BASE64          = DIGIT | ALPHA | "+" | "/"

   Note: All directives ("mechanism", "id", "realm", "challenge", and
   "credentials" are case-insensitive. All directive values are case-
   sensitive.

 4.3 Usage model

  4.3.1 SASL handshake initiation

   When a server, which requires SASL-based authentication, is about to
   respond with a 401 - Unauthorized (407 - Proxy Authentication
   Required) response, it SHALL include a <sasl-token> value in a WWW-
   Authenticate (or Proxy-Authenticate) header field. The server MUST
   list all supported and acceptable SASL mechanisms in <sasl-mechanism>
   directives. If the server only supports one SASL mechanism, it MAY
   include a <sasl-challenge> directive in order to reduce the number of
   roundtrips.  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. Further, the
   server MUST include a <realm> directive in accordance with [RFC2617].
   Only one <sasl-sid> directive must be sent.

   A client, which is about to issue a request to a server, and knows
   that the server requires a certain SASL mechanism, MAY include a
   <sasl-credential> directive in a <sasl-token> in an Authorization (or
   Proxy-Authorization) field in its request. This is useful to minimize
   the number of roundtrips when a server does not explicitly have to
   send the client a challenge (or information about the realm in
   question).  In this situation the client MUST also include a value in



Nystrom & Zuccherato      Expires: August 2001                  [Page 4]


INTERNET DRAFT              SASL in http/1.1               February 2001


   a <sasl-sid> directive to identify the secure session being
   negotiated.  This value MUST be the same for all messages associated
   with that session. Only one <sasl-sid> directive must be sent.

   Note: C.f. the "initial response" in [RFC2222].

  4.3.2 Client response

   A client, which receives a <sasl-token> value in a WWW-Authenticate
   (Proxy-Authenticate) header in a 401 - Unauthorized (407 - Proxy
   Authentication Required) response, SHALL choose one of the available
   mechanisms and respond with a suitable <sasl-credential> directive in
   a <sasl-token> in a Authorization (Proxy-Authorization) header field
   in its next request. If the chosen mechanism allows for "initial
   response" type messages, the client MUST include the initial response
   in its request.  The client MUST also return the <sasl-sid> value in
   the corresponding field of <sasl-token>.

  4.3.3 Server behaviour upon receiving a <sasl-token>

   The server (proxy), upon receiving a <sasl-token> value containing 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 in a <sasl-
   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, but the chosen SASL mechanism
   requires that further challenge/response data (e.g. the final part of
   a three-way handshake) be sent by the server, the server SHOULD
   respond with the requested message-body, possibly protected by the
   negotiated security session (see Section 4.4), but including a WWW-
   Authenticate (or Proxy-Authenticate) header containing a <sasl-
   credential> directive in the <sasl-token> token. Alternatively, it
   can respond with a 401 - Unauthenticated (407 - Proxy Authentication
   Required) response containing a <sasl-credential> directive in a
   <sasl-token> in a WWW-Authenticate (or Proxy-Authenticate) header.
   If the client is authenticated and the server does not need to send
   any further challenge information, the server MUST respond with the
   requested message-body, possibly protected by the negotiated security
   session (see Section 4.4), but including a WWW-Authenticate (or
   Proxy-Authenticate) header containing a <sasl-token>. In this
   situation, no <sasl-credential>, <sasl-challenge> or <sasl-mechanism>
   directive shall be present.  In all cases, the server MUST also
   return the <sasl-sid> value in the corresponding field.



Nystrom & Zuccherato      Expires: August 2001                  [Page 5]


INTERNET DRAFT              SASL in http/1.1               February 2001


   The presence of the WWW-Authenticate (or Proxy-Authenticate) header
   containing a <sasl-credential> directive in a <sasl-token> on a
   message that is not a 401 - Unauthenticated response indicates
   successful authentication of the client.

  4.3.4 Final part of handshake

   The client, upon receiving a <sasl-challenge> directive in a <sasl-
   token> 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 in 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 401 -
   Unauthorized (407 - Proxy Authentication Required) response, no
   further credentials are required.  However, if the client is going to
   make any further requests within the given realm, it SHOULD include a
   <sasl-token> in an Authorization (Proxy-Authorization) header that
   does not contain a <sasl-credential> directive.  The request MAY be
   protected by the negotiated security session (see Section 4.4).  In
   all cases, the client MUST also return the <sasl-sid> value in the
   corresponding field of <sasl-credentials>.

  4.3.5 Other considerations

   Clients MAY abort exchanges at any time, e.g. by using the
   "Connection: close" header.

   There MUST NOT be more than one WWW-Authenticate or Proxy-
   Authenticate field containing a <sasl-token> in a respone.

   There MUST NOT be more than one Authorization or Proxy-Authorization
   header field containing a <sasl-token> in a request.

 4.4 Header and Message Encoding

   The <sasl-challenge> directive and the <sasl-credential> directive
   contains SASL challenges and responses.  The challenges and responses
   MUST be base64 [RFC2045] encoded before being placed in these fields.

   <<One problem here is how to handle headers. Some should probably be
   protected but others can't be e.g., WWW-Authenticate.  Here is one,
   not necessarily good, idea.  It's not clear to us that we can just
   protect headers this way.  Things might start to break, and an
   alternative could be not to protect headers - this would be similar
   to, e.g. S/MIME or PEM>>

   If a protection mechanism is negotiated as part of the SASL security



Nystrom & Zuccherato      Expires: August 2001                  [Page 6]


INTERNET DRAFT              SASL in http/1.1               February 2001


   session, then it SHOULD be applied to all subsequent <message-body>
   data sent between the server and client.  The protection takes effect
   immediately following the CRLF that separates the <message-header>'s
   from the <message-body>.

   In addition, certain headers that contain sensitive information
   SHOULD be protected.  In this case, the protection takes effect
   immediately following the CRLF that separates the header from the
   previous header or immediately following the <start-line>, if it is
   the first header in the HTTP message.  Protection ends immediately
   preceeding the CRLF separating the header from the next header or the
   <message-body>.  The WWW-Authenticate (Proxy-Authenticate) and
   Authorization (Proxy-Authorization) headers MUST NOT be protected.

   The protected message body and/or headers MUST be contained in an
   HTTP message having either a <sasl-challenge> or <sasl-credential>
   directive in a <sasl-token> in the appropriate header with the
   corresponding <sasl-sid> value.  The <sasl-credential> directive MUST
   NOT be present unless being sent from the server to the client as the
   final message in session negotiation.  (See Section 4.3.3)

   Protected <message-body>'s and <message-header>'s MUST be base64
   encoded.

 4.5 Error handling

  4.5.1 Client errors

   http/1.1 status codes which applies to SASL-based mechanisms are:

   -401 Unauthorized
    An http/1.1 server will use this status code when credentials
    supplied by a client could not be validated, in addition to the use
    described in Section 4.3 above.
   -406 Not Acceptable
    An http/1.1 server will use this status code when a client suggests
    an authentication mechanism which is not supported or accepted by
    the server.
   -407 Unauthorized
    An http/1.1 server will use this status code when credentials
    supplied by a client could not be validated, in addition to the use
    described in Section 4.3 above.

  4.5.2 Server errors

   When a client does not support any of the security mechanisms
   suggested by a server, or is otherwise unable to complete a SASL
   mechanism handshake with a server, it shall close the connection.



Nystrom & Zuccherato      Expires: August 2001                  [Page 7]


INTERNET DRAFT              SASL in http/1.1               February 2001


   User-oriented clients SHOULD provide the user with information about
   the failed handshake, and MUST fail in a controlled, predictable
   manner.

 4.6 Authorization Identity

   An authorization identity is one kind of access control factor.  It
   is the name of the entity that requests that operations be performed.
   Access control policies are often expressed in terms of authorization
   identities; e.g., entity X can perform operation Y on resource Z.

   The authorization identity bound to an association is often exactly
   the same as the authentication identity presented by the client, but
   it may be different.  SASL allows clients to specify an authorization
   identity distinct from the authentication identity asserted by the
   client's credentials.  This permits agents such as proxy servers to
   authenticate using their own credentials, yet request the access
   privileges of the identity for which they are proxying.  Also, the
   form of authentication identity supplied by a service like TLS may
   not correspond to the authorization identities used to express a
   server's access control policy, requiring a server-specific mapping
   to be done.

 4.7 Examples

  4.7.1 Example 1

   This example illustrates a client requesting a URL and a server
   responding with a list of supported SASL mechanisms. The client
   selects one of these and responds with a new request containing an
   initial-response type <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.

   <TBW>

  4.7.2 Example 2

   In this example a client knows in advance that a certain SASL
   mechanism is required. The mechanism allows for an initial-response
   type message and the client therefore includes a <sasl-credential>
   directive in its Authorization header. The server accepts the
   credentials and responds with the requested information.

   <TBW>





Nystrom & Zuccherato      Expires: August 2001                  [Page 8]


INTERNET DRAFT              SASL in http/1.1               February 2001


 4.8 Interoperability with existing http/1.1 clients and servers

   A client supporting SASL-based authentication MUST NOT include a
   <sasl-credential> directive in a <sasl-token> value in an
   Authorization or Proxy-Authorization header unless it knows that the
   server supports this SASL mechanism. The way the client finds out
   about the server's capacities in this respect is out of scope for
   this memo. This ensures proper interworking with existing http/1.1
   servers.

   A server supporting SASL-based authentication SHOULD include a
   "Basic" and a "Digest Access" <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.

 4.9 Preferences

   A client supporting both the "Basic", "Digest Access", and some SASL-
   based authentication mechanisms MUST choose the first supported
   mechanism it encounters in the first WWW-Authenticate (Proxy-
   Authenticate) header field it encounters in the server's response.
   Servers MUST therefore list authentication mechanisms in preferred
   order.

 4.10 Other considerations

   <<Perhaps a discussion on caching at proxies, c.f. RFC 2616 Section 
   13.6 and 13.7?>>

5  IANA Considerations

 5.1 GSSAPI/SASL Service Name

   For use with SASL [RC2222], a protocol must specify a service name to
   be used with various SASL mechanisms, such as GSSAPI.  For HTTP, the
   service name shall be "http".

6  Security Considerations

 6.1 Man-in-the-middle attacks

   Users of this protocol SHOULD be recognize that certain man-in-the-
   middle attacks are possible since the negotiation of the particular
   SASL security mechanism to be used is not protected.  For example, if
   the server suggests SASL mechansims A, B and C in a <sasl-token>
   message where A is a "strong" mechanism (for some definition of



Nystrom & Zuccherato      Expires: August 2001                  [Page 9]


INTERNET DRAFT              SASL in http/1.1               February 2001


   "strong") but B and C are "weak" or provide fewer security attributes
   than A, then an attacker could simply remove A from the list.  This
   forces the client to choose a "weaker" mechanism and neither side
   will detect the changes made by the attacker.

   Thus servers SHOULD only suggest SASL mechanisms that will provide
   adequate security for the task at hand.

   Similarly, the SASL <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, it is
   recommended to use this authentication mechanism in conjunction with
   an existing underlying TLS session.

 6.2 Replay attacks

   <TBW>

 6.3 Other considerations

   <TBW>

7  Acknowledgements

   Text for Section 4.6 was borrowed from [RFC2829].

8  Copyright

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an



Nystrom & Zuccherato      Expires: August 2001                 [Page 10]


INTERNET DRAFT              SASL in http/1.1               February 2001


   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

9  References

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
   3," IETF RFC 2026, October 1996.

   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies", IETF
   RFC 2045, November 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels," IETF RFC 2119, March 1997.

   [RFC2222] Myers, J., "Simple Authentication and Security Layer," IETF
   RFC 2222, October 1997.

   [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
   Specifications: ABNF," IETF RFC 2234, November 1997.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
   L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol --
   HTTP/1.1," IETF RFC 2616, June 1999.

   [RFC2617] Franks, J., Hallam-Baker, P, Hostetler, J., Lawrence, S.,
   Leach, P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and
   Digest Access Authentication," IETF RFC 2617, June 1999.

   [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
   "Authentication Methods for LDAP," IETF RFC 2829, May 2000.

10  Authors' Addresses

   Magnus Nystrom
   RSA Security
   Box 10704
   121 29 Stockholm
   Sweden

   Phone: +46 8 725 0900
   Email: magnus@rsasecurity.com

   Robert Zuccherato
   Entrust Technologies



Nystrom & Zuccherato      Expires: August 2001                 [Page 11]


INTERNET DRAFT              SASL in http/1.1               February 2001


   1000 Innovation Drive
   Ottawa, Ontario
   Canada K2K 3E7

   Phone: +1 613 270 2598
   Email: robert.zuccherato@entrust.com













































Nystrom & Zuccherato      Expires: August 2001                 [Page 12]