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

Re: more on Digest Autho

From: John Franks <john@math.nwu.edu>
Date: Thu, 22 Feb 1996 12:02:01 -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.960222113939.12195A-100000@hopf.math.nwu.edu>
On Wed, 21 Feb 1996, Paul Leach wrote:

> John said --
> 
> ] I didn't carefully follow your nonce incrementing proposal, but the
> ] only way I can immediately see to make it useful in preventing replay
> ] attacks is for the server to keep a data base of used nonces and the
> ] number of times each has been used.  Otherwise the server wouldn't
> ] know if the nonce had been properly incremented each time.  Keeping
> ] this data would constitute a "very big change" for a large heavily
> ] loaded server.
> 
> I posted the 47 lines of code it takes to detect reuse of nonces. The 
> most expensive operation was hashing (not digesting) the username and 
> password.  I'll time it tomorrow -- I'll bet it doesn't take more than 
> 20 microsecs on a 100 mhz pentium.
> 
> So I don't think it's a "very big change".
> 
> 

Okay, let's stipulate, for the sake of argument, that you can efficiently
remember which nonces have been used.

Then why not just use a new nonce for each transaction (a strategy
suggested by the specification).  That wouldn't break anything and
would achieve your goal of defending against replay attacks.  I hope
everyone understands that a new nonce does not mean that the user must
re-enter her username/password.  It only means that if the client
tries with the old nonce it gets a message that the nonce is stale and
it is asked to re-authenticate using a new nonce.  All this is
transparent to the user.  The username and password have to be
remembered by the client anyway.

There is a slight increase in net traffic because of the extra
transaction.  But this is really a marginal difference, especially
with persistent connections.

One of the nice things about the current spec is its flexability.  For
your application one-time nonces may be crucial.  But for mine nonces
with a one hour timestamp may be more appropriate.  Both of these are
possible.  Neither has to be set in stone in the protocol.  It is true
that incompetent implementations are possible which would not be
secure.  But that will always be true no matter what we put in the
specification.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Thursday, 22 February 1996 10:05:30 EST

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