Re: RFC 2617 errata / MD5-sess

William,

On Thursday 10 August 2006 16:12, William A. Rowe, Jr. wrote:
> 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.
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

Received on Thursday, 10 August 2006 17:19:33 UTC