IMAP/POP AUTHorize Extension for Simple Challenge/Response
obsoletes
- rfc-2095 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
Extracted elements (16)
CRAM was designed to avoid requiring the server to maintain per-login history records, which is advantageous for protocols like IMAP that may have several simultaneous connections between a given client and server.
Keyed MD5 (HMAC-MD5) was chosen because of the greater security imparted to authentication of short messages, and because precomputation of intermediate 'contexts' allows the server to avoid storing the shared secret in cleartext.
The document was deliberately written to permit easy upgrading to use SHA or other hash alternatives when they become widely available and adequately safe, anticipating the limited effective lifetime of MD5 in authentication.
CRAM does not support a protection mechanism (i.e., no integrity or confidentiality protection of the session data after authentication).
CRAM-MD5 is intended for use with both the IMAP4 AUTHENTICATE command and the POP3 AUTH command, and may constitute an improvement over APOP for POP3 use since it does not require the shared secret to be stored in cleartext on the server.
If the digest provided by the client is correct, the server should consider the client authenticated and respond appropriately.
The digest is computed by applying the Keyed MD5 algorithm (HMAC-MD5 per RFC 2104) where the key is the shared secret and the digested text is the timestamp including angle-brackets.
The shared secret is null-padded to a length of 64 bytes before use as the HMAC key. 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.
The authentication type name for this mechanism is 'CRAM-MD5', used with the IMAP4 AUTHENTICATE command and the POP3 AUTH command.
The server's first ready response contains a challenge whose unencoded form must correspond to an RFC 822 'msg-id': a presumptively arbitrary string of random digits, a timestamp, and the fully-qualified primary host name of the server enclosed in angle-brackets.
A server that implements both a cleartext password command and CRAM-MD5 should not allow both methods of access for a given user, as mixing them undermines the security benefits of CRAM.
As the length of the shared secret increases, the difficulty of deriving it increases; longer secrets provide stronger security.
Even with CRAM, users remain vulnerable to active attacks such as TCP session hijacking (as described in CERT Advisory CA-95:01); CRAM provides origin identification and replay protection but not session integrity.
Storing server-side 'contexts' (precomputed HMAC intermediate values) is marginally better than storing shared secrets in cleartext, but is not sufficient to protect secrets if the server itself is compromised; servers must be protected to a level appropriate to the value of user mailboxes and identities.
The challenge and response strings are base64-encoded when used with the IMAP4 AUTHENTICATE command or the POP3 AUTH command; the base64 encoding is part of those outer protocols, not part of CRAM itself.
The client response consists of the user name, a space, and a digest. The digest is a 16-octet Keyed-MD5 value encoded in hexadecimal using lower-case ASCII characters.