Re: Proxies and Digest-MessageDigest

On Thu, 29 Feb 1996, Paul Leach wrote:

> Are you just talking about D-MD, or Digest Auth for 
> Proxy-Authentication and Proxy-Authorization as well?
> 

Digest-MessageDigest has been part of the draft since its very early
versions.  It has limitations. I don't think we are in a position
to either remove it or overcome its limitations.  The new nextnonce
field seems to me to be a useful addition which is is a very modest
change and not likely to lead to any unpleasant surprises.  I also
agree with Paul that there is not much reason to keep the user, nonce
and realm fields.  In the fullness of time we can and will create
stronger ways of dealing with authentication, proxies, headers, etc.

I propose that the D-MD section of this draft be:

--------------------------------------

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.

--------------------------------------

The full text of the latest draft is at

http://hopf.math.nwu.edu/~john/new_rfc.txt


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Thursday, 29 February 1996 19:47:11 UTC