W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: Digest mess

From: John Franks <john@math.nwu.edu>
Date: Fri, 19 Dec 1997 08:58:40 -0600 (CST)
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jg@w3.org, paulle@microsoft.com
Message-Id: <Pine.LNX.3.95.971219085254.580A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5031
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 

> 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
Received on Monday, 5 January 1998 06:55:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC