Re: more on Digest Auth

  > 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

Received on Wednesday, 21 February 1996 12:42:54 UTC