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

Re: Some comments on Digest Auth

From: David W. Morris <dwm@xpasc.com>
Date: Sat, 17 Jan 1998 17:23:12 -0800 (PST)
To: Ben Laurie <ben@algroup.co.uk>
Cc: Yaron Goland <yarong@microsoft.com>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980117171211.19963B-100000@shell1.aimnet.com>


On Sat, 17 Jan 1998, Ben Laurie wrote:

> Yaron Goland wrote:
> > 3) Assuming using a new nonce for every request becomes a MUST it will be
> > impossible to use pipelining or concurrent requests. The performance
> > implications are chilling. As such we were thinking of an addition to the
> > standard which would be 100% backwards compatible but would help with
> > performance. The idea is to send a "next-nonce" header which includes a list
> > of nonces. The client MUST use the nonces in order, this is necessary to
> > make the server's job of tracking nonces tractable. Current clients would
> > ignore the header and just use the nonce provided in the authentication
> > response header. I am not privy to the black corridors of security so I
> > can't be sure this wouldn't weaken the algorithm but it seems to make the
> > mechanism no weaker than providing the next nonce in the authentication
> > response header.
> 
> Seems to me that the problem with this is that you can't enforce "the
> client MUST use the nonces in order", partly because multiple
> simultaneous connections, for example, could foil the client's best
> efforts to obey, by exhibiting variable delay, and partly because the
> client may be multithreaded, so synchronizing the sending of the nonces
> with each other (as opposed to the acquisition of them, which is
> trivially synchronized) would be onerous.

What if instead if the NONCE per REQUEST were modified to per ATOMIC
CONNECTION with the server. All requests within a connection could use
the same NONCE or in the case of multiple NONCEs sent on responses
within the connection, the client would be permitted to use the latest
NONCE it had received which essentially means any NONCE sent on the
connection. Either Yaron's original multiple NONCE proposal of this
variant would have some risk of an undectect MIM attack with a hijacked
connection but I would put my amateur security hat on and suggest that
if the content is valuable enough to be worth that level of sophistication
in the attack then SSL or something stronger should have been used
anyway. 

Also, what if each NONCE' used where derrived from the previous
NONCE using a known algorithm.  Like the next NONCE was a function
of the prior NONCE and the shared secret?

Dave Morris
Received on Saturday, 17 January 1998 17:25:20 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:10 EDT