RFC 2095

RFC 2095: IMAP/POP AUTHorize Extension for Simple Challenge/Response 💖

okay bestie, here's the title block tea ☕✨

• RFC number: 2095 🎀
• Title: IMAP/POP AUTHorize Extension for Simple Challenge/Response
• Authors: J. Klensin, R. Catoe, and P. Krumviede, all from MCI 💅
• Category: Standards Track 👑
• Date: January 1997 🌸
• Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 🦋

It's from the Network Working Group, so it's an official IETF-style doc, not someone's random blog post 🧚

---

Status of this Memo ✨

this doc is an Internet standards track protocol for the whole Internet community, and it's asking everyone to talk about it and suggest improvements 🫶 for where the protocol's standardization state and status are at, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 and distribution of this memo is unlimited, so share away 💜

Abstract 🌈

okay so IMAP4 has a bunch of strong authentication mechanisms from RFC 1731 🔐 but it's missing one that doesn't send cleartext, reusable passwords over the network 😭 and doesn't need a huge security setup or make the mail server rewrite a mail-system-wide user authentication file every time someone checks their mail 💀

this spec gives you a simple challenge-response auth protocol that works with IMAP4 ✨ it uses Keyed-MD5 digests and doesn't require the secret to be stored in the clear on the server, so it could be an upgrade over APOP for POP3 from RFC 1734 🔥 literally iconic

1. Introduction 🎀

so there are already Proposed Standards for an AUTHENTICATE mechanism in IMAP4 [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for POP3 [POP3-AUTH] 🍓 the AUTHENTICATE one is built to be extensible, and the four methods in [IMAP-AUTH] are all pretty powerful, but they need some security infrastructure to work 🏗️

POP3 [POP3] also has a lightweight challenge-response thing called APOP 🦋 APOP comes with most of the risks you'd expect from this kind of protocol. the big one is that both the client and the server machine need the shared secret in cleartext form 😬 CRAM fixes that by avoiding cleartext storage, but it still keeps the algorithmic simplicity of APOP by only using MD5, in a "keyed" way 🔑

right now IMAP [IMAP] has nothing like APOP 🙈 the only option besides 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) 💅

another glow-up: unlike some other options, this one doesn't make the server keep info about email "logins" on a per-login basis 🧚 those per-login history records can offer better security, but with protocols like IMAP, where a client and server might have several connections open at more or less the same time, that gets really hard to implement 💀

2. Challenge-Response Authentication Mechanism (CRAM) 🌸

the authentication type for CRAM is "CRAM-MD5" 🎀

the data in the first ready response has a presumptively arbitrary string of random digits, a timestamp, and the fully-qualified primary host name of the server 🦋 the unencoded form's syntax must correspond to an RFC 822 'msg-id' [RFC822] as described in [POP3] 📚

the client notes the data and then responds with a string made of the user name, a space, and a 'digest' ✨ the digest is computed by applying the keyed MD5 algorithm from [KEYED-MD5], where the key is a shared secret and the digested text is the timestamp (including angle-brackets) 🔐

the shared secret is a string only the client and server know 🤫 the digest parameter is a 16-octet value sent in hexadecimal format, using lower-case ASCII characters 🍓

when the server gets this client response, it checks the digest 👀 if the digest is correct, the server should consider the client authenticated and respond appropriately 💖

keyed MD5 was picked for this because it gives greater security for authenticating short messages 💅 also, the precomputation techniques from [KEYED-MD5] make it possible to avoid storing the shared secret in cleartext on the server 🙌 instead the server stores the intermediate results, which are called "contexts" ✨

CRAM does not 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 comes from 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

then the user name gets prepended to it, forming:

  tim b913a602c7eda7a495b4e6e7334d3890

and then it's base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE command (or the similar POP3 AUTH command), giving:

  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, H., "HMAC-MD5: Keyed-MD5 for Message Authentication", Work in Progess. 🌸

[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 🔐

okay this section is serious, so read it carefully bestie 🚨

it's conjectured that CRAM authentication gives origin identification and replay protection for a session 🤔 because of that, a server that does 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 like CHAP [CHAP] and APOP [POP3] require 😬 but it's not 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 matches the potential information value in user mailboxes and identities 🛡️

the longer the shared secret, the harder it is to derive 💪

there are suggestions in the literature that MD5 and keyed MD5 probably have a limited effective lifetime in authentication 😳 but the technique is widely deployed and widely understood 🌈 that general understanding may help with rapidly replacing the current uses of permanent cleartext passwords in IMAP with CRAM-MD5 ✨ this document was deliberately written so it can easily be upgraded to SHA (or whatever alternatives come out) once they're widely available and safe enough 🦋

even with CRAM, users are still vulnerable to active attacks 🙈 an increasingly common 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 the authors of those docs deserve thanks 🙌 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