rfc2595.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页

9. Security Considerations

   TLS only provides protection for data sent over a network connection.
   Messages transferred over IMAP or POP3 are still available to server
   administrators and usually subject to eavesdropping, tampering and
   forgery when transmitted through SMTP or NNTP.  TLS is no substitute
   for an end-to-end message security mechanism using MIME security
   multiparts [MIME-SEC].

   A man-in-the-middle attacker can remove STARTTLS from the capability
   list or generate a failure response to the STARTTLS command.  In
   order to detect such an attack, clients SHOULD warn the user when
   session privacy is not active and/or be configurable to refuse to
   proceed without an acceptable level of security.

   A man-in-the-middle attacker can always cause a down-negotiation to
   the weakest authentication mechanism or cipher suite available.  For
   this reason, implementations SHOULD be configurable to refuse weak
   mechanisms or cipher suites.

   Any protocol interactions prior to the TLS handshake are performed in
   the clear and can be modified by a man-in-the-middle attacker.  For
   this reason, clients MUST discard cached information about server
   capabilities advertised prior to the start of the TLS handshake.

   Clients are encouraged to clearly indicate when the level of
   encryption active is known to be vulnerable to attack using modern
   hardware (such as encryption keys with 56 bits of entropy or less).

   The LOGINDISABLED IMAP capability (discussed in section 3.2) only
   reduces the potential for passive attacks, it provides no protection
   against active attacks.  The responsibility remains with the client
   to avoid sending a password over a vulnerable channel.

   The PLAIN mechanism relies on the TLS encryption layer for security.
   When used without TLS, it is vulnerable to a common network
   eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
   unless a suitable TLS encryption layer is active or backwards
   compatibility dictates otherwise.

   When the PLAIN mechanism is used, the server gains the ability to
   impersonate the user to all services with the same password
   regardless of any encryption provided by TLS or other network privacy
   mechanisms.  While many other authentication mechanisms have similar
   weaknesses, stronger SASL mechanisms such as Kerberos address this
   issue.  Clients are encouraged to have an operational mode where all
   mechanisms which are likely to reveal the user's password to the
   server are disabled.



Newman                      Standards Track                    [Page 11]

RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999


   The security considerations for TLS apply to STARTTLS and the
   security considerations for SASL apply to the PLAIN mechanism.
   Additional security requirements are discussed in section 2.

10. References

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
              Configuration Access Protocol", RFC 2244, November 1997.

   [AUTH]     Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, October 1994.

   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
              AUTHorize Extension for Simple Challenge/Response", RFC
              2195, September 1997.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, October 1995.

   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [POP3EXT]  Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
              Mechanism", RFC 2449, November 1998.

   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
              December 1994.

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

   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              TLS", RFC 2487, January 1999.

   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.





Newman                      Standards Track                    [Page 12]

RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999


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


11. Author's Address

   Chris Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790 USA

   EMail: [e-mail]


A. Appendix -- Compliance Checklist

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for the protocols it implements.  An
   implementation that satisfies all the MUST and all the SHOULD
   requirements for its protocols is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements for its protocols is said to be
   "conditionally compliant".

   Rules                                                 Section
   -----                                                 -------
   Mandatory-to-implement Cipher Suite                      2.1
   SHOULD have mode where encryption required               2.2
   server SHOULD have mode where TLS not required           2.2
   MUST be configurable to refuse all clear-text login
     commands or mechanisms                                 2.3
   server SHOULD be configurable to refuse clear-text
     login commands on entire server and on per-user basis  2.3
   client MUST check server identity                        2.4
   client MUST use hostname used to open connection         2.4
   client MUST NOT use hostname from insecure remote lookup 2.4
   client SHOULD support subjectAltName of dNSName type     2.4
   client SHOULD ask for confirmation or terminate on fail  2.4
   MUST check result of STARTTLS for acceptable privacy     2.5
   client MUST NOT issue commands after STARTTLS
      until server response and negotiation done        3.1,4,5.1
   client MUST discard cached information             3.1,4,5.1,9
   client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
   IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
   IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
   POP server MUST implement POP3 extensions                4
   ACAP server MUST re-issue ACAP greeting                  5.1




Newman                      Standards Track                    [Page 13]

RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999


   client SHOULD warn when session privacy not active and/or
     refuse to proceed without acceptable security level    9
   SHOULD be configurable to refuse weak mechanisms or
     cipher suites                                          9

   The PLAIN mechanism is an optional part of this specification.
   However if it is implemented the following rules apply:

   Rules                                                 Section
   -----                                                 -------
   MUST NOT use PLAIN unless strong encryption active
     or backwards compatibility dictates otherwise         6,9
   MUST use UTF-8 encoding for characters in PLAIN          6






































Newman                      Standards Track                    [Page 14]

RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 implementation 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Newman                      Standards Track                    [Page 15]