RE: Digest Auth defending against replay

On Mon, 26 Feb 1996, Paul Leach wrote:

> Note that if you used incrementing nonces, you wouldn't need a timestamp.
> Probably comes out about even in expense with incrementing.
> Which is why I removed it from the last suggested replacment for the <nonce>
> description.
> ]
> ] > When using persistent connections, the next expected nonce on that
> ] > connection can be kept in a per-connection data structure (which
> ] > the server probably already has and where the authenticated user
> ] > name would also be kept), and directly accessed, without the
> ] > overhead of a hash table.
> ]
> ] If you don't keep a hash table how do you prevent a replay attack?
> ] The replay would, of course, be in a different session.
> And each new session issue a challenge using a totally new nonce,
> and only accept the latest incremented version of it.  All replays
> of old ones would just be rejected.

You can't assume that the challenge and response are part of the same
connection.  This might happen typically but you can't *require* it
without changes to HTTP which won't be acceptable to lots of people.
If the server has to permit some responses which are not in the same
connection as the challenge then that's what an attacker would use.
In that situation the server has no way to know what a "totally
new nonce" is without remembering old ones in some fashion.  You can't
remember all nonces forever so you have to remember them for some
fixed time and then expire them with a time stamp embedded in them.

> ] You haven't
> ] yet described how you would implement aging and recycling your hash
> ] table.
> That's because one isn't needed when one is using persistent connections.

At the time you create the nonce and issue the challenge there is
no way to know if the connection will be persistent. 

> You age the hash table by putting an expiration time in each entry,
> and freeing the entry when that time has passed.

An expiration time for each hash entry?? 

John Franks 	Dept of Math. Northwestern University

Received on Monday, 26 February 1996 19:42:13 UTC