Re: Digest mess

  This entire discussion has, I think, become a bit muddied as to just
  what we are trying to acheive.  I believe that the goal can be
  simply stated as:

    The Digest Access Authentication scheme is intended to provide a
    mechanism for HTTP clients and servers to authenticate messages
    without transmitting credentials in a way that allows for thier
    substitution or reuse by an eavesdropper or relay.

  We found that use of RFC 2069 Digest Authentication through a
  correctly operating proxy could fail (that is, authentication fails
  even though the parties sent authenticators using valid credentials)
  because the proxy may modify or insert headers that affect the
  digest value.  The headers in question were included in the digest
  calculation in order to prevent replay attacks.

  We then progressed to discussion of various mechanisms for adjusting
  the calculation of the digest values to make it robust in the face
  of changes by proxies.  This has now begun to evolve into a much
  more complex mechanism for digesting arbitrary headers, even when
  those headers may also have been modified by proxies.  If we
  continue along this line, we will pretty quickly discover that we
  have reinvented SHTTP and are wrapping all the response headers (not
  that I have a problem with SHTTP, but it has already been invented).

  If this is to be robust and widely implemented, I think that it
  needs to be simpler, not more complex.  For example, I would like to
  be able to implement it in a single parsing pass over the message,
  which is certainly impossible if arbitrary headers may be included
  by an attribute in a field that may be sent in a trailer.

  Getting back to the original problem - the prevention of the replay
  of a valid message in response to a different request.  The server
  can already prevent replay of a past client message by changing the
  nonce value included in the challenge.  I believe that we can
  similarly protect the client by allowing it to provide its own nonce
  which the server must use in sending the response.  The client can
  then detect any replay while only needing to remember the
  nonce value for outstanding requests, and even a man in the middle
  cannot create authenticated messages without the original
  credentials.

  We might then be able to remove all or most of the header fields
  from the entity digest calculation, simplifying the digest
  processing and avoiding problems with proxies even with headers
  defined in the future.  I think that we could use just Content-Type
  and the HTTP response code.

  We can also specify the usual generic extentions for the
  authentication header fields, allowing protocols (such as WEBDAV)
  built on HTTP to specify additional attributes to be passed to
  protect specific essential header information.

  All this does imply that a substantial rewrite of the authentication
  spec would be required, but a number of people have already pointed
  out on this list various ways in which the merger of the Basic and
  Digest specs was not as smooth as we'd all like it to be.  I am
  happy to volunteer to help.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Tuesday, 6 January 1998 07:22:47 UTC