Myers, J., "Simple Authentication and Security Layer (SASL),"
          RFC 2222, Netscape Communications, October 1997.

     [UNICODE]
          The Unicode Consortium, The Unicode Standard, Version 3.2.0,
          defined by: The Unicode Standard, Version 3.0 (Reading, MA,
          Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the
          Unicode Standard Annex #27: Unicode 3.1
          (http://www.unicode.org/reports/tr27/) and the Unicode
          Standard Annex #28: Unicode 3.2
          (http://www.unicode.org/reports/tr28/)

     [UTF8]
          Yergeau, F., "UTF-8, a transformation format of ISO 10646",
          RFC 2279, Alis Technologies, January 1998.

3.2.  Informative References

     [IMAP4]
          Crispin, M., "Internet Message Access Protocol - Version
          4rev1," Work in progress (son of RFC2060)






Nerenberg          draft-nerenberg-sasl-crammd5-03.txt          [Page 4]

Internet Draft           CRAM-MD5 SASL Mechanism           November 2002


4.  Security Considerations

     It is conjectured that use of the CRAM-MD5 authentication mechanism
     provides replay protection for a session.

     This mechanism does not obscure the user name in any way.
     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 name.

     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."

     While the saving, on the server, of the MD5 "context" is marginally
     better than saving the shared secrets in cleartext, 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 the data and services protected by
     this mechanism.  In other words, techniques like this one involve a
     tradeoff between vulnerability to network sniffing and I/O buffer
     snooping and vulnerability of the server host's databases.  If one
     believes that the host and its databases are subject to compromise,
     and the network is not, this technique (and all others like it) is
     unattractive.  It is perhaps even less attractive than cleartext
     passwords, which are typically stored on hosts in one-way hash
     form.  On the other hand, if the server databases are perceived as
     reasonably secure, and one is concerned about client-side or
     network interception of the passwords (secrets), then this (and
     similar) techniques are preferable to clear-text passwords by a
     wide margin.

     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 many
     protocols.  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-MD5, 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.




Nerenberg          draft-nerenberg-sasl-crammd5-03.txt          [Page 5]

Internet Draft           CRAM-MD5 SASL Mechanism           November 2002


5.  Contributors

     The CRAM-MD5 mechanism was originally specified in RFC 2095,
     IMAP/POP AUTHorize Extension for Simple Challenge/Response.  The
     authors of that document -- John C. Klensin, Paul Krumviede, and
     Randy Catoe -- are to be credited with the design and specification
     of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the
     formal context of SASL, which specification it preceeded by several
     months.


6.  Intellectual Property

     The IETF takes no position regarding the validity or scope of any
     intellectual property or other rights that might be claimed to
     pertain to the implementation or use of the technology described in
     this document or the extent to which any license under such rights
     might or might not be available; neither does it represent that it
     has made any effort to identify any such rights.  Information on
     the IETF's procedures with respect to rights in standards-track and
     standards-related documentation can be found in BCP-11.  Copies of
     claims of rights made available for publication and any assurances
     of licenses to be made available, or the result of an attempt made
     to obtain a general license or permission for the use of such
     proprietary rights by implementors or users of this specification
     can be obtained from the IETF Secretariat.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights which may cover technology that may be required to practice
     this standard.  Please address the information to the IETF
     Executive Director.


7.  Authors' Address

     Lyndon Nerenberg
     Orthanc Systems
     508 - 11025 Jasper Avenue
     Edmonton, Alberta
     Canada T5K 0K7
     Email: lyndon@orthanc.ab.ca















Nerenberg          draft-nerenberg-sasl-crammd5-03.txt          [Page 6]

Internet Draft           CRAM-MD5 SASL Mechanism           November 2002


8.  Full Copyright Statement

     Copyright (C) The Internet Society (2002). All Rights Reserved.

     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implmentation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into languages
     other than English.
     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.































Nerenberg          draft-nerenberg-sasl-crammd5-03.txt          [Page 7]