- From: Ben Laurie <ben@algroup.co.uk>
- Date: Tue, 06 Jan 1998 17:53:42 +0000
- To: John Franks <john@math.nwu.edu>
- Cc: Scott Lawrence <lawrence@agranat.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John Franks wrote: > > JF> an earlier challenge with a valid, but old, nonce? In fact the > > JF> MIM would have to do this for the replay attack to work. > > > > It can, but then the client generates a request including a > > client-generated nonce of its own. > > Sigh. Yes, a client nonce can protect against a replay attack. We've > discussed it before. This would be a *big* change. It breaks all > existing implementations -- including the widely deployed Apache > server implementation and all existing client implementations. The Apache implementation is already marked as not suitable for serious use, because of the server's vulnerability to a replay. I'm not sure how to avoid this, except, perhaps, by tying the nonce to the (rough) time and the URL. Of course, a client nonce doesn't help with this at all, but since something needs to be done to fix Apache anyway, I'm not averse to changing the way Digest works. Actually, if we could insist that the digest authed request was in the same keptalive session as the original request, that'd help a lot... Cheers, Ben. -- Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Received on Tuesday, 6 January 1998 09:56:35 UTC