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