Subject: draft-ietf-sasl-crammd5-01.txt

From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Dec 2003 23:39:51 +0100

Hello, I have read the document.  Some comments:

,----
|      The client MUST prepare the user name and shared secret strings
|      using the [SASLPrep] profile of the [StringPrep] algorithm.  The
|      resulting values MUST be encoded as UTF-8 [UTF8].
`----

I suggest adding:

      The server MUST prepare the shared secret string using the
      [SASLPrep] profile of the [StringPrep] algorithm.  The resulting
      value MUST be encoded as UTF-8 [UTF8].  The server may store the
      prepared string instead of, or as well as, the unprepared
      string, so that it does not have to prepare it every time it is
      needed for computation.  However, if the original, unprepared
      string, is not stored, it may render the computed secret to be
      incompatible with a future revisions of SASLPrep that support
      currently unassigned code points (compare section 7 of
      [StringPrep]).  It is therefor recommended to store the
      unprepared string in the database.

Also, the example section is incorrect.  Suggested new version:

     S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
     C: A0001 AUTHENTICATE CRAM-MD5
     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+
     C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3
     S: A0001 OK CRAM-MD5 authentication successful

     In this example, the shared secret is the string

          tanstaaftanstaaf

     Hence, the Keyed MD5 digest is produced by calculating

          MD5((tanstaaftanstaaf XOR opad),
               MD5((tanstaaftanstaaf XOR ipad),
               <[email-masked]>))

     where ipad and opad are as defined in [KEYED-MD5] and the string
     shown in the challenge is the base64 encoding of
     <[email-masked]>. The shared secret is
     null-padded to a length of 64 bytes. If the shared secret is longer
     than 64 bytes, the MD5 digest of the shared secret is used as a 16
     byte input to the keyed MD5 calculation.

     This produces a digest value (in hexadecimal) of

          3dbc88f0624776a737b39093f6eb6427

     The user name is then prepended to it, forming

          joe 3dbc88f0624776a737b39093f6eb6427

     Which is then base64 encoded to meet the requirements of the IMAP4
     AUTHENTICATE command (or the similar POP3 AUTH command), yielding

          am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3

Perhaps it would be useful to add an example for non-ASCII strings
too, using <U+4711> or similar to indicate non-ASCII characters.

Thanks,
Simon