RE: Some comments on Digest Auth

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.

		Yaron

> -----Original Message-----
> From:	David W. Morris [SMTP:dwm@xpasc.com]
> Sent:	Saturday, January 17, 1998 5:23 PM
> To:	Ben Laurie
> Cc:	Yaron Goland; http-wg@cuckoo.hpl.hp.com
> Subject:	Re: Some comments on Digest Auth
> 
> 
> 
> 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 Sunday, 18 January 1998 16:21:24 UTC