Subject: RFC2616bis todos

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Nov 2004 09:31:15 +0100

Hi,

here are two things we may want to add to the RFC2616 issues list 
(<http://skrb.org/ietf/http_errata.html>). They aren't really issues but 
action items, though:

1) Update spec so that it's based on rfc2396bis,

2) Get rid of section 2.1 (extending RFC822's BNF syntax) and update to 
ABNF (RFC2234).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Nov 2004 22:18:26 -0600

> (<http://skrb.org/ietf/http_errata.html>). They aren't really issues 
> but action items, though:
>
> 2) Get rid of section 2.1 (extending RFC822's BNF syntax) and update 
> to ABNF (RFC2234).

And, for RFC 2617, there's also the matter of clarifying the
interaction between nextnonce and session mode. I brought this up
over a year ago, but there's been virtually no discussion of
the topic.

We need to either make sure that the use of session mode is clearly
specified, or we need to remove it from the specification
altogether. The current situation -- language so ambiguous that
it leads to interoperability problems -- is untenable. I'm really
just asking for one sentence to clear up behavior upon receipt of
a nextnonce when session mode is being used. I don't care what it
says; I just want it to be clear.

-------------------------------------------------------------------
[Repost from 9/2003 follows]

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.

/a