Re: HTTP Bar BoF

On the same subject, MD5 is effectively DoA.  Even sha1 will be officially
phased out from the FIPS stack by 2010.  So it's apparently time to provide
that digest authentication hashes can elect more effective hash spaces, e.g.
SHA-256 or SHA-512, etc.

Something to ponder, there will be a draft/experimental implementation in
the Apache httpd sandbox shortly, for purposes of discussion, and I'll post
the corresponding suggested semantic here for such an extension.

Bill

Adam Roach 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.
> 
> I *did* get Scott to understand the problem at one point in time, circa 
> 2004. There *is* a problem here. The fix is minor. If we're revising the 
> document, can we *please* make this unambiguous so that implementors 
> have some chance of interoperating?
> 
> Unfortunately, I have prior commitments that prevent me from attending 
> the BOF.
> 
> /a
> 
> Mark Nottingham wrote:
>>
>> It seems like a fair number of people are interested in this, so:
>>
>> 2) Errata Candidates <http://skrb.org/ietf/http_errata.html>
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Ambiguity with MD5-sess and nextnonce
> From:
> Adam Roach <adam@dynamicsoft.com>
> Date:
> Mon, 8 Sep 2003 14:46:12 -0500
> To:
> "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>
> 
> To:
> "'ietf-http-wg@w3.org'" <ietf-http-wg@w3.org>
> 
> 
> 
> In implementing MD5-sess, we've encountered some
> ambiguities with the interaction between MD5 sessions
> and nextnonce.
> 
> The only description of signaling the end of an
> authentication session is in section 3.3. In particular,
> it says that an authentication session lasts until the
> client receives another WWW-Authenticate header.
> 
> Presumably, the session ends at this point because
> the nonce has changed. Using this logic, the authentication
> session should also terminate if the client receives a
> response with an Authentication-Info header containing a
> nextnonce parameter.
> 
> Termination of a session with nextnonce isn't mentioned
> anywhere, though -- so it's not clear whether this was
> the intention when the RFC was written. In particular, it's
> not clear to me what value changing a nonce within the
> same session would provide.
> 
> To be specific, when using MD5-sess, the proper client
> behavior upon receiving nextnonce is not particularly clear.
> To illustrate the ambiguity, I'll demonstrate the exact
> issue with a use case.
> 
> 1) Client sends a request.
> 
> 2) Server challenges request, with an algorithm of "MD5-Sess".
>   We will call the nonce sent in this challenge "nonce-value-1".
> 
> 3) Client re-sends request, with response to challenge. This response
>   includes a cnonce, which we will call "cnonce-value-1". The
>   response is calculated as follows:
> 
>   KD(H(unq(username-value) ":" unq(realm-value) ":" passwd)
>      ":" unq(nonce-value-1) ":" unq(cnonce-value-1),
>      unq(nonce-value-1) ":" nc-value ":" unq(cnonce-value-1) ":"
>      unq(qop-value) ":" Method ":" digest-uri-value)
> 
> 4) Server responds to request with a 200 response. This response
>   contains a new nonce in a nextnonce parameter. We will call
>   this value "nonce-value-2".
> 
> 5) Later, the client sends a second request. It preemptively includes
>   an "Authentication" header with a cnonce that we will call
>   "cnonce-value-2".
> 
> Here's where the confusion lies. For the highest chance of success,
> should the client calculate the response-digest as:
> 
> A) KD(H(unq(username-value) ":" unq(realm-value) ":" passwd)
>      ":" unq(nonce-value-1) ":" unq(cnonce-value-1),
>      unq(nonce-value-2) ":" nc-value ":" unq(cnonce-value-2) ":"
>      unq(qop-value) ":" Method ":" digest-uri-value)
> 
> or as:
> 
> B) KD(H(unq(username-value) ":" unq(realm-value) ":" passwd)
>      ":" unq(nonce-value-2) ":" unq(cnonce-value-2),
>      unq(nonce-value-2) ":" nc-value ":" unq(cnonce-value-2) ":"
>      unq(qop-value) ":" Method ":" digest-uri-value)
> 
> The text in the document would support A (since only WWW-Authenticate
> ends an authentication session and H(A1) "is calculated only once" per
> authentication session), while B seems far more intuitive.
> 
> So, what have people here actually implemented?
> 
> /a
>

Received on Wednesday, 12 July 2006 19:13:46 UTC