2004/id/draft-ietf-http-digest-aa-03.txt


HTTP Working Group                                  Jeffery L. Hostetler
INTERNET-DRAFT                                               John Franks
<draft-ietf-http-digest-aa-03.txt>                   Philip Hallam-Baker
                                                             Paul  Leach
                                                            Ari Luotonen
                                                            Eric W. Sink
                                                     Lawrence C. Stewart

Expires SIX MONTHS FROM--->                                March 1, 1996

      A Proposed Extension to HTTP : Digest Access Authentication

Status of this Memo

   This document is an Internet-Draft. 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."

   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   Distribution of this document is unlimited. Please send comments
   to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
   Discussions of the working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
   about HTTP and the applications which use HTTP should take place
   on the <www-talk@www10.w3.org> mailing list.

Abstract

   The protocol referred to as "HTTP/1.0" includes specification
   for a Basic Access Authentication scheme.  This scheme is not
   considered to be a secure method of user authentication, as the
   user name and password are passed over the network in an
   unencrypted form.  A specification for a new authentication scheme
   is needed for future versions of the HTTP protocol.  This document
   provides specification for such a scheme, referred to as "Digest
   Access Authentication".  The encryption method used by default is the
   RSA Data Security, Inc. MD5 Message-Digest Algorithm [2].

Table of Contents

   1.  Introduction
       1.1  Purpose
       1.2  Overall Operation
       1.3  Representation of MD5 digest values
   2.  Basic Access Authentication Scheme
       2.1  Specification of Digest Headers
       2.2  Digest Operation
       2.3  Security protocol negotiation
       2.4  Example
   3.  Security Considerations
   4.  Acknowledgments
   5.  References
   6.  Authors Addresses


1. Introduction

1.1  Purpose

   The protocol referred to as "HTTP/1.0" includes specification
   for a Basic Access Authentication scheme[1].  This scheme is not
   considered to be a secure method of user authentication, as the
   user name and password are passed over the network in an
   unencrypted form.  A specification for a new authentication scheme
   is needed for future versions of the HTTP protocol.  This document
   provides specification for such a scheme, referred to as "Digest
   Access Authentication".

   The Digest Access Authentication scheme is not intended to be
   a complete answer to the need for security in the World Wide Web.
   This scheme provides no encryption of object content.  The intent
   is simply to facilitate secure access authentication.

   It is proposed that this access authentication scheme be included
   in the proposed HTTP/1.1 specification.

1.2  Overall Operation

   Like Basic Access Authentication, the Digest scheme is based on a
   simple challenge-response paradigm.  The Digest scheme challenges
   using a nonce value.  A valid response contains a checksum (by default
   the MD5 checksum) of the username, the password, the given nonce
   value, and the requested URI.  In this way, the password is never sent
   in the clear.  Just as with the Basic scheme, the username and
   password must be prearranged in some fashion which is not addressed
   by this document.

1.3  Representation of digest values

   An optional header allows the server to specify the algorithm
   used to create the checksum or digest.  By default the MD5
   algorithm is used and that is the only algorithm described in
   this document.

   For the purposes of this document, an MD5 digest of 128 bits
   is represented as 32 ASCII printable characters.  The bits
   in the 128 bit digest are converted from most significant
   to least significant bit, four bits at a time to their
   ASCII presentation as follows.  Each four bits is
   represented by its familiar hexadecimal notation from the
   characters 0123456789abcdef.  That is binary 0000 gets
   represented by the character '0', 0001, by '1', and so on
   up to the representation of 1111 as 'f'.


1.4  Limitations

   The digest authentication scheme described in this document suffers
   from many known limitations.  It is intended as a replacement for
   basic authentication and nothing more.  It is a password-based system
   and (on the server side) suffers from all the same problems of any
   password system.  In particular no provision is made in this protocol
   for the initial secure arrangement between user and server
   establishing the user's password.

   Users and implementors should be aware that this protocol is not as
   secure as kerberos, and not as secure as any client-side private-key
   scheme.  Nevertheless it is better than nothing, better than what is
   commonly used with telnet and ftp and better than Basic
   authentication.


2. Digest Access Authentication Scheme

2.1 Specification of Digest Headers

   The Digest Access Authentication scheme is conceptually similar to the Basic
   scheme.  The formats of the modified WWW-Authenticate header line and the
   Authorization header line are specified below.  In addition, a new header,
   Digest-MessageDigest, is specified as well.

   Due to formatting constraints, all of the headers are depicted here
   on multiple lines.  In actual usage, they must follow the syntactic
   rules for HTTP/1.0 header lines [1].  Whitespace between the
   attribute-value pairs is allowed.

   If a server receives a request for an access-protected object, and an
   acceptable Authorization header is not sent, the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="<realm>",
                            domain="<domain>",
                            nonce="<nonce>",
                            opaque="<opaque>",
                            stale="<TRUE | FALSE>",
                            algorithm="<digest-algorithm>"


   The meanings of the identifiers used above are as follows:

      <realm>
         A string to be displayed to users so they know which
         username and password to use.  This string should contain
         at least the name of the host performing the authentication
         and might additionally indicate the collection of users who
         might have access.  An example might be
         "registered users @ gotham.news.com."

      <domain>  OPTIONAL
         A comma separated list of URIs, as specified for HTTP/1.0.  The
         intent is that the client could use this information to know the
         set of URIs for which the same authentication information should be
         sent.  The URIs in this list may exist on different servers.  If
         this keyword is omitted or empty, the client should assume that
         the domain consists of all URIs on the responding server.

      <nonce>
         A server-specified data string which may be uniquely generated each
         time a 401 response is made.  It is recommended that this string be
         base64 or hexadecimal data.  Specifically, since the string is passed
         in the header lines as a quoted string, the double-quote character
         is not allowed.

         The contents of the nonce is implementation dependent.  The
         quality of the implementation depends on a good choice.  A
         recommended nonce would include

             H(<client IP> + ":" + <timestamp> + ":" + <private key> )

         Where <client IP> is the dotted quad IP address of the client
         making the request, <timestamp> is a server generated time value,
         <private key> is data known only to the server.  With a nonce
         of this form a server would normally recalculate the nonce
         after receiving the client authentication header and reject
         the request if it did not match the nonce from that header.
         In this way the server can limit the reuse of a nonce to
         the IP address to which it was issued and limit the time of
         the nonce's validity.  A server might also wish to include
         the client request or the contents of the Host: header in
         the data digested to create the nonce.  Further discussion
         of the rationale for nonce construction is in section 3.2
         below.

         An implementation might choose not to accept a previously used
         <nonce> or a previously used <digest> to protect against a
         replay attack.  Or, an implementation might choose to use
         one-time nonces or digests for POST or PUT requests and a
         timestamp for GET requests.  For more details on the issues
         involved see section 3. of this document.

         The nonce is opaque to the client.

      <opaque>  OPTIONAL
         A string of data, specified by the server, which should returned by
         the client unchanged.  It is recommended that this string be
         base64 or hexadecimal data.  Specifically, since the string is passed
         in the header lines as a quoted string, the double-quote character
         is not allowed.

      <stale>   OPTIONAL
         A flag, indicating that the previous request from the client
         was rejected because the nonce value was stale.  If stale
         is TRUE, the client may wish to simply retry the request with
         a new encrypted response, without reprompting the user for a
         new username and password.  The server should only set stale
         to true if it receives a request for which the nonce is invalid
         but with a valid digest for that nonce (indicating the the client
         knows the correct username/password).

      <algorithm>   OPTIONAL
         A string indicating the algorithm used to produce the digest
         or checksum.  If this not present the MD5 algorithm is assumed.
         In this document the string obtained by applying this algorithm
         to the data "<data>" will be denoted by H(<data>).


   The client is expected to retry the request, passing an Authorization header
   line as follows:

Authorization: Digest
           username="<username>",             -- required
           realm="<realm>",                   -- required
           nonce="<nonce>",                   -- required
           uri="<requested-uri>",             -- required
           response="<digest>",               -- required
           message="<message-digest>",        -- OPTIONAL
           algorithm="<digest-algorithm>"     -- OPTIONAL
           opaque="<opaque>",                 -- required if provided
                                                          by server

        where <digest> := H( H(A1) + ":" + N + ":" + H(A2) )
  and <message-digest> := H( H(A1) + ":" + N + ":" + H(<entity-body>) )

        where:

                A1 := U + ':' + R + ':' + P
                A2 := <Method> + ':' + <requested-uri>

                with:
                        N -- nonce value
                        U -- username
                        R -- realm
                        P -- password

   <Method> is the HTTP method specified at the beginning of the
   first line of the client request. <requested-uri> is the part
   of the requested URL transmitted by the client to the server
   in the first line of an HTTP request.  In particular it does
   not include the "http://host:port"  part of the URL but does
   include any "query" part which might, for example,  include form
   data after a '?' in the URL.

   The purpose of the <message-digest> is to allow the server to
   ensure that the content of the request body has not been tampered
   with after leaving the client.  This would normally be used with a
   POST or PUT request and would allow the server to check the validity
   of the posted data. The <entity-body> is the "entity body" as
   prescribed in the Hypertext Transfer Protocol version 1.1.

   When authorization succeeds, the Server may optionally provide the
   following:

HTTP/1.1 200 OK
Digest-MessageDigest:
              message="<message-digest>",
              nextnonce="<nextnonce>"

   The Digest-MessageDigest header indicates that the server
   wants to communicate some information regarding the
   successful authentication (such as a message digest or a
   new nonce to be used for the next transaction).

   <message-digest> is computed by the same algorithm given
   above for the body of the client request.  This allows the
   client to verify that the body of the response has not been
   changed en-route.  The server would probably only send this
   when it has the document and can compute it.  The server would
   probably not bother generating this header for CGI output.

   <nextnonce> is the nonce the server wishes the client to use for
   the next authentication response.  Either field is optional.  In
   particular the server may send the Digest-MessageDigest header
   with only the nextnonce=<nextnonce> field as a means of
   implementing one-time nonces.  If the nextnonce field is present
   the client is strongly encouraged to use it for the next
   WWW-Authenticate header.  Failure of the client to do so may
   result in a request to re-authenticate from the server with
   the "stale=TRUE."

   The Digest-MessageDigest header has many limitations.  Only the
   entity body is digested, not any headers.  This limitation is due
   to the fact that proxy caches may (and do) alter the headers of
   documents which they relay. Future authentication schemes will
   have to deal with the complexities imposed by the behavior of
   intermediaries handling documents on their way from the origin
   server to the client, but those issues are beyond the scope of
   digest authentication, whose purpose is to replace Basic
   Authentication.  Despite its limitations the Digest-MessageDigest
   can be useful.

2.2 Digest Operation

   Upon receiving the Authorization information, the server may check
   its validity by looking up its known password which corresponds to
   the submitted <username>.  Then, the server must perform the same
   MD5 operation performed by the client, and compare the result to
   the given <response>.

   Note that the HTTP server does not actually need to know the user's
   clear text password.  As long as H(A1) is available to the server, the
   validity of an Authorization header may be verified.

   All keyword-value pairs must be expressed in characters from the
   US-ASCII character set, excluding control characters.

   A client may remember the username, password and nonce values, so that
   future requests within the specified <domain> may include the Authorization
   line preemptively.  The server may choose to accept the old Authorization
   information, even though the nonce value included might not be fresh.
   Alternatively, the server could return a 401 response with a new nonce
   value, causing the client to retry the request.  By specifying stale=TRUE
   with this response, the server hints to the client that the request should
   be retried with the new nonce, without reprompting the user for a new
   username and password.

   The <opaque> data is useful for transporting state information around.
   For example, a server could be responsible for authenticating content
   which actual sits on another server.  The first 401 response would include
   a <domain> which includes the URI on the second server, and the <opaque>
   for specifying state information.  The client will retry the request, at
   which time the server may respond with a 301/302 redirection, pointing
   to the URI on the second server.  The client will follow the redirection,
   and pass the same Authorization line, including the <opaque> data which
   the second server may require.

   As with the basic scheme, proxies must be completely transparent in
   the Digest access authentication scheme. That is, they must forward the
   WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched.
   If a proxy wants to authenticate a client before a request is forwarded to
   the server, it can be done using the Proxy-Authenticate and
   Proxy-Authorization headers.

2.3 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes
   a client is capable of handling.

   If this proposal is accepted as a required part of the HTTP/1.1
   specification, then a server may assume Digest support when a client
   identifies itself as HTTP/1.1 compliant.

   It is possible that a server may want to require Digest as its
   authentication method, even if the server does not know that the client
   supports it.  A client is encouraged to fail gracefully if the server
   specifies any authentication scheme it cannot handle.

2.4 Example

   The following example assumes that an access-protected document is being
   requested from the server.  The URI of the document is
   "http://www.nowhere.org/dir/index.html".

   Both client and server know that the username for this document is
   "Mufasa", and the password is "CircleOfLife".

   The first time the client requests the document, no Authorization header
   is sent, so the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest    realm="testrealm@host.com",
                            nonce="72540723369",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

   The client may prompt the user for the username and password, after which it
   will respond with a new request, including the following Authorization
   header:

Authorization: Digest       username="Mufasa",
                            realm="testrealm@host.com",
                            nonce="72540723369",
                            uri="/dir/index.html",
                            response="e966c932a9242554e42c8ee200cec7f6",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"


3. Security Considerations

   Digest Authentication does not provide provide a strong authentication
   mechanism.  That is not its intent.  It is intended solely to replace
   a much weaker and even dangerous authentication mechanism: Basic
   Authentication.  An important design constraint is that the new
   authentication scheme be free of patent and export restrictions.

   Most needs for secure HTTP transactions cannot be met by Digest
   Authentication.  For those needs SSL or SHTTP are more appropriate
   protocols.  In particular digest authentication cannot be used for any
   transaction requiring encrypted content.  Nevertheless many functions
   remain for which digest authentication is both useful and appropriate.

3.1 Comparison with Basic Authentication

   Both Digest and Basic Authentication are very much on the weak end of
   the security strength spectrum. But a comparison between
   the two points out the utility, even necessity, of replacing Basic
   by Digest.

   The greatest threat to the type of transactions for which these
   protocols are used is network snooping.  This kind of transaction
   might involve, for example, online access to a database whose use is
   restricted to paying subscribers.  With Basic authentication an
   eavesdropper can obtain the password of the user.  This not only
   permits him to access anything in the data base, but often worse, will
   permit access to anything else the user protects with the same
   password.

   By contrast, with Digest Authentication the eavesdropper only gets
   access to the transaction in question and not to the user's password.
   The information gained by the eavesdropper would permit a replay
   attack, but only with a request for the same document and even
   that might be difficult.

3.2 Replay Attacks

   A replay attack against digest authentication would usually be
   pointless for a simple GET request since an eavesdropper would
   already have seen the only document he could obtain with a replay.
   This is because the URI of the requested document is digested in
   the client response and the server will only deliver that document.
   By contrast under Basic Authentication once the eavesdropper has
   the user's password any document protected by that password is open
   to him.  A GET request containing form data could only be "replayed"
   with the identical data.  However, this could be problematic if it
   caused a CGI script to take some action on the server.

   Thus, for some purposes, it is necessary to protect against replay
   attacks.  A good digest implementation can do this in various ways.
   The server created "nonce" value is implementation dependent, but if
   it contains a digest of the client IP, a timestamp, and a private
   server key (as recommended above) then a replay attack is not
   simple. An attacker must convince the server that the request is
   coming from a false IP address and must cause the server to deliver
   the document to an IP address different from the address to which it
   believes it is sending the document.  An attack can only succeed in
   the period before the timestamp expires.  Digesting the client
   IP and timestamp in the nonce permits an implementation which does
   not maintain state between transactions.

   For applications where no possibility of replay attack can be
   tolerated the server can use one-time response digests which will
   not be honored for a second use.  This requires the overhead of
   the server remembering which digests have been used until the
   nonce timestamp (and hence the digest built with it) has expired,
   but it effectively protects against replay attacks. Instead of
   maintaining a list of the values of used digests, a server would
   hash these values and require re-authentication whenever a hash
   collision occurs.

   An implementation must give special attention to the possibility of
   replay attacks with POST and PUT requests.  A successful replay
   attack could result in counterfeit form data or a counterfeit
   version of a PUT file.  The use of one-time digests or one-time
   nonces is recommended.  It is also recommended that the optional
   <message-digest> be implemented for use with POST or PUT requests
   to assure the integrity of the posted data.  Alternatively, a server
   may choose to allow digest authentication only with GET requests.
   Responsible server implementors will document the risks described
   here as they pertain to a given implementation.

3.3 Man in the Middle

   Both Basic and Digest authentication are vulnerable to "man in the
   middle" attacks, for example, from a hostile or compromised proxy.
   Clearly, this would present all the problems of eavesdropping.  But it
   could also offer some additional threats.  In particular, even with
   digest authentication, a hostile proxy might spoof the client into
   making a request the attacker wanted rather than one the client
   wanted.  Of course, this is still much harder than a comparable
   attack against Basic Authentication.

3.4 Spoofing by Counterfeit Servers

   Basic Authentication is vulnerable to spoofing by counterfeit servers.
   If a user can be led to believe that she is connecting to a host
   containing information protected by a password she knows when
   in fact she is connecting to a hostile server then the hostile server
   can request a password, store it away for later use, and feign an
   error.  This type of attack is not possible with Digest Authentication.

3.5 Summary

   By modern cryptographic standards Digest Authentication is weak.  But
   for a large range of purposes it is valuable as a replacement for
   Basic Authentication.  It remedies many, but not all, weaknesses of
   Basic Authentication.  Its strength may vary depending on the
   implementation.  In particular the structure of the nonce (which is
   dependent on the server implementation) may affect the ease of
   mounting a replay attack.  A range of server options is appropriate
   since, for example, some implementations may be willing to accept the
   server overhead of one-time nonces or digests to eliminate the
   possibility of replay while others may satisfied with a nonce like
   the one recommended above restricted to a single IP address and with
   a limited lifetime.

   The bottom line is that *any* compliant implementation will be
   relatively weak by cryptographic standards, but *any* compliant
   implementation will be far superior to Basic Authentication.


4.  Acknowledgments

   In addition to the authors, valuable discussion instrumental in
   creating this document have come from Peter J Churchyard, Ned Freed,
   and David Kristol.


5. References

   [1]  T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
        "Hypertext Transfer Protocol -- HTTP/1.0"
        Internet-Draft (work in progress), UC Irvine,
        <URL:http://ds.internic.net/internet-drafts/
        draft-ietf-http-v10-spec-00.txt>, March 1995.

   [2]  RFC 1321.  R.Rivest, "The MD5 Message-Digest Algorithm",
        <URL:http://ds.internic.net/rfc/rfc1321.txt>,
        April 1992.

6. Authors Addresses

   John Franks
   john@math.nwu.edu
   Professor of Mathematics
   Department of Mathematics
   Northwestern University
   Evanston, IL 60208-2730, USA

   Phillip M. Hallam-Baker
   hallam@w3.org
   European Union Fellow
   CERN
   Geneva
   Switzerland

   Jeffery L. Hostetler
   jeff@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   Paul J. Leach
   paulle@microsoft.com
   Microsoft Corporation
   1 Microsoft Way
   Redmond, WA 98052, USA

   Ari Luotonen
   luotonen@netscape.com
   Member of Technical Staff
   Netscape Communications Corporation
   501 East Middlefield Road
   Mountain View, CA 94043, USA

   Eric W. Sink
   eric@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   Lawrence C. Stewart
   stewart@OpenMarket.com
   Open Market, Inc.
   215 First Street
   Cambridge, MA  02142, USA

