RFC 2195

RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response 🎀

Okay bestie, here's the paperwork 📋. This one's from the Network Working Group, written by J. Klensin, R. Catoe, and P. Krumviede, all at MCI 💼. It's a Standards Track doc from September 1997 ✨. It obsoletes RFC 2095 🔄.

Status of this Memo 📋

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🙏. For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Abstract ✨

Okay so IMAP4 has a bunch of strong auth mechanisms from RFC 1731 💪, but there's no option that avoids sending cleartext, reusable passwords over the network 😭. And the ones that do avoid that need a major security infrastructure, or the mail server has to update a mail-system-wide user auth file on every single access 💀. This spec gives a simple challenge-response auth protocol that works with IMAP4 🦋. It uses Keyed-MD5 digests and doesn't need the secret stored in the clear on the server 🔐, so it might also be an upgrade on APOP for POP3 from RFC 1734 👑.

1. Introduction 🧚

So there are already Proposed Standards for an AUTHENTICATE mechanism in IMAP4 [IMAP, IMAP-AUTH] and a parallel AUTH mechanism in POP3 [POP3-AUTH] 📮. AUTHENTICATE is meant to be extensible 🔧, and the four methods in [IMAP-AUTH] are all pretty powerful, but they need some security infrastructure to run 🏗️. The base POP3 spec [POP3] also has a lightweight challenge-response thing called APOP 🫠. APOP comes with most of the usual risks for this kind of protocol. Like, it needs both the client and server machines to have the shared secret in cleartext 😬. CRAM is the glow-up 💅: it avoids that cleartext storage, keeps APOP's simple algorithm, and only uses MD5, but in a "keyed" way 🔑.

IMAP [IMAP] doesn't have anything like APOP right now 🥲. The only other option next to the strong mechanisms in [IMAP-AUTH] is a presumably cleartext username and password through the LOGIN command in [IMAP] 🙃. This doc describes a simple challenge-response mechanism, similar to APOP and PPP CHAP [PPP], that works with IMAP and, in principle, with POP3 too 🌸.

This mechanism also has an advantage over some other options: the server doesn't have to keep info about email "logins" on a per-login basis 🙌. Mechanisms that do need those per-login history records might be more secure 🤔, but protocols like IMAP can have several connections open between a given client and server at more or less the same time 🌀, and that can make those records really hard to implement 😵‍💫.

2. Challenge-Response Authentication Mechanism (CRAM) 🔐

The auth type for CRAM is "CRAM-MD5" 🎀.

The data in the first ready response is a presumptively arbitrary string of random digits 🎲, plus a timestamp ⏰, plus the fully-qualified primary host name of the server 🖥️. The unencoded form has to match an RFC 822 'msg-id' [RFC822], as described in [POP3] 📝.

The client takes note of the data, then replies with a string made of the user name, a space, and a 'digest' ✨. The digest comes from running the keyed MD5 algorithm in [KEYED-MD5] 🧮, where the key is a shared secret and the digested text is the timestamp (with the angle-brackets included) 💜.

The shared secret is a string that only the client and server know 🤫. The digest parameter is a 16-octet value, sent in hexadecimal format with lower-case ASCII characters 🔡.

When the server gets the client's response, it checks the digest 🕵️‍♀️. If the digest is correct, the server should consider the client authenticated and respond appropriately 🎉.

Keyed MD5 is picked for this because it gives more security for authenticating short messages 🛡️. Also, the precomputation techniques in [KEYED-MD5] mean the server can store intermediate results, called "contexts", instead of the shared secret in cleartext 🧠. Those contexts make it possible to avoid explicit cleartext storage of the secret on the server system 🙌.

CRAM doesn't support a protection mechanism 🚫.

Example:

The examples here show CRAM used 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 spec 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' 🤍. So the Keyed MD5 digest is produced by calculating:

MD5((tanstaaftanstaaf XOR opad),
    MD5((tanstaaftanstaaf XOR ipad),
    <1896.697170952@postoffice.reston.mci.net>))

where ipad and opad are as defined in the keyed-MD5 Work in Progress [KEYED-MD5] 🧩, and the string in the challenge is the base64 encoding of <1896.697170952@postoffice.reston.mci.net> 🔤. 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 gives a digest value (in hexadecimal) of:

b913a602c7eda7a495b4e6e7334d3890

The user name then gets prepended to it, forming:

tim b913a602c7eda7a495b4e6e7334d3890

Then it's base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command) 🎀, yielding:

dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

3. References 📚

[CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.

[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996.

[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, Carnegie Mellon, December 1994.

[KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.

[POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, Carnegie Mellon, May 1996.

[POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December, 1994.

4. Security Considerations 🛡️

⚠️ This section is serious business, bestie, so read it all 👀.

It's conjectured that CRAM authentication gives origin identification and replay protection for a session 🤞. So a server that implements both a cleartext password command and this auth type should not allow both methods of access for a given user 🚫.

Saving "contexts" on the server (see section 2) is marginally better than saving shared secrets in cleartext, which is what CHAP [CHAP] and APOP [POP3] require 😤. But it still isn't enough to protect the secrets if the server itself gets compromised 💥. So servers that store the secrets or contexts must both be protected to a level that fits the potential information value in user mailboxes and identities 🔒.

The longer the shared secret is, the harder it is to derive it 📏.

There are now suggestions in the literature that MD5 and keyed MD5 in auth procedures probably have a limited effective lifetime ⏳. But the technique is widely deployed and widely understood 🌍. That general understanding may help with the rapid replacement, by CRAM-MD5, of the current uses of permanent cleartext passwords in IMAP 🚀. This doc was deliberately written to allow easy upgrading to use SHA (or whatever alternatives come out) once they're considered widely available and safe enough 🔮.

Even with CRAM, users are still vulnerable to active attacks 😩. An increasingly common example of an active attack is 'TCP Session Hijacking', as described in CERT Advisory CA-95:01 [CERT95] 🕳️.

See section 1 above for more discussion 👆.

5. Acknowledgements 💜

This memo borrows ideas and some text liberally from [POP3] and [RFC-1731], and thanks are due to the authors of those docs 🫶. Ran Atkinson made a bunch of valuable technical and editorial contributions to the document 👏.

6. Authors' Addresses 💌

John C. Klensin
MCI Telecommunications
800 Boylston St, 7th floor
Boston, MA 02199
USA

EMail: klensin@mci.net
Phone: +1 617 960 1011

Randy Catoe
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA

EMail: randy@mci.net
Phone: +1 703 715 7366

Paul Krumviede
MCI Telecommunications
2100 Reston Parkway
Reston, VA 22091
USA

EMail: paul@mci.net
Phone: +1 703 715 7251