Re: Digest mess
John Franks (john@math.nwu.edu)
Fri, 19 Dec 1997 08:58:40 -0600 (CST)
On Fri, 19 Dec 1997, Scott Lawrence wrote:
>
> JF> I think the reason for including dates and expires in a digest is
> JF> to prevent replay attacks. There are many cases where not only is
> JF> the information important but the date it was sent is important
> JF> (think of a stock quote, for example).
>
> The digest already includes the server-generated nonce; efficient
> mechanisms already exist in the scheme for a unique nonce for each
> transaction. Since the nonce and its reusability are controlled by
> the server, this can already be made to match the application
> requirements.
>
It is the client who must be concerned about reused nonces to avoid
a replay attack. To avoid a replay attack the client would have to
keep a data base of all previous nonces and make sure they are not
reused.
> JF> The motivation for including the response status value in the
> JF> digest is to have the response from a PUT essentially certify that
> JF> the PUT succeeded.
>
> On the face of it this would seem to be a good idea, but is it
> possible for a proxy to change the response value (as for example
> changing a 303 from a 1.1 origin server to a 302 for a 1.0 user
> agent)?
>
Yes a proxy might change the status code. That is why it needs to be
replicated in the Authentication-info header. Hashing the status code
is what John Mallery was talking about when he said with a few minor
changes digest could become really useful. :)
John Franks
john@math.nwu.edu