- From: John Franks <john@math.nwu.edu>
- Date: Mon, 26 Feb 1996 21:39:18 -0600 (CST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 john@math.nwu.edu
Received on Monday, 26 February 1996 19:42:13 UTC