2.5 Proxy-Authentication and Proxy-Authorization

   The digest authentication scheme may also be used for authenticating
   users to proxies, proxies to proxies, or proxies to end servers by
   use of the Proxy-Authenticate and Proxy-Authorization headers. These
   headers are instances of the general Proxy-Authenticate and Proxy-
   Authorization headers specified in sections 10.30 and 10.31 of the
   HTTP/1.1 specification [2] and their behavior is subject to
   restrictions described there.  The transactions for proxy
   authentication are very similar to those already described.  Upon
   receiving a request which requires authentication, the proxy/server
   must issue the "HTTP/1.1 401 Unauthorized" header followed by a
   "Proxy-Authenticate" header of the form





 
RFC 2069              Digest Access Authentication          January 1997


     Proxy-Authentication     = "Proxy-Authentication" ":" "Digest"
                                   digest-challenge

   where digest-challenge is as defined above in section 2.1. The
   client/proxy must then re-issue the request with a Proxy-Authenticate
   header of the form

     Proxy-Authorization      = "Proxy-Authorization" ":"
                                   digest-response

   where digest-response is as defined above in section 2.1. When
   authentication succeeds, the Server may optionally provide a Proxy-
   Authentication-info header of the form

Proxy-Authentication-info = "Proxy-Authentication-info" ":" nextnonce

   where nextnonce has the same semantics as the nextnonce field in the
   Authentication-info header described above in section 2.1.

   Note that in principle a client could be asked to authenticate itself
   to both a proxy and an end-server.  It might receive an "HTTP/1.1 401
   Unauthorized" header followed by both a WWW-Authenticate and a
   Proxy-Authenticate header.  However, it can never receive more than
   one Proxy-Authenticate header since such headers are only for
   immediate connections and must not be passed on by proxies.  If the
   client receives both headers, it must respond with both the
   Authorization and Proxy-Authorization headers as described above,
   which will likely involve different combinations of username,
   password, nonce, etc.

3. Security Considerations

   Digest Authentication does not provide a strong authentication
   mechanism.  That is not its intent.  It is intended solely to replace
   a much weaker and even more 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.








 
RFC 2069              Digest Access Authentication          January 1997


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 database, 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