RFC 2617 errata / MD5-sess

Hello Scott, Adam, wg-list,

I just want to give some input to the discussion about
rfc 2617 and the MD5-sess algorithm described there.
This is what you wrote recently and some time ago:

====
Adam wrote
> Three years ago (and periodically since then), I have raised an issue 
> around ambiguity relating to the handling of md5-sess in RFC2617.
> This is complicated. The explanation of what is wrong takes a lot of 
> reading and a *lot* of thought. I'm sorry about that.
and some time ago:
> If we're opening this section for revisions, can we please
> also address the issue of whether the session key is recalculated
> when the server sends an Auth-Info header with nextnonce?
Scott responded
> I don't think that is ambiguous given the current text.  If the server
> sends a nextnonce, then it wants the client to start using it.  I
> don't think that servers that are choosing to use MD5-sess mode will
> do that very often, but that is a different question and not one that
> a standard needs to or should address.
===

Personally I don't think that this is ambiguous
(at least if you read the spec carefully).

But the number of b0rken implementations out there that I found
clearly shows the contrary.

The rfc does not effectually communicate
- that the session key MUST only be calculated once,
  using the first nonce/cnonce pair within the session
- when the session ends and a new one should be created

I found numerous client implementations where the session key
is recalculated for every new cnonce the client issues.
This is clearly against the spec, but reading the example implementation
without understanding section 3.2.2.2 obviously suggested to implementors
(e.g. mozilla, kio-http) to recalculate the session-key for every request.

IMHO a clarification and/or example would serve the primary goal
of a spec (i.e. create a real consensus amongst real implementations,
not only the outline of a theoretical consensus) far better than
to abide by a formulation that has proven to be prone to misinterpretation.

The formulation (or the lack thereof) what MD5-sess wants to be
and how it should be implemented clearly lead to implementations
which claim to be according to the spec, but which violate it.

This cannot be the aim of any spec.

Kind regards

Ingo Struck

Received on Wednesday, 9 August 2006 17:20:17 UTC