Re: Digest Auth defending against replay

A trick I introduced into SEA was to always apply a random mask to 
each shared secret on each transaction. This is equivalent to the
nonce "increment" idea but its essentially a replacement for challenge
response.

The client sends to the server KD(key | mask, Date, URI) where mask 
is a random value chosen by the client. The server must then check to 
ensure that the value of mask is not re-used within a time-frame
defined about date by the server. 

Ie server may decide to accept requests whose date is within 10 
minutes of the server date and keep a log of old requests for 20
minutes. This approach does have the danger of network time spoofing,
I tell a server over afs that its clock is 2 days slow, get the user 
to give me an authentication ticket for two days hence and then store
them, Hence a server should keep trak of all pre-dated tickets 
regardless of the time window size.


While we are at it Ran Carnetti suggested that we pu in an authentication 
of the server to the client using the same technique as for client-server.
This is low cost and high gain.

I think that we should not try to achieve perfection on digest auth
since we will be able to do much much more with WRAPPED transactions.
I see digest as a drop in replacement for BASIC. This is why I was
prepared to see the compromises involved in its design. My original
suggestion _did_ wrap the message and Jeff objected (rightly) that
it was no longer a direct BASIC replacement.


	Phill

Received on Monday, 26 February 1996 11:59:58 UTC