Subject: CRAMing for last call

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:02:54 -0700

Now that 2222bis is close to reality, I would like to push the final 
version of CRAM out as well. The two documents should be able to go 
through together, (I hope) making life easier for the RFC editor.

I have some non-substantive editorial changes that will make the 
document a bit easier to read, but these are not show stoppers. I think 
all of the last round of comments are addressed in the current draft. 
If not, I would like to hear from people, soon.

I would also like to solicit a few additional examples from anyone who 
has implemented CRAM in other than IMAP.

Finally, we need to address the issue of the MD5 "break." I have held 
off from commenting on this issue until the community has seen explicit 
evidence of the attack, and the implications of it. At this point, I 
don't know if the document deserves a writeup on the attack. Theory 
abounds, but I haven't yet seen a practical attack that works in the 
general case. We should at the least make mention of what has been 
discussed, and point to the literature, but I don't think the document 
deserves to discuss all the possible attacks. This doesn't mean to 
discourage anyone from contributing text to the Security Considerations 
section (please do).

The IMAP-EXT list has had recent discussion that points out the 
ambiguity of searching for the space (SP) separator (between the user 
id and the digest) as being the rightmost SP, so I will strengthen that 
text. Any other comments should come forth soon as I would like to run 
out the final draft at the end of next week (Oct. 8) if I can.

Cheers,

--lyndon (editor)

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:58:59 -0400

>>>>> "Lyndon" == Lyndon Nerenberg <[email-masked]> writes:

    Lyndon> Finally, we need to address the issue of the MD5 "break."
    Lyndon> I have held off from commenting on this issue until the
    Lyndon> community has seen explicit evidence of the attack, and
    Lyndon> the implications of it. At this point, I don't know if the
    Lyndon> document deserves a writeup on the attack. Theory abounds,
    Lyndon> but I haven't yet seen a practical attack that works in
    Lyndon> the general case. We should at the least make mention of
    Lyndon> what has been discussed, and point to the literature, but
    Lyndon> I don't think the document deserves to discuss all the
    Lyndon> possible attacks. This doesn't mean to discourage anyone
    Lyndon> from contributing text to the Security Considerations
    Lyndon> section (please do).

The security area seems to believe that hmac-md5 is still OK, at least
for now.  Especially since cram-md5 does not require much structure
for the challenge, we should discuss the issue in the security
considerations section.

Will you need agenda time at the next meeting?  If so, can you give an
estimate of how much and what we want to cover?

Thanks,

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 00:55:10 +0200

Hello.  Some comments on the latest cram-md5 draft.

In this post:

http://thread.gmane.org/gmane.ietf.sasl/1457

Kurt suggest to explain why the IANA USAGE field of CRAM-MD5 is
LIMITED.  I too believe this would be useful, to make readers realize
they might want PLAIN+TLS, DIGEST-MD5 or GSSAPI instead.

There are a few (minor, mostly editorial) suggestions in Kurt's post
that has not been addressed, that I believe make sense.

Next, I believe it would be useful to tighten up the language in the
following paragraph:

   The mechanism starts with the server issuing a challenge.  The data
   encoded in the challenge contains a presumptively arbitrary string of
   random data.

I suggest to remove "presumptively arbitrary" and add a reference to
RFC 1750 after the word "random".  Possibly it could be worded
differently, because there is quite some structure in the challenge,
not complete random data.  I read RFC 2104, but it does not say
anything about randomness or structure of the challenge text.  It may
be useful to find some other reference on the properties of challenge
strings in CRAM-MD5, or to ask the CFRG for guidance.

Next, there were discussion regarding SASLprep unassigned code points
in this thread:

http://thread.gmane.org/gmane.ietf.sasl/1342

I agree with Kurt that it should be clarified that the client copy of
the user name and shared secret should be defined as query strings.  I
think this would be achieved by adding after:

   The client MUST prepare the user name and shared secret strings using
   the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep
   [RFC3454] algorithm.

the following:

   The client MUST treat the user name and shared secret string as
   query strings, consequently unassigned code points should be
   allowed in the prepared output.  The server MUST treat the received
   user name, and the password (regardless of whether it is in
   unprepared, prepared or hashed form), as stored strings, and
   consequently disallow unassigned code points in the prepared output
   that is used as input to the keyed hash operation.

Without such text, there is an ambiguity how to invoke SASLPrep.  I
believe the text belong in CRAM-MD5, as string preparation is a
mechanism issue.  It does not seem to belong in SASLPrep or 2222bis.

Further, RFC 2279 has been obsoleted by RFC 3629:

   The resulting values MUST be encoded as UTF-8 [RFC2279] strings.

I suggest adding a paragraph break after the previous sentence, and
the generic recommendations on storing prepared strings.

Next, because CRAM-MD5 do not provide a security layer, it should have
a reference to TLS and some security consideration suggesting TLS, or
similar, if active attacks or privacy issues are a threat.  Compare
PLAIN.

Finally, RFC 2104 is INFORMATIONAL.  Can it be a normative reference?

Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:57:39 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Finally, RFC 2104 is INFORMATIONAL.  Can it be a normative
    Simon> reference?

Yes.  Recently a BCP on dealing with this was published.

--Sam

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 27 Oct 2004 16:23:50 -0700

> Yes.  Recently a BCP on dealing with this was published.

Don't Panic!™

Due to a seemingly-imminent disk failure on my laptop, I pushed out a
preliminary version of the draft (as a backup measure more than 
anything).
There will be another rev after the IETF, containing the editorial 
changes
I've previously alluded to. The references will be fixed as part of 
that update.
(And, I hope, the presentation/stored strings issues.)

--lyndon

---

From: Sam Hartman <[email-masked]>
Date: Sat, 02 Oct 2004 14:58:59 -0400

Thanks,

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Oct 2004 00:55:10 +0200

In this post:

the following:

Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Oct 2004 17:57:39 -0400

--Sam

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 27 Oct 2004 16:23:50 -0700

Don't Panic!™

--lyndon