Subject: Some DIGEST-MD5 nits

From: Simon Josefsson <[email-masked]>
Date: Sun, 19 Dec 2004 00:21:57 +0100

Hi Alexey, all.  Some random notes on -04:

In the challenge, it doesn't say what should happen when "cipher"
occur more than once, I guess adding this:
      <<What if this directive is present multiple times? Error, or take
      the union of all values?>>
would be useful, to mimic the qop-options field, until the issue is
resolved fully.  IMHO, multiple directives should be rejected.

In the "response" token, it says that "realm" values SHOULD match the
realms offered by the server.  Given that the challenge "realm" text
now require UIs to offer to enter a different realm, maybe the SHOULD
could be relaxed to a MAY?

For the "response" token nonce-count value, I suggest describing that
authentication MUST fail if the value is 0.  I.e., replace the final
sentence with:
   This directive is required and MUST be present exactly once;
   otherwise, or if the value is 0, authentication fails.

The response authzid doesn't say what should happen if multiple
occurrences are encountered, I suggest to replace the first sentence
with:
   This directive may appear at most once; if multiple instances are
   present, the client MUST abort the authentication exchange.

The response digest-uri field seem to be indented incorrectly.

The challenge "charset" field doesn't say what happen when it is sent
when not needed (i.e., server announced charset field in response), or
not sent when needed.  I suggest failing authentication in both cases;
clients must already support UTF-8 so it doesn't make sense to allow
clients to use ISO-8859-1 when the server has announced support of
UTF-8.

If the finishing response-auth token is changed to allow for optional
tokens, there should be a size limit on it as well, I suggest:
   The size of a response-auth MUST be less than 2048 bytes.

One of the open issues in the document are:
   1). The latest revision prohibits escaped characters in nonce/cnonce.
   This is different
       from HTTP Digest. Any objections?
If DIGEST-MD5 is different from HTTP Digest, why not limit
nonce/cnonce to printable ASCII characters?  I wonder how many
implementations handle nonce/cnonce strings with ASCII #0 or #255.  If
the rationale for breaking backwards compatibility is to reduce code
complexity, why not really reduce complexity by forbidding #0.  If
code complexity wasn't the rationale, what is?

The SASLprep discussions should mention, for each string, whether the
output string may contain unassigned code points or not.

Thanks,
Simon

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 20 Dec 2004 11:26:56 -0800

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Simon Josefsson
> Sent: Sunday, December 19, 2004 7:09 PM
> To: [email-masked]
> Subject: Re: Some DIGEST-MD5 nits
> 
> 
> A few additional notes:
> 
> I suggest making AES the mandatory to implement cipher.  Currently,
> there is no reference for rc4 in the document, there are papers on
> weaknesses (such as Wagner's [1]), and there is no discussion in the
> current document how to deal with Shamir's findings (see [2]).
[Paul Leach] I would suggest that either RC4 be deprecated, or that a
new RC4-based cipher specifier be added that discards the first 256
bytes of the RNG. If the latter is the choice, security considerations
should be added referencing the above, and noting that discarding 256
bytes handles the problems.