Re: Some comments on Digest Auth

>>>>> "PL" == Paul Leach <paulle@MICROSOFT.com> writes:

PL> If the servers keep no state, and just accepts the nonce that the client
PL> quotes back at it, then you get no replay protection at all.

  This is something of a digression, but it _is_ possible for the
  server to construct nonces which are not reusable and which require
  no per-nonce state in the server.

PL> But I think we should specify that it MUST contain a timestamp, if
PL> that's all the replay protection we're going to have. And we could
PL> specify that the client include a timestamp in the nonce...
PL> [description of nonce generation rules using timestamps]

  First, I must repeat my favorite refrain: Not all HTTP
  implementations have clocks - you can't require the use of
  timestamps.

  More important for the current discussion... the standard should not
  specify how nonces are constructed.  There are very good reasons for
  this:

    - Any specified algorithm (no matter how clever) tells an attacker
      how the nonce space is limited, thereby weakening the security.

    - RFC 2069 specifies that the nonce may be constructed in any way
      the server chooses, and specifies that the client just uses that
      value.  Any change that requires specific algorithms for either
      will break existing deployed implementations.

  If we are going to break existing implementations, then it seems to
  me that we should just forget the current spec altogether and go on
  to digest-ng (which I don't think we can get done soon enough to
  make the IESG happy with advancing 1.1).

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

Received on Wednesday, 21 January 1998 07:12:29 UTC