RE: Some comments on Digest Auth

> ----------
> From: 	Ben Laurie[SMTP:ben@algroup.co.uk]
> Sent: 	Tuesday, January 20, 1998 3:09 PM
> To: 	Paul Leach
> Cc: 	Dave Kristol; http-wg@cuckoo.hpl.hp.com
> Subject: 	Re: Some comments on Digest Auth
> 
> Paul Leach wrote:
> > 
> > > From:         Ben Laurie[SMTP:ben@algroup.co.uk]
> > > A replayable Digest is by no means as bad as Basic:
> > >
> > > 1. The replay is likely to be time-limited in any sensible
> > > implementation, unlike in Basic.
> > >
> > > 2. The replay is only applicable to a single URL, unlike Basic.
> > >
> > > 3. The attacker is likely to have already seen the content, in the
> > > process of stealing the material necessary for the replay.
> > >
> > If you can do the above, then you've got _some_ replay prevention.
> 
> You can.
> 
> > Dave is arguing that no replay protection is necessary. I'm willing to
> > discuss how much is needed, but I'm tired of statements about
> "eliminating
> > plaintext is all we have to do". (I'll remind everyone that even Basic
> > _doen't_ use plaintext -- it uses a Base64 encoding.)
> 
> Agreed.
> 
> > I also do not believe that we can rely on "any sensible implementation".
> > When it comes to security, we need to require sensible impllementations,
> > because it is well proven that even well intentioned implentors
> frequently
> > fail to acheive "sensible implementations".
> 
> I'll limit the obvious snipe to this sentence :-)
> 
None of us has ever used a weak random number generator to create keys, I'm
sure.

> > That means we need to precisely describe the algorithms for at least one
> > sensible implementaiton.
> 
> Fair enough, but I don't think we can go so far as to mandate the
> algorithm, because...
> 
> > Finally, I believe that if we can solve the pipelining problem, then we
> can
> > solve the replay problem.
> 
> ...this, I believe, can only be solved by requiring servers to keep
> state, which is a Bad Thing. I have no objection to those servers that
> want to (and can) doing this, but I really don't see the point - if you
> are _that_ concerned about the content, you should've SSLed it (because
> the Bad Guy who is failing to get usephul stuph for a replay attack is
> getting the content anyway).
> 
If the servers keep no state, and just accepts the nonce that the client
quotes back at it, then you get no replay protection at all. The bad guy can
get an updated version of any page they have previously overheard, any time
they want. If the application is (e.g.) one where the user pays to get
periodically update information which has a constant URL, then this is a
serious problem.

That isn't what is being proposed, I realize. If the nonce the server gives
out contains a time stamp, it can refuse to accept old nonces. But I think
we should specify that it MUST contain a timestamp, if that's all the replay
protection we're going to have. And we could specify that the client include
a timestamp in the nonce...

Eureka!

Let the server send a nonce which contains a timestamp S. The client checks
to see that it isn't too old.

Let the client return a nonce which is the server's nonce S concatenated
with a timestamp C (plus some more random stuff to prevent dictionary
attacks). The server checks that S and C are both not too old. S can be used
for (say) 10 minutes; C has to be less than (say) 30 seconds old. (C is
initially set to S, and subsequent C are equal to S plus the amount of time
since S was received. This pretty much synchs the two clocks, so the
out-of-dateness of C is bounded by transit time through the
network/proxies...)

When the 60 minutes expires, the server has to respond with a 401 to refresh
S. Or, we could allow WWW-Authenticate to be sent with 200 OK; it would
update all the fields that were present (so could refresh the nonce, opaque,
realm, etc.)

Paul

Received on Wednesday, 21 January 1998 04:59:46 UTC