diff options
Diffstat (limited to 'RFC/draft-klensin-cram-03.txt')
| -rw-r--r-- | RFC/draft-klensin-cram-03.txt | 261 |
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
-
-
|