IMAP/POP AUTHorize Extension for Simple Challenge/Response
obsoleted by
- rfc-2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
Extracted elements (14)
CRAM was designed not to require per-login history records on the server, making it more suitable for IMAP where multiple simultaneous connections between a client and server are common. Mechanisms requiring per-login records would be particularly challenging to implement in that context.
Keyed MD5 (HMAC-MD5) was chosen over plain MD5 because it provides greater security for authentication of short messages. Additionally, HMAC-MD5 allows the server to store precomputed intermediate results ('contexts') instead of the cleartext shared secret, reducing exposure if the server is compromised.
The document was deliberately written to permit easy upgrading from MD5 to SHA or other alternatives when they become widely available and adequately safe, acknowledging that keyed MD5 has a limited effective lifetime.
CRAM-MD5 is intended as an improvement over APOP for POP3 use (RFC 1734) and as an addition to IMAP4 authentication (RFC 1731). The base64 encoding of challenges and responses is part of the IMAP4 AUTHENTICATE command framing, not part of the CRAM specification itself.
When the server receives the client response and the digest is correct, the server should consider the client authenticated and respond appropriately.
CRAM does not support a protection mechanism (i.e., it provides no integrity or confidentiality for the session data after authentication completes).
CRAM-MD5 is a challenge-response authentication mechanism for IMAP4 and POP3 that avoids transmitting cleartext passwords. The server sends a challenge containing random digits, a timestamp, and the server's fully-qualified primary hostname, formatted as an RFC 822 msg-id.
The client response consists of the username, a space, and a 16-octet keyed MD5 digest sent in lowercase hexadecimal. The digest is computed using HMAC-MD5 where the key is the shared secret and the digested text is the challenge timestamp including angle-brackets.
The shared secret is null-padded to 64 bytes for use as the HMAC key. If the shared secret exceeds 64 bytes, the MD5 digest of the secret is used as a 16-byte input to the keyed MD5 calculation.
A server implementing both cleartext password commands and CRAM-MD5 authentication should not allow both methods for a given user, since CRAM provides origin identification and replay protection that would be undermined by also permitting cleartext access.
Even with CRAM, users remain vulnerable to active attacks such as TCP session hijacking (as described in CERT Advisory CA-95:01). CRAM provides replay protection but does not protect against active man-in-the-middle or session hijacking attacks.
Longer shared secrets increase the difficulty of deriving the secret through brute force or dictionary attacks. The strength of CRAM-MD5 is directly tied to the entropy and length of the shared secret.
Storing HMAC 'contexts' on the server is only marginally better than storing secrets in cleartext; if the server itself is compromised, the secrets are not adequately protected. Servers storing secrets or contexts must be protected commensurate with the value of user mailbox and identity information.
The challenge is base64-encoded for use with IMAP4 AUTHENTICATE or POP3 AUTH commands. The unencoded challenge must conform to RFC 822 msg-id syntax. The client response is also base64-encoded: username + space + 32 hex characters (16-octet MD5 digest in lowercase hex).