Re: Digest mess

>>>>> "JF" == John Franks <john@math.nwu.edu> writes:

JF> I see no problem with a single pass.  Remember the actual message
JF> headers are irrelevant for authentication purposes.  Conversely, the
JF> "origin-headers" play no role as HTTP headers, but are used only for
JF> authentication.[...]  A point worth emphasizing is that
JF> the actual HTTP headers never get used in any way in the authentication
JF> process.

>> If this is the case then the mechanism has not accomplished
>> anything.

JF> The origin-headers are used in deciding whether the transaction was in
JF> fact authenticated properly.

JF> Examples:

JF> (1) The client gets a response whose digest checks out, but with an
JF> origin-header with outdated Expires.  It knows its proxy is broken or
JF> lying or the server is broken.  A sensible thing to do would be try
JF> again and if the origin-header Expires is still outdated, then
JF> authentication fails.  The HTTP transactions were fine -- the
JF> authentication process failed.

  But it failed purely due to a flaw in the protocol - the fact that
  we used values that may be changed.  We can (I think...) design the
  protocol to not use those values so that an innocent change in a
  proxy does not affect the authentication.

JF> (2) If the client sees the proper response code in the origin-headers,
JF> it knows its PUT succeeded whatever the HTTP status code was.

JF> It is easy to think up other examples.  These are useful things.  They
JF> don't require more than one pass and something valuable has been
JF> accomplished.

  I don't agree that these are usefull examples; if I get back a
  response to a PUT whose origin-headers do not match the actual
  headers, I don't know whether or not it is a replayed response
  from an earlier successfull PUT unless I've kept all the old server
  nonces.  I have no choice but to assume that it did not succeed,
  even though in fact it may have and the proxy just messed with the
  date headers (or, heaven help us, some other dynamically included
  header!).

JF> Sigh.  Yes, a client nonce can protect against a replay attack.  We've
JF> discussed it before.  This would be a *big* change.  It breaks all
JF> existing implementations -- including the widely deployed Apache
JF> server implementation and all existing client implementations.

  All existing implementations (mine included) are already broken - we
  have established that.  They will not work on the real Internet in
  the face of proxies.  No backward-compatible solution exists.  Like
  it or not, we are talking about a new scheme now that happens to
  share as much as possible with the old one, but lacks the problem
  with proxies.  I see no alternative to admitting that, changing the
  scheme identifier and going ahead.

JF> The other changes which have been recently discussed affect only the
JF> optional Authentication-info header which is not in the Apache
JF> implementation.  I know there are a few implementations, but I know of
JF> none which are widely deployed.

  More specifically they affect the entity-digest, without which an
  attacker can just replace the entire entity body and all the
  authentication was for nothing anyway.  Authentication for POST or
  PUT is completely uninteresting without an entity digest (which was
  the motivation for adding 'digest-required').

  The key point is that there are _no_ widely deployed user agent
  implementations (with my sincere apologies and thanks to the few
  that there are), so any server implementations (again, mine
  emphatically included) are worthless (what is the sound of one hand
  authenticating?).

>>>>> BL == Ben Laurie of The Apache Group:

BL> but since something needs to be done to fix Apache anyway, I'm not
BL> averse to changing the way Digest works.

JF> I'm getting discouraged.

  I share your frustration, but this really is important.  It
  certainly is to our market - the acceptance of web based device
  management is strongly influenced by the perception of the
  insecurity of the web - forget the fact that people have been
  sending cleartext passwords over Telnet and SNMP for years.

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

Received on Tuesday, 6 January 1998 11:38:14 UTC