Digest Auth (I think we have a deal!)

On Tue, 27 Feb 1996, Paul Leach wrote:

> *** IMPORTANT ***
> 
> If the value of the nonce parameter is supposed to replace the one the 
> client is using,  and if this is how current shipping clients (if any) 
> behave, then I will happily withdraw my "incrementing nonce" proposal.
> A server that wants to prevent replays can give the client a new nonce 
> on each response, constructing it by incrementing or randomizing or 
> timestamps or whatever it wants.
> 

I think we have a deal!

To the best of my knowledge there are no implementations which support
the optional Digest-MessageDigest: header.  I have no problem with extending
it in an optional fashion.  To be on the safe side I suggest adding a
new optional field "nextnonce."  It is explicitly allowed for the server
to return Digest-MessageDigest: with only the nextnonce field.  If this
field is present the client is strongly encouraged to use it as the
next nonce.  Failure to do so may result in an extra challenge/response.

My proposed addition to the draft is attached below. Is it ok Paul?

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

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

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

HTTP/1.1 200 OK
Digest-MessageDigest:
              username="<username>",
              realm="<realm>",
              nonce="<nonce>",
              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.

        The <username>, <realm>, and <nonce> are those of the
        current transaction.  <nextnonce> is the nonce the server
        wishes the client to use for the next authentication
        response.  All fields are 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.

Received on Tuesday, 27 February 1996 11:30:27 UTC