Re: more on Digest Autho

John said --
----------
]
] 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.

It's an extra round trip on every request, even with persistent 
connections. That's 1-2 seconds in many cases; even longer overseas. 
That will encourage people to trade efficiency for security.

Let me try to reduce this to the bare minimum.
All I want to do to the spec is add one little thing -- say that the 
low order 4 digits are a counter modulo 10^n, and that client is highly 
encouraged to increment it after each use (but, for backward 
compatibility, doesn't have to).

Let's look at the ramifications of such a change:

Servers that don't want to rememeber nonces wouldn't have to. They 
wouldn't even have to change. When the response arrives, they would compute
	H(H(A1) + ':' + N + ":" + H(A2))
from info in the incoming request and the server's knowledge ot the 
paswword ,just as they now do, and if it maches the digest in the 
"response=", then the request is authenticated. If it happens not to 
check, then the worst that will happen is a challenge.

Old clients, that don't increment the nonce, will continue to work (by 
the same reasoning) with old servers that don't care about replay, and 
will just generate a challenge on each request from servers that do.

New clients, that increment the nonce, will work with old servers, new 
servers that don't remember the nonce, and efficiently with new servers 
that demand the nonce not be reused.

Net net: it's not an implementation change unless increased security is 
desired; it's a spec change to say that part of the nonce is not opaque 
(and to describe how one could efficiently get increased security..).


] One of the nice things about the current spec is its flexability.

Two observations: it's not flexible enough to do what I want 
efficiently; and the proposed change is 99.44% as flexible, and 
backward compatible to boot.

Paul

Received on Thursday, 22 February 1996 10:38:22 UTC