> From http-wg-request@cuckoo.hpl.hp.com Wed Feb 21 15:22:26 1996
> Received: from allegra.tempo.att.com by zp.tempo.att.com.tempo.att.com; id AA25388; Wed, 21 Feb 96 15:22:21 EST
> Received: from research.att.com by allegra.tempo.att.com; id AA23959; Wed, 21 Feb 96 15:22:19 EST
> Received: from hplb.hpl.hp.com by research; Wed Feb 21 15:19:33 EST 1996
> Received: from cuckoo.hpl.hp.com by hplb.hpl.hp.com; Wed, 21 Feb 1996 20:13:27 GMT
> Received: from http-wglistexploder by cuckoo.hpl.hp.com
> (1.37.109.16/15.6+ISC) id AA194253573; Wed, 21 Feb 1996 20:12:53 GMT
> Date: Wed, 21 Feb 1996 12:05:41 -0800 (PST)
> From: Ned Freed <NED@innosoft.com>
> Subject: Re: more on Digest Auth
> In-Reply-To: "Your message dated Wed, 21 Feb 1996 08:59:18 -0500 (EST)"
> <9602211359.AA21600@zp.tempo.att.com.tempo.att.com>
> To: dmk@allegra.att.com
> Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Message-Id: <01I1H3JP9GOQ9QVBMH@INNOSOFT.COM>
> Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> Sender: http-wg-request@cuckoo.hpl.hp.com
> Status: R
>
Ned Freed <NED@innosoft.com> wrote:
> > [Dave Kristol wrote:]
> > There has been a lot of nonce-sense spewed here recently about Digest
> > Authentication. There is a current I-D:
> > http://www.internic.net/internet-drafts/draft-ietf-http-digest-aa-02.txt
>
> > Unfortunately, the I-D doesn't talk much about how to generate the
> > opaque string, and opaque is an important part of preventing replays of
> > the sort recently discussed here. Unfortunately, I can't figure out
> > the originator of the algorithm I use to generate opaque, but I think
> > it was John Franks. In any case, my opaque is an MD5 of
>
> > - a server-dependent (compile-time) random number
> > - a timestamp
> > - the request IP address
> > - the (time-dependent) nonce
> > - the security realm
>
> > Opaque in the Authenticate header must match the server's
> > request-time-calculated value for processing to proceed.
>
> I think your choice of material is fine, but putting it in the opaque string is
> a waste of time in the cryptographic sense since the opaque string isn't
> included in the digest operation. There is nothing to prevent an attacker from
> learning the opaque string the server wants to see and simply coupling it with
> any digest value because the two are completely independent things. This does
> not guard against replays in any way.
> [...]
In my implementation (based on John Franks's), the server expects the
returned opaque string to match one it can calculate from the other
parameters. I don't claim to be a security or crypto expert, but I
think an adversary would have a hard time predicting what the opaque
string should be, because of the compile-time random number, if not the
timestamp.
Nevertheless, I take your point about the value of incorporating the
opaque string into the digest.
Dave Kristol