Re: more on Digest Auth

On Wed, 21 Feb 1996, 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.
> An Authenticate for one server is unlikely to work for another.
> 

This is the algorithm in my prototype implementation.  Incidentally the
source code of this is in the public domain and available via
	http://hopf.math.nwu.edu/digestauth/index.html
This is designed for use with the WN server but may be of interest to
others.

Here is an excerpt from the README:

   "This implementation has several interesting features which are not
   part of the specification but are made possible by the flexibility of
   the proposed method.  

     1. Timestamps:  The maintainer can set the time period for which
     authentication granted the client is valid.  After this time period
     the client will have to re-authenticate.   The time period can be
     set to any number of seconds (or be unlimited) and is accurate to
     within 1% of the specified value.  The timestamp is encoded in the
     "opaque" header field (see the specification).

     2. IP address stamps:  The IP address (or the IP address of the
     client's proxy) is encoded in the "opaque" header field.  This means
     that a replay attack would have to spoof the server with a false
     IP address."


At the time digest design was being discussed I argued for timestamps
and hashing the IP address, but was overruled.  Nevertheless, I was
satisfied since the protocol allows any implementation to add the 
features I want via the opaque string.  Other implementations can
add additional safeguards like the ones above and they will interoperate
with clients supporting the protocol.  I think this is a feature.

Someone on this thread mentioned a problem with clients reusing 
passwords and mentioned the need for more than username, password and
nonce to be hashed for the response.  More *is* hashed.  The realm
(which should contain the hostname) is also part of what gets hashed.
Thus the same password on different servers could only be a problem
if two servers used the same realm (presumably one host would be 
claiming to be the other).  Nonces by the way are opaque integers.
In my implementation they are modified random numbers.  Another
implementation could use a hash of a secret key + whatever and
convert the result to a large integer.  (I think integer in this
context only means digit string).

The reason it would be  rather difficult to change the protocol now
is that it is already in widespread use.  It is in all the current
versions of browsers from Microsoft and NCSA.

For better or worse the current draft leaves a lot up to the
implentation.  It is possible to have an implementation that is not
much more secure than Basic.  It is also possible to have an
implementation that addresses all of the issues raised in this thread,
plus some more.  The current protocol is not exactly the way I would
have done it if all the decisions were up to me, but as everyone in
this discussion is aware we sometimes have to make compromises.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 21 February 1996 07:11:13 UTC