Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

Robert, Larry,

> How about creating a separate document which "updates"
> RFC 2617, describes the feature completely, and then
> pushing it out as "proposed standard" quickly?
>
> Should take much less time than the RFC 2617 update.
Sounds like a good idea.

> No, it's a feature by feature test. Basic works for some people some
> of the time, and MD5-sess doesn't. The cause is irrelevant. It could
> be that the spec is too difficult to implement, the spec is not worth
> implementing, the specified protocol doesn't work at all, or that
> browser engineers are dumb. It doesn't really matter--the document is
> really old by now, and the workable parts are clear.
I completely agree with that last statement --
the workable parts are clear and the spec (especially as a
draft document) is quite old. From a practical point of
view you are right with the feature-by-feature check; the
MD5-sess stuff does not work right now. Still it could,
however, circumvent some problems with basic and "simple" digest
auth (e.g. the "eternally-logged-in-problem" moz bug 355319)
if properly implemented.

But maybe it's really time to drop the non-used (or unusable)
parts to have a slight chance to advance the standardisation
state of that rfc and to grind out coherent, interoperable 
implementations within the next, say five to seven, years.

It seems that people agree that the rfc is at least hard
to read -- the reality check with existing implementations
shows that it is hard enough to read to prevent a large number
of implementations that share the same interpretation of the spec.

My proposal would be to create an "updated" document that
at least
- determines the parts to be incorporated into a digest
  (including their encoding and order - only ONE definite
  order, only ONE definite encoding)
- leaves open the hash function used, requiring "at least"
  the implementation of the MD5 hash function (although 
  "outdated" too from a cryptology point of view, but halfway
  proved to be interoperable)
- makes the hash functions that may be used
  subject to an IETF registry (like mime-types) with an
  initial registry of e.g. md5, sha1 and blowfish (note,
  these are to be read as an *example*)
- moves out the "sessionized" version of the scheme to a
  different document
- renders "basic" obsolete as a potential risk (because it means
  clear text passwords, a fact still not well understood by 
  implementors; I still find scores of discussions referring to
  "base64-encryption" which is plain wrong)

This would basically be a cut-down and tightened form of
rfc2617, without the introduction of any new features
that harden the authentication scheme.

To widely establish a better authentication scheme, like
the one Robert proposed at 
http://www.franklinmint.fm/blog/archives/000843.html
(especially incorporating the headers into the digest
is an essential improvement) I would resume with the completely
new "line" of documents started by Robert's (lately expired)
http://www.ietf.org/internet-drafts/draft-sayre-http-hmac-digest-01.txt

I am not sure where best to publish a "cut-down-update" of
rfc 2617 informally for public review... Any recommendations?

Kind regards

Ingo Struck

Received on Monday, 16 October 2006 21:51:32 UTC