RFC 2095 (rfc2095) - Page 3 of 5

IMAP/POP AUTHorize Extension for Simple Challenge/Response

RFC 2095              IMAP/POP AUTHorize Extension          January 1997


   CRAM does not support a protection mechanism.

   Example:

   The examples in this document show the use of the CRAM mechanism with
   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
   the challenges and responses is part of the IMAP4 AUTHENTICATE
   command, not part of the CRAM specification itself.

     S: * OK IMAP4 Server
     C: A0001 AUTHENTICATE CRAM-MD5
     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
     S: A0001 OK CRAM 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 protected]>))

      where ipad and opad are as defined in the keyed-MD5 Work in
      Progress [KEYED-MD5] and the string shown in the challenge is the
      base64 encoding of [email protected]>. 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

           b913a602c7eda7a495b4e6e7334d3890

      The user name is then prepended to it, forming

           tim b913a602c7eda7a495b4e6e7334d3890

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

           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw








Klensin, Catoe & Krumviede  Standards Track