From fdec8d6cf10bfd061d98d8b790bb71985ed36e3a Mon Sep 17 00:00:00 2001 From: Graham Wilson Date: Mon, 29 Nov 2004 16:40:04 +0000 Subject: Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file. svn path=/trunk/; revision=4013 --- RFC/draft-klensin-cram-03.txt | 261 ------------------------------------------ 1 file changed, 261 deletions(-) delete mode 100644 RFC/draft-klensin-cram-03.txt (limited to 'RFC/draft-klensin-cram-03.txt') diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt deleted file mode 100644 index bfac1d5b..00000000 --- a/RFC/draft-klensin-cram-03.txt +++ /dev/null @@ -1,261 +0,0 @@ - -Network Working Group J Klensin -Internet Draft R Catoe -Document: draft-klensin-cram-03.txt P Krumviede - MCI - September 1996 - - - - - IMAP/POP AUTHorize Extension for Simple Challenge/Response - -Status of this Memo - - This document is an Internet Draft. Internet Drafts are working - documents of the Internet Engineering Task Force (IETF), its Areas, - and its Working Groups. Note that other groups may also distribute - working documents as Internet Drafts. - - Internet Drafts are draft documents valid for a maximum of six - months. Internet Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress``. - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or - munnari.oz.au. - - A revised version of this draft document will be submitted to the - IESG for processing as a Proposed Standard for the Internet - Community, updating RFC 1731. Discussion and suggestions for - improvement are requested. This document reflects editorial - comments received during the last call period; the protocol is - unchanged from the previous version. This draft will expire - before February 22, 1997. Distribution of this draft is - unlimited. - - -Abstract - - While IMAP4 supports a number of strong authentication mechanisms - as described in RFC 1731, it lacks any mechanism that neither passes - cleartext, reusable passwords across the network nor requires either a - significant security infrastructure or that the mail server update a - mail-system-wide user authentication file on each mail access. This - specification provides a simple challenge-response authentication - protocol that is suitable for use with IMAP4. Since it utilizes - Keyed-MD5 digests and does not require that the secret be stored in the - clear on the server, it may also constitute an improvement on APOP for - POP3 use as specified in RFC 1734. - -1. Introduction - - Existing Proposed Standards specify an AUTHENTICATE mechanism for - the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for - the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is intended - to be extensible; the four methods specified in [IMAP-AUTH] are all - fairly powerful and require some security infrastructure to support. - The base POP3 specification [POP3] also contains a lightweight - challenge-response mechanism called APOP. APOP is associated with - most of the risks associated with such protocols: in particular, it - requires that both the client and server machines have access to the - shared secret in cleartext form. CRAM offers a method for avoiding - such cleartext storage while retaining the algorithmic simplicity - of APOP in using only MD5, though in a "keyed" method. - - At present, IMAP [IMAP] lacks any facility corresponding to APOP. - The only alternative to the strong mechanisms identified in - [IMAP-AUTH] is a presumably cleartext username and password, - supported through the LOGIN command in [IMAP]. This document - describes a simple challenge-response mechanism, similar to APOP and - PPP CHAP [PPP], that can be used with IMAP (and, in principle, with - POP3). - - This mechanism also has the advantage over some possible - alternatives of not requiring that the server maintain information - about email "logins" on a per-login basis. While mechanisms that - do require such per-login history records may offer enhanced - security, protocols such as IMAP, which may have several - connections between a given client and server open more or less - simultaneous, may make their implementation particularly - challenging. - - -2. Challenge-Response Authentication Mechanism (CRAM) - - The authentication type associated with CRAM is "CRAM-MD5". - - The data encoded in the first ready response contains an - presumptively arbitrary string of random digits, a timestamp, - and the fully-qualified primary host name of the server. The - syntax of the unencoded form must correspond to that of an - RFC 822 'msg-id' [RFC822] as described in [POP3]. - - The client makes note of the data and then responds with a string - consisting of the user name, a space, and a 'digest'. The latter 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). - - This shared secret is a string known only to the client and server. - The `digest' parameter itself is a 16-octet value which is - sent in hexadecimal format, using lower-case ASCII characters. - - When the server receives this client response, it verifies the digest - provided. If the digest is correct, the server should consider the - client authenticated and respond appropriately. - - Keyed MD5 is chosen for this application because of the greater - security imparted to authentication of short messages. In addition, - the use of the techniques described in [KEYED-MD5] for - precomputation of intermediate results make it possible to avoid - explicit cleartext storage of the shared secret on the server system - by instead storing the intermediate results which are known as - "contexts". - - CRAM does not support a protection mechanism. - - - Example: - - The examples in this document show the use of the CRAM mechanism 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 specification 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'. - Hence, 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 draft - [KEYED-MD5] and the string shown 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 produces a digest value (in hexadecimal) of - - - b913a602c7eda7a495b4e6e7334d3890 - - The user name is then prepended to it, forming - - tim b913a602c7eda7a495b4e6e7334d3890 - - Which is then 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 4", - RFC 1730, University of Washington, December, 1994. - - [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 (draft-ietf-ipsec-hmac-md5-00.txt), - IBM, March 1996. - - [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 ", - RFC 1939 (STD 53), Carnegie Mellon, May 1996. - - [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie - Mellon, December, 1994. - - -4. Security Considerations - - It is conjectured that use of the CRAM authentication mechanism - provides origin identification and replay protection for a session. - Accordingly, a server that implements both a cleartext password - command and this authentication type should not allow both methods of - access for a given user. - - While the saving, on the server, of "contexts" (see section 2) is - marginally better than saving the shared secrets in cleartext as is - required by CHAP [CHAP] and APOP [POP3], it is not sufficient to - protect the secrets if the server itself is compromised. - Consequently, servers that store the secrets or contexts must both - be protected to a level appropriate to the potential information - value in user mailboxes and identities. - - As the length of the shared secret increases, so does the difficulty - of deriving it. - - While there are now suggestions in the literature that the use of - MD5 and keyed MD5 in authentication procedures probably has a - limited effective lifetime, the technique is now widely deployed and - widely understood. It is believed that this general understanding - may assist with the rapid replacement, by CRAM-MD5, of the current - uses of permanent cleartext passwords in IMAP. This document has - been deliberately written to permit easy upgrading to use SHA (or - whatever alternatives emerge) when they are considered to be widely - available and adequately safe. - - Even with the use of CRAM, users are still vulnerable to active - attacks. An example of an increasingly common active attack is 'TCP - Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. - - See section 1 above for additional discussion. - - -5. Acknowledgements - - This memo borrows ideas and some text liberally from [POP3] and - [RFC-1731] and thanks are due the authors of those documents. Ran - Atkinson made a number of valuable technical and editorial - contributions to the current draft. - - -6. Authors' Addresses - - John C. Klensin - MCI Telecommunications - 800 Boylston St, 7th floor - Boston, MA 02199 - USA - Email: klensin@mci.net - Tel: +1 617 960 1011 - - Randy Catoe - MCI Telecommunications - 2100 Reston Parkway - Reston, VA 22091 - USA - Email: randy@mci.net - Tel: +1 703 715 7366 - - Paul Krumviede - MCI Telecommunications - 2100 Reston Parkway - Reston, VA 22091 - USA - Email: paul@mci.net - Tel: +1 703 715 7251 - - -- cgit v1.2.3