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

1 files changed, 0 insertions, 261 deletions

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

-

-