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

RE: New draft for Digest Authentication

From: John Franks <john@math.nwu.edu>
Date: Fri, 23 Feb 1996 16:17:04 -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.960223155556.15547A-100000@hopf.math.nwu.edu>
On Fri, 23 Feb 1996, Paul Leach wrote:

> John said-
> 
> ] 1) Nonce incrementing, does not in any way strengthen the security of
> ] digest authentication over the use of one-time nonces. One-time nonces
> ] are consistent with, and suggested in, the current and past
> ] specifications.  The only advantage of nonce incrementing would be a
> ] small efficiency improvement.
> 
> It isn't small. It's an extra round trip on every authenticated 
> request. And every request SHOULD be authenticated. Making the extra 
> security be unnecessarily expensive will only lead to it not being used.
> 

Opinions may differ on what is "small".  I think we have agreed that
it is only useful for PUT or POST transactions, not GET transactions.
It is unnecessary for most but not all POST transactions if the 
message-digest is used (which it has to be for any kind of security).
Posts which simply gather information do not need one-time  nonces
since a replay could only reproduce identical information.  You
want to use POST for server administration.  That requires one-time
nonces but for that application the extra round trip would be 
negligible.

The transactions where one-time nonces have any use 
represent only a small fraction of all transactions.  In any case
with persistent connections an extra round trip is not excessively
expensive.  

> The trivial change I outlined in a previous post (reproduced below) 
> will make it possible for every request to be authenticated at no extra cost.
> 
> ]
> ] 2) Nonce incrementing breaks current implementations.
> 
> No it doesn't, as my previous mail explained. Reproduced below.
> 
> ] Making it
> ] optional to maintain backwards compatibility would make it useless for
> ] security as any attacker would simply use the old version of the
> ] protocol.
> 
> No it doesn't. An existing client that doesn't send in an incremented 
> nonce will get a new challenge with a new nonce. Ditto for an attacker.
> 

You do not address the fact that   new client <--> old server
transactions are broken. If the client increments a nonce from
an server not expecting it the transaction will fail.

> 
> New clients, that increment the nonce, will work with old servers

Why?  An incremented nonce will fail with an old server.  How does
a client know it if is talking to a new or old server.

Look, we can come up with a hack that doesn't break anything if we
work long enough.  But it will be just that, a hack, and it doesn't
buy much -- the elimination of one nonce negotiation on a small
fraction of transactions.

We are supposed to arrive at "rough consensus".  Does anyone besides Paul
think that incrementing nonces is worth it?  If so why?



John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Friday, 23 February 1996 14:19:32 EST

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