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

Digest Auth defending against replay

From: John Franks <john@math.nwu.edu>
Date: Sat, 24 Feb 1996 08:20:32 -0600 (CST)
To: Paul Leach <paulle@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960224075301.16603B-100000@hopf.math.nwu.edu>

I think I may have a solution to the "nonce incrementing" issue. This is
really the issue of how to defend against replay attacks efficiently.

My suggestion is to forget one-time nonces and use one-time 
response digests.  In other words, instead of keeping hashes of 
previously used nonces the server may keep hashes of previously
used response digests (or response digest + message digest if message
digest is present).  If the server detects a previously used digest
it will request re-authentication with a new nonce using the stale
nonce field.

Here are some virtues of this scheme:

1. At least as strong as one-time nonces or incremented nonces in defending
against replay attacks.

2. Compatible with all current implementations of browsers and servers.
No change is required in client implementations and server implementations
are at least as easy to do as nonce incrementing.

2. Efficient.  The extra round trip re-authentication request occurs
*only* when the client, in a single session, makes a second GET for
the same document or does a second POST or PUT with identical data.
Most clients by default use a cached version when a document is
requested for a second time in one session.  I believe that
"duplicate" GETs, POSTs, and PUTs would be very rare.  Compare this
with nonce incrementing which would require an extra round trip for
every new-client <--> old-server or old-client <--> new-server
transaction.

What do you think?  

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Saturday, 24 February 1996 06:21:54 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:46 EDT