Where we stand on Digest Authentication

          Where We Stand on Digest Authentication

I wrote a revised version of the Digest Authentication ID aimed at
meeting the objections to <draft-ietf-http-digest-aa-02.txt> on
Feb. 22.  Since that time, discussion especially with Paul Leach has
clarified some issues and I have revised the draft.  The latest
working version of the draft is available at
	http://hopf.math.nwu.edu/~john/new_rfc.txt

There is a certain amount of time pressure to come to closure on
this docuement and submit it as <draft-ietf-http-digest-aa-03.txt>.

There is one outstanding issue.  Paul Leach has proposed an optional
"nonce-incrementing" scheme be added to the draft.  This would make
the nonce no longer opaque, but add a fixed size counter at the end
which the client would be encouraged to increment each time it used
the nonce.  

So far, Paul is the only person to speak in favor of this.  In
fairness, I am the only one to argue against it.  Everyone else may
have lost interest.  Paul has offered several hypothetical
implementations which would use this feature.  I believe that I have
offered alternate implementations using the current spec without
nonce-incrementing that have the same functionality and comparable
efficiency (see below for details).  I believe that Paul agrees that
that there is no additional security from nonce-incrementing, but he
feels that there is an efficiency difference.

We agree that while this is a change in the spec, it could be done
in a way that old-client/new-server and new-client/old-server interactions
would work, but with some extra challenge response exchanges required.

At this point I would like to solicit guidance from others involved
with the digest authentication draft with the aim of arriving at
consensus.  There has been a lot of discussion and I would like to
arrive at closure.

-------------------------------------------------------------------

A Comparison of Hypothetical Implementations: with and without
Nonce Incrementing.

We briefly describe hypothetical implementations intended to
protect against replay attack.  These would be appropriate for PUT
or POST requests.  For a simple GET of a file this type of
protection does not add significantly to the security.

1.  A Per Request implementation.

With nonce-incrementing:
   Paul Leach suggests hashing the nonce value and storing the
   username, realm, expiration time, and next (incremented) nonce
   for each transaction in the hash table.  Reauthentication would 
   be required after a hash collision.  This defends against replay
   attacks.

Without nonce-incrementing:
   A functionally comparable implementation would hash the digest
   value.  This could be done with a single bit per digest by setting
   bit n in an array if the digest hashes to n.  There is no need to
   keep the username, or realm.  There is also no need to keep an
   expiration time if the hash table is divided into N sections with
   one section expiring, say every minute, and an N minute time stamp
   in the nonce.  The section of the table to check for a request is
   also encoded in the nonce.

The security of these two is identical.  The efficiency difference
of these two is probably neglible when compared to the cost of
calculating the MD5 digest.  The second might need a smaller hash
table.  The first might have somewhat fewer hash collisions.


2.  A Per Connection implementation.

With nonce-incrementing:
   Paul Leach suggests that for a single connection with multiple 
   requests a per connection structure could keep the user name,
   realm and next expected nonce.  This would be a very efficient
   way to have one-time nonces.


Without nonce-incrementing:
   An alternative would require keeping a very small per connection hash
   of digests (1 bit per digest).  If there was say a 1% chance of 
   collision then most connections would never see a collision.  A very
   few quite long connections would require re-authentication.  

The security of these two is identical.  The performance difference
between these two is probably negligible.  There is some difficulty
with either because of the fact that the server cannot predict at
the time a challenge is issued whether the response will be in the
same connection.  I believe that this would make some kind of
global nonce hashing necessary, but, in any case there is no
difference in the two versions in this regard.


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

Received on Tuesday, 27 February 1996 08:09:04 UTC