Add files from ESR's dev directory that weren't under version control

svn path=/trunk/; revision=3881

1 files changed, 261 insertions, 0 deletions

diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt
new file mode 100644
index 00000000..bfac1d5b
--- /dev/null
+++ b/RFC/draft-klensin-cram-03.txt
@@ -0,0 +1,261 @@
+

+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

+

+