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

Re: Digest mess (fwd)

From: John Franks <john@math.nwu.edu>
Date: Tue, 6 Jan 1998 16:58:51 -0600 (CST)
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.96.980106165826.1755B-100000@hopf.math.nwu.edu>
Forwarded at Ben's request.

John Franks
john@math.nwu.edu

---------- Forwarded message ----------
Date: Tue, 06 Jan 1998 22:43:21 +0000
From: Ben Laurie <ben@algroup.co.uk>
To: John Franks <john@math.nwu.edu>
Subject: Re: Digest mess

John Franks wrote:
> 
> On Tue, 6 Jan 1998, Ben Laurie wrote:
> 
> >
> > How does the server know the client has responded with the nonce the
> > server sent? This requires a pile of mechanisms Apache hasn't got, or
> > some way of recreating the same nonce.
> >
> [snip]
> > The attack in Basic is "snarf the password and then use it for your
> > own evil purposes". The equivalent attack in Digest is "snarf the nonce
> > and the hashed password+nonce and use it for your own evil purposes".
> > That is a replay attack. The defence is to know that the nonce is a dud.
> > The question is, how?
> >
> 
> What the server receives is more complicated than what you describe;
> it includes a  hash of username, password, method and requested URL.

Hmmm. That'll teach me to rely on my memory. I'd forgotten that the URL
was in there. Certainly this reduces the problem.

> So, you are right, that a MITM could replay a request, but only for
> exactly the same URL with the same method.  This means it is quite
> appropriate for use with GET (or another idempotent method) as the MITM
> could only get another copy of a document he had already seen.

Right.

> Digest without the optional entity-digest (as in Apache) is
> inappropriate for PUT or POST, in any case, as there is no way to know
> that a MIM has not tampered with the posted entity.

Well... no less appropriate than Basic, and, in fact, somewhat more
appropriate. If Digest is truly not appropriate for PUT or POST, then
PUT and POST are not appropriate for HTTP (without some stronger
authentication).

> Incidentally, I don't know about Apache, but many implementations
> give a nonce a short duration time-to-live.  A good implementation
> would at least encode the last modified date in the nonce to assure
> that a replay cannot get an updated version.  This is pretty easy
> and I would assume Apache does it.

You'd be wrong, if I recall correctly (but my record isn't too good so
far). The current implementation was intended purely for
interoperability testing. Since it was followed by a rush of
non-implementation in clients, we never bothered to take it further. If
we can decide what Digest really should be, and clients are actually
going to implement Digest, then no doubt we'll do a better job. I'd like
to see it done properly.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache
Received on Tuesday, 6 January 1998 15:03:23 EST

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