Re: Some comments on Digest Auth

On Mon, 19 Jan 1998, Dave Kristol wrote:
> 
> A nonce can be self-describing.  That is, the server can choose a form
> for a nonce that encodes its lifetime.  That's attractive, because it
> means the server can avoid having a database of nonces.  The lifetime
> can be made arbitrarily long or short, as the server's needs require.
> 

Embedding items in a nonce (e.g. by making the nonce a hash of these
items) is often useful.  The nonce is then checked when the request
with credentials arrives to make sure that it is a valid nonce.  Dave
mentions using an embedded timestamp which can be used to expire
nonces.  It is also a good idea to embed the requestor's IP address.
One thing that I would like to do, but which would conflict with a
pre-delivered list of nonces, is to embed the (strong) ETag of a
document in the nonce.  This is simpler than timestamping and
guarantees that a replay can only retrieve exactly the same document
(which a MITM has presumably already seen when he captured the nonce.)

>
> Conclusions:  requiring a client and server to honor a sequence of
> nonces is hard.  Allowing them to pick from a list of nonces, as long as
> there's no reuse is easier, but still hard.  I don't see any particular
> added value in sending a list of nonces, all of which have independent
> (or simultaneous) time-out properties, instead of a single such nonce.
> 

The point of Yaron's suggestion is to get pipelining to work.  This
is certainly important if we can figure out how to do it.  A list of
nonces which must be returned in order is problematic if they
are not all used in the same pipeline because there is no guarantee
that they arrive in the order they were sent (or even to the same
server in some cases).  Fortunately, to make pipelining work we are
essentially talking about one connection.

I would prefer letting the client generate a sequence of nonces
(based on the first) valid only when pipelined.  They would embed
the shared secret.  E.g. 

   new_nonce := H( username:password:last_nonce:URI )

The server gets to create the first nonce and can embed things like IP
address and timestamp in it.  Subsequent nonces are guaranteed to be
made by someone knowing the secret and have the first nonce embedded.
The server only needs to remember the previous nonce in a pipeline.

I don't think this would break anything.  An old client which did not
understand this would simply not pipeline.  A new client understanding
this and sending a request to an old server would have the pipelined
requests after the first fail and would retry them without pipelining.

What do you think?

One problem is what does "in the same pipeline" mean if HTTP were
to use something other than TCP/IP as undelying transport.

John Franks
john@math.nwu.edu

Received on Monday, 19 January 1998 10:46:58 UTC