Re: Digest Auth defending against replay

I think Phil's trick is very clever too. Applying this idea to the 
current controversy, it gives me an idea.

I would be happy to get rid of the explicit sequence number from the 
nonce in favor of something that seems like it is the combination 
Phil's idea, your draft and my suggestions.

It's like "one-time responses", but with a way to compress the storage 
that remembers all the previous responses. The client never generates 
the same response twice; it makes the responses vary by XORing in some 
bit string that the server can predict. Thus, the server just needs to 
duplicate the client's munging of the
nonce by updating its prediction of the client's bit string each time 
it receives a request, instead of storing all of the clients previous 
responses.

I'm happy to accept  any form of the predictable bit string generator 
that others find acceptable (as long as it's not a constant... :-)

Use of this technique  can be *completely* optional, as long as there 
is agreement on what the predictable bit string generating function is 
among those using the option.

] ... I worry a little about
] generating a whole sequences of digests on data which has a byte
] incremented each time.  Does anyone know if MD5 is vulnerable given
] this kind of data?

This is a VERY good question.  Actually, I've never even heard anyone say
what the issues are of making a ton of digested "secret concatenated 
with known plaintext" material available to an attacker trying to 
discover the secret.

Note that a server can limit the amount of either kind of material 
available to an attacker by simply refusing to accept more than N 
Authorization: headers based on a single base nonce. In terms of the 
latest draft, it can vary the "private key" every N times and reissue a 
challenge (with "stale=true").

Paul

Received on Monday, 26 February 1996 18:41:36 UTC