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

Re: Some comments on Digest Auth

From: Ben Laurie <ben@algroup.co.uk>
Date: Mon, 19 Jan 1998 03:00:56 +0000
Message-Id: <34C2C1E8.76358FE8@algroup.co.uk>
To: Yaron Goland <yarong@microsoft.com>
Cc: "'David W. Morris'" <dwm@xpasc.com>, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5216
Yaron Goland wrote:
> I wish someone would explain to me how having multiple outstanding attacks
> could lead to degraded security assuming that the multiple nonces do NOT
> have lifetimes greater than that of the previous single nonce. That is, the
> server sends you a nonce and starts a hypothetical count down. Once the
> count down is expired that nonce will not be accepted. My proposal is to
> allow the server, using a separate header, to return multiple nonces.
> However I suspect that the server should use the same count down for ALL the
> previously returned nonces. Use 'em or lose 'em, as it were.
> As for ordering of requests, I'm still not sure how big an issue this is. It
> would be great if some server side implementers could weigh in on the issue.

My point is that you can't require ordering unless you add some other
requirements, too (like using the nonces on the same keptalive session).
Anyway, checking ordering in Apache would be troublesome, and I imagine
in other servers, too, at least without additional restrictions. In
fact, Apache won't even be able to prevent the client from using the
same nonce multiple times (up until the nonce times out, anyway).

But most importantly, I can't see what value the ordering requirement
has, so it may as well be dropped. 



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 Sunday, 18 January 1998 19:04:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC