- From: Paul Leach <paulle@microsoft.com>
- Date: Tue, 27 Feb 96 10:30:09 PST
- To: john@math.nwu.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
(No advocacy of incrementing nonces within. Just comments on how servers might implement digest challenge and response.) John said: ] You can't assume that the challenge and response are part of the same ] connection. Agreed. You have to assume that some clients will use one-shot connections. For those, you need a hash table if you care about replay. Even if you didn't, it might be cheaper to look up the "digest=" value in a hash table than to recompute it. ] 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. They indeed have to be remembered in "some fashion", but that doesn't mean they have to be individually remembered; there are more space efficient ways. Nonces are divided into three sets: ones already used, ones currently valid if presented by clients, and ones that haven't been used yet. If the server remembers the ones that are currently valid, and rejects all others, it will never permit a replay. Then, if it never generates the same nonce twice (probabiliistically, at least) it will never make one current that was once used before. It can do this by including time or a sequence number in the nonce. ] An expiration time for each hash entry?? 32 whole bits of it. Paul
Received on Tuesday, 27 February 1996 10:27:22 UTC