W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

FW: Digest Auth defending against replay

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
Message-Id: red-16-msg960227182319MTP[01.52.00]000000b1-116761
(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.

Received on Tuesday, 27 February 1996 10:27:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC