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

RE: Digest Auth defending against replay

From: John Franks <john@math.nwu.edu>
Date: Mon, 26 Feb 1996 16:16:28 -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.960226150449.21188B-100000@hopf.math.nwu.edu>
On Mon, 26 Feb 1996, Paul Leach wrote:

> On Saturday, February 24, 1996 8:20AM, John suggested "one-time 
> response digests".
> 
> It didn't dawn on me until you made this latest suggestion, but the
> recommended nonce includes the URI of the requested entity.
> This will require a at least one challenge for each document requested.
> This latest suggestion achieves that lower bound.
> 

Yes, including the URI in the recommended nonce was a mistake.  I was
aware of this and I have removed it.  Re-using nonces is current
practice and will continue to be by far the most common type of
transaction.  It was my mistake to add URI to the recommended nonce
calculation.  BTW, over the weekend, I modified my prototype
implementation to use the recommended nonce (minus URI).  It works
fine with at least MSIE 2.0b2.  If anyone would like to try a browser
supporting digest authentication with it the URL is 

	http://hopf.math.nwu.edu/simp2/index.html

with username "Mufasa" and password "CircleOfLife".

> However: incrementing nonces only require one challenge per *session*,
> which is much more efficient, especially for long sessions. (This won't
> matter for sites where most information doesn't require authentication,
> but subscription based sites are an important case that lots of people
> want to support and  they would have almost all pages be authenticated
> if it were cheap enough.)

Yes, but I thought we had agreed that for a subscription service there
is no reason not to re-use nonces.  Re-using the nonce is even cheaper
than incrementing them.  

> When using persistent connections, the next expected nonce on that
> connection can be kept in a per-connection data structure (which
> the server probably already has and where the authenticated user
> name would also be kept), and directly accessed, without the
> overhead of a hash table.

If you don't keep a hash table how do you prevent a replay attack?
The replay would, of course, be in a different session.  I thought
that defending against replay was the point of all this.  You haven't
yet described how you would implement aging and recycling your hash
table.

If what you want is one challenge per session, a good way to implement
it would be a global hash table of session nonces together with a 
very small per session hash of the response digests kept in the per
session data structure you mention.  The nonce would not change 
throughout the session. 

> 
> Lastly, incrementing nonces are compatible with all existing
> implementations. A server that wasn't expecting the (new) client
> to modify the nonce will fail to authenticate and reissue the
> challenge. (A clever client could even notice this and stop
> incrementing the nonce after a couple of challenges to see if that helped.)
> 

The Microsoft browser I use for testing my implementation of Digest
Authentication responds to a re-issued challenge by asking the user to
re-enter the username and password.  This is appropriate since it
assumes that I have mistyped my password.  I wouldn't want to do this
whenever I contact a new server though.  Thus, at the very least, a
new-server would have to prevent that by recognizing that it was
talking to an old-client (i.e. the nonce had not been incremented).
Likewise, a new-client would also need a way to distinguish whether the
re-issued challenge was due to a mis-typed password or an old-server.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Monday, 26 February 1996 15:12:25 EST

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