summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc2195.txt
diff options
context:
space:
mode:
authorEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
committerEduardo Chappa <chappa@washington.edu>2013-06-03 10:30:56 -0600
commite4b35478c8b3ce7352a74b2fea0e067f068daf18 (patch)
tree0b8a97debddc8210c6696c252c26f03703b606fa /imap/docs/rfc/rfc2195.txt
parenta46157ba61f2c65f88b42abb31db60c4a714f87b (diff)
downloadalpine-e4b35478c8b3ce7352a74b2fea0e067f068daf18.tar.xz
* Changes to configure.ac to add -lkrb5 to the link
* Changes to avoud errors in compilation when -Wformat-security is used * Remove RFC files from source code
Diffstat (limited to 'imap/docs/rfc/rfc2195.txt')
-rw-r--r--imap/docs/rfc/rfc2195.txt283
1 files changed, 0 insertions, 283 deletions
diff --git a/imap/docs/rfc/rfc2195.txt b/imap/docs/rfc/rfc2195.txt
deleted file mode 100644
index 4a2725bf..00000000
--- a/imap/docs/rfc/rfc2195.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Klensin
-Request for Comments: 2195 R. Catoe
-Category: Standards Track P. Krumviede
-Obsoletes: 2095 MCI
- September 1997
-
-
- IMAP/POP AUTHorize Extension for Simple Challenge/Response
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo 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.
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 1]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- 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".
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 2]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- 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 Work in
- Progress [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
-
-
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 3]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
-3. References
-
- [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
- RFC 1334, October 1992.
-
- [IMAP] Crispin, M., "Internet Message Access Protocol - Version
- 4rev1", RFC 2060, University of Washington, December 1996.
-
- [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
- RFC 1731, Carnegie Mellon, December 1994.
-
- [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
- Message Authentication", RFC 2104, February 1997.
-
- [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",
- STD 53, RFC 1939, 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
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 4]
-
-RFC 2195 IMAP/POP AUTHorize Extension September 1997
-
-
- 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 document.
-
-6. Authors' Addresses
-
- John C. Klensin
- MCI Telecommunications
- 800 Boylston St, 7th floor
- Boston, MA 02199
- USA
-
- EMail: klensin@mci.net
- Phone: +1 617 960 1011
-
- Randy Catoe
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-
- EMail: randy@mci.net
- Phone: +1 703 715 7366
-
- Paul Krumviede
- MCI Telecommunications
- 2100 Reston Parkway
- Reston, VA 22091
- USA
-
- EMail: paul@mci.net
- Phone: +1 703 715 7251
-
-
-
-
-
-
-Klensin, Catoe & Krumviede Standards Track [Page 5]
-