Subject: RFC 2617 errata / MD5-sess

From: [email-masked]
Date: Wed, 9 Aug 2006 17:22:02 +0000

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

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Thu, 10 Aug 2006 09:12:50 -0700

> rfc 2617 and the MD5-sess algorithm described there.

My own concern, if the MD5-sess dialog is reopened, is to account for
the complete dismissal of MD5 for any authn/authz security applications
and to reopen the spec to extending the noonce to SHA1 / SHA2 semantics.

MD5 is already past it's prime, and SHA1 is heading that way as well.
It would be good to anticipate future hash support by adding anything
of SHA2 up to SHA-512 and providing for an extensible description of
the negotiated hash employed for this purpose.

---

From: Ingo Struck <[email-masked]>
Date: Thu, 10 Aug 2006 17:02:52 +0000

William,

> the negotiated hash employed for this purpose.
First, rfc2617 explicitly states that it is not and does not want to
be a cryptographically strong authentication mechanism (it only wants
to substitute the completely unacceptable plain-text-password basic-auth)

Second, I don't think that the hash employed does make any difference
regarding the problem with the clarification X vs. X-sess
(given X is any hash-function). The mechanism and the parts involved
calculating the session key HA1, the target key HA2, and the response
could remain the same if you alter the hash-function.

The rfc already allows for the employment of any different algorithm
both server and client understand, see section 3.1.3, 3.2.1 and the
bnf of that section:
  algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token )

The rfc could, however, demand that any implemented hash-function
- calculates hashes over the same values like described, i.e.
  that only H(x)=MD5(x) may be substituted, but the underlying parts
  used to calculate the hash MUST remain the same (including their order)
- supports both modes, namely HA and HA-sess (with HA the new hash-function)
In bnf this could read similar to:
  hashfunction = ( "MD5" | token )
  algorithm = "algorithm" "=" ( hashfunction | hashfunction "-sess" )
where token may be the name of any other hash function.

If the rfc would require just this, any existing implementation could simply
switch the underlying hash function without further modifications.
It could be considered to use a more compact representation to transfer
longer hashes (e.g. base64 instead of HEX), but this would introduce the
need for more modifications to switch to a new algorithm.

Kind regards

Ingo Struck

---

From: Paul Leach <[email-masked]>
Date: Fri, 11 Aug 2006 01:04:36 +0000

The statements about strength in 2617 refer to the strength of any
password based mechanism compared to public key mechanisms. The strength
of Digest should be only limited by the strength of the password -- if
we continue to use weak hash schemes, that won't be true.

(Not to mention that in some cases, strong random passwords can be used,
and these will be as strong as the hash. We shouldn't rule these cases
out needlessly.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ingo Struck
Sent: Thursday, August 10, 2006 10:03 AM
To: William A. Rowe, Jr.
Cc: [email-masked]
Subject: Re: RFC 2617 errata / MD5-sess

William,

On Thursday 10 August 2006 16:12, William A. Rowe, Jr. wrote:
> the complete dismissal of MD5 for any authn/authz security 
> applications and to reopen the spec to extending the noonce to SHA1 /
SHA2 semantics.
> the negotiated hash employed for this purpose.
First, rfc2617 explicitly states that it is not and does not want to be
a cryptographically strong authentication mechanism (it only wants to
substitute the completely unacceptable plain-text-password basic-auth)

---

From: Ingo Struck <[email-masked]>
Date: Fri, 11 Aug 2006 07:22:07 +0000

Paul,

> and these will be as strong as the hash. We shouldn't rule these cases
I completely agree with this -- that's why I proposed that the
rfc should only demand the way how (and when!) the hashes are
to be calculated, not which hash functions have to be used.
Of course it would be silly to demand that implementations should
use weak hashes -- I thought to have pointed out, that the rfc in
fact does not demand this, but just uses md5 as a sample implementation
(and provides for different algorithms).

However, the problem with plain headers without integrity check,
opening up digest auth for simple mitm-attacks (section 4.8), 
still remains.

imho there is no much point using the strongest hashes available
as long as implementations are vulnerable to such a simple thing
like tricking the client to use basic auth (i.e. plaintext passwords)
and thus to reap the credentials much easier than to crack the hash.

Kind regards

Ingo Struck