RE: Digest Auth (I think we have a deal!)

John suggested:

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

Yes, just fine by me!  A couple of small mostly editorial comments/suggestions:

1. Small edit -- change:
	Failure of the client to do so  may result in a request to
	re-authenticate from the server.
to
	Failure of the client to do so  may result in a request to
	re-authenticate from the server with "stale=true".
just to emphasize that the client shouldn't reprompt for a new password. (Since
it seems that clients, at least from certain very large PC software companies,
may be confused on this subject...:-)

2. The value of returning "message-digest=" is clear. It isn't clear 
from the text
what use there is in returning the username, realm and nonce.  It seems like it
might be so the client can recompute the digest= that it sent on the 
request and
compare it with the one it sent -- but if it was munged by the attacker,
authentication would fail. If there's some other purpose,  it would be good
to state what it is and what clients need to do achieve that purpose. If not,
maybe it should just come out?

3. There's an awkward transition between where D-MD is described and the
next paragraph, which appears to be a description of the overall operation
of the Digest part of HTTP. I'd suggest something like renaming section 
2.1 from
"Specification" to "Specification of Digest headers", and inserting
a section header 2.2 titled something like "Digest operation" just
after the description of D-MD (and renumbering the later sections).

Comment #2 is the major one.

Paul

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