idnits 2.17.1 draft-klensin-cram-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 263 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1996) is 10108 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PPP' is mentioned on line 69, but not defined == Missing Reference: 'RFC822' is mentioned on line 89, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'CERT95' is mentioned on line 213, but not defined == Missing Reference: 'RFC-1731' is mentioned on line 220, but not defined == Unused Reference: 'MD5' is defined on line 173, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1334 (ref. 'CHAP') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1730 (ref. 'IMAP') (Obsoleted by RFC 2060, RFC 2061) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KEYED-MD5') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 1734 (ref. 'POP3-AUTH') (Obsoleted by RFC 5034) Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J Klensin 2 Internet Draft R Catoe 3 Document: draft-klensin-cram-02.txt P Krumviede 4 MCI 5 August 1996 7 IMAP/POP AUTHorize Extension for Simple Challenge/Response 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress``. 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 25 munnari.oz.au. 27 A revised version of this draft document will be submitted to the 28 IESG for processing as a Proposed Standard for the Internet 29 Community, updating RFC 1731. Discussion and suggestions for 30 improvement are requested. This document reflects editorial 31 comments received during the last call period; the protocol is 32 unchanged from the previous version. This draft will expire 33 before February 22, 1997. Distribution of this draft is 34 unlimited. 36 Abstract 38 While IMAP4 supports a number of strong authentication mechanisms 39 as described in RFC 1731, it lacks any mechanism that neither passes 40 cleartext, reusable passwords across the network nor requires either a 41 significant security infrastructure or that the mail server update a 42 mail-system-wide user authentication file on each mail access. This 43 specification provides a simple challenge-response authentication 44 protocol that is suitable for use with IMAP4. Since it utilizes 45 Keyed-MD5 digests and does not require that the secret be stored in the 46 clear on the server, it may also constitute an improvement on APOP for 47 POP3 use as specified in RFC 1734. 49 1. Introduction 51 Existing Proposed Standards specify an AUTHENTICATE mechanism for 52 the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for 53 the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is intended 54 to be extensible; the four methods specified in [IMAP-AUTH] are all 55 fairly powerful and require some security infrastructure to support. 56 The base POP3 specification [POP3] also contains a lightweight 57 challenge-response mechanism called APOP. APOP is associated with 58 most of the risks associated with such protocols: in particular, it 59 requires that both the client and server machines have access to the 60 shared secret in cleartext form. CRAM offers a method for avoiding 61 such cleartext storage while retaining the algorithmic simplicity 62 of APOP in using only MD5, though in a "keyed" method. 64 At present, IMAP [IMAP] lacks any facility corresponding to APOP. 65 The only alternative to the strong mechanisms identified in 66 [IMAP-AUTH] is a presumably cleartext username and password, 67 supported through the LOGIN command in [IMAP]. This document 68 describes a simple challenge-response mechanism, similar to APOP and 69 PPP CHAP [PPP], that can be used with IMAP (and, in principle, with 70 POP3). 72 This mechanism also has the advantage over some possible 73 alternatives of not requiring that the server maintain information 74 about email "logins" on a per-login basis. While mechanisms that 75 do require such per-login history records may offer enhanced 76 security, protocols such as IMAP, which may have several 77 connections between a given client and server open more or less 78 simultaneous, may make their implementation particularly 79 challenging. 81 2. Challenge-Response Authentication Mechanism (CRAM) 83 The authentication type associated with CRAM is "CRAM-MD5". 85 The data encoded in the first ready response contains an 86 presumptively arbitrary string of random digits, a timestamp, 87 and the fully-qualified primary host name of the server. The 88 syntax of the unencoded form must correspond to that of an 89 RFC 822 'msg-id' [RFC822] as described in [POP3]. 91 The client makes note of the data and then responds with a string 92 consisting of the user name, a space, and a 'digest'. The latter is 93 computed by applying the keyed MD5 algorithm from [KEYED-MD5] 94 where the key is a shared secret and the digested text is 95 the timestamp (including angle-brackets). 97 This shared secret is a string known only to the client and server. 98 The `digest' parameter itself is a 16-octet value which is 99 sent in hexadecimal format, using lower-case ASCII characters. 101 When the server receives this client response, it verifies the digest 102 provided. If the digest is correct, the server should consider the 103 client authenticated and respond appropriately. 105 Keyed MD5 is chosen for this application because of the greater 106 security imparted to authentication of short messages. In addition, 107 the use of the techniques described in [KEYED-MD5] for 108 precomputation of intermediate results make it possible to avoid 109 explicit cleartext storage of the shared secret on the server system 110 by instead storing the intermediate results which are known as 111 "contexts". 113 CRAM does not support a protection mechanism. 115 Example: 117 The examples in this document show the use of the CRAM mechanism with 118 the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of 119 the challenges and responses is part of the IMAP4 AUTHENTICATE 120 command, not part of the CRAM specification itself. 122 <>> 124 S: * OK IMAP4 Server 125 C: A0001 AUTHENTICATE CRAM-MD5 126 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 127 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 128 S: A0001 OK CRAM authentication successful 130 In this example, the shared secret is the string 'tanstaaftanstaaf'. 131 Hence, the Keyed MD5 digest is produced by calculating 133 MD5((tanstaaftanstaaf XOR opad), 134 MD5((tanstaaftanstaaf XOR ipad), 135 <1896.697170952@postoffice.reston.mci.net>)) 137 where ipad and opad are as defined in the keyed-MD5 draft 138 [KEYED-MD5] and the string shown in the challenge is the base64 139 encoding of <1896.697170952@postoffice.reston.mci.net>. The 140 shared secret is null-padded to a length of 64 bytes. If the 141 shared secret is longer than 64 bytes, the MD5 digest of the 142 shared secret is used as a 16 byte input to the keyed MD5 143 calculation. 145 This produces a digest value (in hexadecimal) of 147 b913a602c7eda7a495b4e6e7334d3890 149 The user name is then prepended to it, forming 151 tim b913a602c7eda7a495b4e6e7334d3890 153 Which is then base64 encoded to meet the requirements of the IMAP4 154 AUTHENTICATE command (or the similar POP3 AUTH command), yielding 156 dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 158 3. References 160 [CHAP] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 161 RFC 1334, October 1992. 163 [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4", 164 RFC 1730, University of Washington, December, 1994. 166 [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms", 167 RFC 1731, Carnegie Mellon, December, 1994 169 [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message 170 Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt), 171 IBM, March 1996. 173 [MD5] Rivest, R. "The MD5 Message Digest Algorithm", 174 RFC 1321, MIT Laboratory for Computer Science, April, 1992. 176 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3 ", 177 RFC 1939 (STD 53), Carnegie Mellon, May 1996. 179 [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie 180 Mellon, December, 1994. 182 4. Security Considerations 184 It is conjectured that use of the CRAM authentication mechanism 185 provides origin identification and replay protection for a session. 186 Accordingly, a server that implements both a cleartext password 187 command and this authentication type should not allow both methods of 188 access for a given user. 190 While the saving, on the server, of "contexts" (see section 2) is 191 marginally better than saving the shared secrets in cleartext as is 192 required by CHAP [CHAP] and APOP [POP3], it is not sufficient to 193 protect the secrets if the server itself is compromised. 194 Consequently, servers that store the secrets or contexts must both 195 be protected to a level appropriate to the potential information 196 value in user mailboxes and identities. 198 As the length of the shared secret increases, so does the difficulty 199 of deriving it. 201 While there are now suggestions in the literature that the use of 202 MD5 and keyed MD5 in authentication procedures probably has a 203 limited effective lifetime, the technique is now widely deployed and 204 widely understood. It is believed that this general understanding 205 may assist with the rapid replacement, by CRAM-MD5, of the current 206 uses of permanent cleartext passwords in IMAP. This document has 207 been deliberately written to permit easy upgrading to use SHA (or 208 whatever alternatives emerge) when they are considered to be widely 209 available and adequately safe. 211 Even with the use of CRAM, users are still vulnerable to active 212 attacks. An example of an increasingly common active attack is 'TCP 213 Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. 215 See section 1 above for additional discussion. 217 5. Acknowledgements 219 This memo borrows ideas and some text liberally from [POP3] and 220 [RFC-1731] and thanks are due the authors of those documents. Ran 221 Atkinson made a number of valuable technical and editorial 222 contributions to the current draft. 224 6. Authors' Addresses 226 John C. Klensin 227 MCI Telecommunications 228 800 Boylston St, 7th floor 229 Boston, MA 02199 230 USA 231 Email: klensin@mci.net 232 Tel: +1 617 960 1011 234 Randy Catoe 235 MCI Telecommunications 236 2100 Reston Parkway 237 Reston, VA 22091 238 USA 239 Email: randy@mci.net 240 Tel: +1 703 715 7366 242 Paul Krumviede 243 MCI Telecommunications 244 2100 Reston Parkway 245 Reston, VA 22091 246 USA 247 Email: paul@mci.net 248 Tel: +1 703 715 7251