rfc2195.IMAP-POP_AUTHorize_extension.txt 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283
  1. Network Working Group J. Klensin
  2. Request for Comments: 2195 R. Catoe
  3. Category: Standards Track P. Krumviede
  4. Obsoletes: 2095 MCI
  5. September 1997
  6. IMAP/POP AUTHorize Extension for Simple Challenge/Response
  7. Status of this Memo
  8. This document specifies an Internet standards track protocol for the
  9. Internet community, and requests discussion and suggestions for
  10. improvements. Please refer to the current edition of the "Internet
  11. Official Protocol Standards" (STD 1) for the standardization state
  12. and status of this protocol. Distribution of this memo is unlimited.
  13. Abstract
  14. While IMAP4 supports a number of strong authentication mechanisms as
  15. described in RFC 1731, it lacks any mechanism that neither passes
  16. cleartext, reusable passwords across the network nor requires either
  17. a significant security infrastructure or that the mail server update
  18. a mail-system-wide user authentication file on each mail access.
  19. This specification provides a simple challenge-response
  20. authentication protocol that is suitable for use with IMAP4. Since
  21. it utilizes Keyed-MD5 digests and does not require that the secret be
  22. stored in the clear on the server, it may also constitute an
  23. improvement on APOP for POP3 use as specified in RFC 1734.
  24. 1. Introduction
  25. Existing Proposed Standards specify an AUTHENTICATE mechanism for the
  26. IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
  27. the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is
  28. intended to be extensible; the four methods specified in [IMAP-AUTH]
  29. are all fairly powerful and require some security infrastructure to
  30. support. The base POP3 specification [POP3] also contains a
  31. lightweight challenge-response mechanism called APOP. APOP is
  32. associated with most of the risks associated with such protocols: in
  33. particular, it requires that both the client and server machines have
  34. access to the shared secret in cleartext form. CRAM offers a method
  35. for avoiding such cleartext storage while retaining the algorithmic
  36. simplicity of APOP in using only MD5, though in a "keyed" method.
  37. Klensin, Catoe & Krumviede Standards Track [Page 1]
  38. RFC 2195 IMAP/POP AUTHorize Extension September 1997
  39. At present, IMAP [IMAP] lacks any facility corresponding to APOP.
  40. The only alternative to the strong mechanisms identified in [IMAP-
  41. AUTH] is a presumably cleartext username and password, supported
  42. through the LOGIN command in [IMAP]. This document describes a
  43. simple challenge-response mechanism, similar to APOP and PPP CHAP
  44. [PPP], that can be used with IMAP (and, in principle, with POP3).
  45. This mechanism also has the advantage over some possible alternatives
  46. of not requiring that the server maintain information about email
  47. "logins" on a per-login basis. While mechanisms that do require such
  48. per-login history records may offer enhanced security, protocols such
  49. as IMAP, which may have several connections between a given client
  50. and server open more or less simultaneous, may make their
  51. implementation particularly challenging.
  52. 2. Challenge-Response Authentication Mechanism (CRAM)
  53. The authentication type associated with CRAM is "CRAM-MD5".
  54. The data encoded in the first ready response contains an
  55. presumptively arbitrary string of random digits, a timestamp, and the
  56. fully-qualified primary host name of the server. The syntax of the
  57. unencoded form must correspond to that of an RFC 822 'msg-id'
  58. [RFC822] as described in [POP3].
  59. The client makes note of the data and then responds with a string
  60. consisting of the user name, a space, and a 'digest'. The latter is
  61. computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
  62. the key is a shared secret and the digested text is the timestamp
  63. (including angle-brackets).
  64. This shared secret is a string known only to the client and server.
  65. The `digest' parameter itself is a 16-octet value which is sent in
  66. hexadecimal format, using lower-case ASCII characters.
  67. When the server receives this client response, it verifies the digest
  68. provided. If the digest is correct, the server should consider the
  69. client authenticated and respond appropriately.
  70. Keyed MD5 is chosen for this application because of the greater
  71. security imparted to authentication of short messages. In addition,
  72. the use of the techniques described in [KEYED-MD5] for precomputation
  73. of intermediate results make it possible to avoid explicit cleartext
  74. storage of the shared secret on the server system by instead storing
  75. the intermediate results which are known as "contexts".
  76. Klensin, Catoe & Krumviede Standards Track [Page 2]
  77. RFC 2195 IMAP/POP AUTHorize Extension September 1997
  78. CRAM does not support a protection mechanism.
  79. Example:
  80. The examples in this document show the use of the CRAM mechanism with
  81. the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
  82. the challenges and responses is part of the IMAP4 AUTHENTICATE
  83. command, not part of the CRAM specification itself.
  84. S: * OK IMAP4 Server
  85. C: A0001 AUTHENTICATE CRAM-MD5
  86. S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
  87. C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
  88. S: A0001 OK CRAM authentication successful
  89. In this example, the shared secret is the string
  90. 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
  91. calculating
  92. MD5((tanstaaftanstaaf XOR opad),
  93. MD5((tanstaaftanstaaf XOR ipad),
  94. <1896.697170952@postoffice.reston.mci.net>))
  95. where ipad and opad are as defined in the keyed-MD5 Work in
  96. Progress [KEYED-MD5] and the string shown in the challenge is the
  97. base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
  98. shared secret is null-padded to a length of 64 bytes. If the
  99. shared secret is longer than 64 bytes, the MD5 digest of the
  100. shared secret is used as a 16 byte input to the keyed MD5
  101. calculation.
  102. This produces a digest value (in hexadecimal) of
  103. b913a602c7eda7a495b4e6e7334d3890
  104. The user name is then prepended to it, forming
  105. tim b913a602c7eda7a495b4e6e7334d3890
  106. Which is then base64 encoded to meet the requirements of the IMAP4
  107. AUTHENTICATE command (or the similar POP3 AUTH command), yielding
  108. dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
  109. Klensin, Catoe & Krumviede Standards Track [Page 3]
  110. RFC 2195 IMAP/POP AUTHorize Extension September 1997
  111. 3. References
  112. [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
  113. RFC 1334, October 1992.
  114. [IMAP] Crispin, M., "Internet Message Access Protocol - Version
  115. 4rev1", RFC 2060, University of Washington, December 1996.
  116. [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
  117. RFC 1731, Carnegie Mellon, December 1994.
  118. [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
  119. Message Authentication", RFC 2104, February 1997.
  120. [MD5] Rivest, R., "The MD5 Message Digest Algorithm",
  121. RFC 1321, MIT Laboratory for Computer Science, April 1992.
  122. [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
  123. STD 53, RFC 1939, Carnegie Mellon, May 1996.
  124. [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
  125. Carnegie Mellon, December, 1994.
  126. 4. Security Considerations
  127. It is conjectured that use of the CRAM authentication mechanism
  128. provides origin identification and replay protection for a session.
  129. Accordingly, a server that implements both a cleartext password
  130. command and this authentication type should not allow both methods of
  131. access for a given user.
  132. While the saving, on the server, of "contexts" (see section 2) is
  133. marginally better than saving the shared secrets in cleartext as is
  134. required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
  135. protect the secrets if the server itself is compromised.
  136. Consequently, servers that store the secrets or contexts must both be
  137. protected to a level appropriate to the potential information value
  138. in user mailboxes and identities.
  139. As the length of the shared secret increases, so does the difficulty
  140. of deriving it.
  141. While there are now suggestions in the literature that the use of MD5
  142. and keyed MD5 in authentication procedures probably has a limited
  143. effective lifetime, the technique is now widely deployed and widely
  144. understood. It is believed that this general understanding may
  145. assist with the rapid replacement, by CRAM-MD5, of the current uses
  146. of permanent cleartext passwords in IMAP. This document has been
  147. Klensin, Catoe & Krumviede Standards Track [Page 4]
  148. RFC 2195 IMAP/POP AUTHorize Extension September 1997
  149. deliberately written to permit easy upgrading to use SHA (or whatever
  150. alternatives emerge) when they are considered to be widely available
  151. and adequately safe.
  152. Even with the use of CRAM, users are still vulnerable to active
  153. attacks. An example of an increasingly common active attack is 'TCP
  154. Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
  155. See section 1 above for additional discussion.
  156. 5. Acknowledgements
  157. This memo borrows ideas and some text liberally from [POP3] and
  158. [RFC-1731] and thanks are due the authors of those documents. Ran
  159. Atkinson made a number of valuable technical and editorial
  160. contributions to the document.
  161. 6. Authors' Addresses
  162. John C. Klensin
  163. MCI Telecommunications
  164. 800 Boylston St, 7th floor
  165. Boston, MA 02199
  166. USA
  167. EMail: klensin@mci.net
  168. Phone: +1 617 960 1011
  169. Randy Catoe
  170. MCI Telecommunications
  171. 2100 Reston Parkway
  172. Reston, VA 22091
  173. USA
  174. EMail: randy@mci.net
  175. Phone: +1 703 715 7366
  176. Paul Krumviede
  177. MCI Telecommunications
  178. 2100 Reston Parkway
  179. Reston, VA 22091
  180. USA
  181. EMail: paul@mci.net
  182. Phone: +1 703 715 7251
  183. Klensin, Catoe & Krumviede Standards Track [Page 5]