are within the protection space specified by the Basic realm value of
   the current challenge. A client MAY preemptively send the
   corresponding Authorization header with requests for resources in
   that space without receipt of another challenge from the server.
   Similarly, when a client sends a request to a proxy, it may reuse a
   userid and password in the Proxy-Authorization header field without
   receiving another challenge from the proxy server. See section 4 for
   security considerations associated with Basic authentication.

3 Digest Access Authentication Scheme

3.1 Introduction

3.1.1 Purpose

   The protocol referred to as "HTTP/1.0" includes the specification for
   a Basic Access Authentication scheme[1]. That 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.
   This section provides the specification for a scheme that does not
   send the password in cleartext,  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 message content. The intent is
   simply to create an access authentication method that avoids the most
   serious flaws of Basic authentication.

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




 
RFC 2617                  HTTP Authentication                  June 1999


   default, the MD5 checksum) of the username, the password, the given
   nonce value, the HTTP method, 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 not
   addressed by this document.

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

3.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 to
   establish 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.

3.2 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, Authentication-Info, is specified.









 
RFC 2617                  HTTP Authentication                  June 1999


3.2.1 The WWW-Authenticate Response Header