W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: Final Review of Digest Authentication

From: John Franks <john@math.nwu.edu>
Date: Tue, 11 Jun 1996 17:13:11 -0500 (CDT)
To: Peter J Churchyard <pjc@trusted.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960611165827.16098A-100000@hopf.math.nwu.edu>
On Tue, 11 Jun 1996, Peter J Churchyard wrote:

> The main thing I am concerned about is the lack of binding of the 
> optional entity digest to the authentication.
> 
> When the digest is for a POST/PUT type operation, the entity-digest should
> be added as an extra nonce for the response digest so if it is removed
> by an intermediate proxy/gateway the auth will fail.
> 
> For GET type requests, On the Authenticate header the server needs to be able 
> to signal that it is going to send an entity digest. This info should also
> be treated as an extra nonce so that it cannot be removed without the 
> authentication failing.
> 
> If you are not going to require the entity digest to be bound with the 
> response digest then why bother? just use content-md5hash...
> 

It is very different from a content-md5 hash.  The entity header is
effectively a digital signature.  It can only be created by one of
the parties sharing the secret (password).  If it is present then
any alteration of the content can be detected.

Of course, it could be removed by a man-in-middle.  If it is not
present then the recipient must decide whether or not to accept an
unsigned document.  This is a common way that digital signatures work.
For example e-mail with a PGP signature could be intercepted and
altered and could have the signature removed.

More elaborate and more secure schemes are certainly possible.

To quote from the specification:


  "The digest authentication scheme described in this document suffers
  from many known limitations.  It is intended as a replacement for
  basic authentication and nothing more.  It is a password-based system
  and (on the server side) suffers from all the same problems of any
  password system.  In particular, no provision is made in this protocol
  for the initial secure arrangement between user and server to
  establish the user's password.

  Users and implementors should be aware that this protocol is not as
  secure as kerberos, and not as secure as any client-side private-key
  scheme.  Nevertheless it is better than nothing, better than what is
  commonly used with telnet and ftp, and better than Basic
  authentication."




John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Tuesday, 11 June 1996 15:16:24 EDT

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