RE: Some comments on Digest Auth

I think the proposal to allow clients to generate nonces is intriguing but
it does concern me from a long term security point of view. Experience has
taught that allowing clients to generate what is essentially server side
information leads to trouble. For example in DAV we learned a long time ago
to not let clients generate URIs, it tends to break things. In this case
allowing the client to generate nonces remove's flexibility on the server's
part in how it generates and manages nonces. Furthermore I'm concerned with
behavior through proxies where a proxy may have multiple connections to a
server and may put a client's request into any one of its connections to
that server.

I guess i'm just old fashioned but I always like to err on the side of
maximum flexibility. In this case that means only giving the server the
right to generate nonces.

		Yaron

> -----Original Message-----
> From:	John Franks [SMTP:john@math.nwu.edu]
> Sent:	Monday, January 19, 1998 10:42 AM
> To:	Dave Kristol
> Cc:	Yaron Goland; http-wg@cuckoo.hpl.hp.com
> Subject:	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 Wednesday, 21 January 1998 04:59:06 UTC