Re: Digest mess

>>> RF == "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>

RF> I think the time has come to declare Digest as dead.  Dead because
RF> it was stuffed with featuritis in an attempt to solve multiple
RF> authentication and security concerns instead of the only one for which
RF> it was originally designed.

  Whoa; we have, for the first time, gotten a major client to say that
  they may implement it and we have several protocols being layered on
  HTTP that are specifying it as required.  There are definitly
  problems, but let's not get frustrated by them, let's solve them.

  I share your concern with respect to feature creap, and will go on
  the record now as opposed to _any_ change that does not directly
  serve the authentication goal.  Applications are using Basic today
  without any prompts; they live without it with digest.  If an
  application really wants to display explanations or reminders, they
  can have an entire unauthenticated page to get it - it is not
  required to prevent passwords being sent in the clear on the
  Internet; let's not loose sight of that goal.

  However, some entity digest capability is absolutely required
  because it is the message we are authenticating - it does no good to
  send credentials if the entity is not tied to them.

PL> Fundamentally, good crypto practice says that EVERYTHING should be in the
PL> digest. It is almost impossible to figure out every possible attack that
PL> someone might make by being able to modify an undigested field, so the only
PL> safe thing to do is digest them all.

  But we also face the backward compatibility problem - we know
  for sure that the current scheme is broken in the face of proxies.

RF> Service degradation is not an issue -- that can be accomplished more
RF> effectively by changing the digested part so that it no longer matches
RF> the digest and thus force a reset of the whole process.

  I agree that service degradation and cache efficiency should not be
  our concern here - what is desperatly needed is a lightweight
  mechanism for authentication, and if that means that caches can't
  cache, well so be it.

  I posted a proposal last Friday

    http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0390.html

  to simplify the entity digest calculation by removing all the
  metadata headers; should I rewrite this in the form of an Internet
  Draft, or can we just debate it and possible other solutions here?

Received on Tuesday, 16 December 1997 06:56:16 UTC