rfc2595.txt

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

Network Working Group                                          C. Newman
Request for Comments: 2595                                      Innosoft
Category: Standards Track                                      June 1999


                   Using TLS with IMAP, POP3 and ACAP


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.

Copyright Notice

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

1. Motivation

   The TLS protocol (formerly known as SSL) provides a way to secure an
   application protocol from tampering and eavesdropping.  The option of
   using such security is desirable for IMAP, POP and ACAP due to common
   connection eavesdropping and hijacking attacks [AUTH].  Although
   advanced SASL authentication mechanisms can provide a lightweight
   version of this service, TLS is complimentary to simple
   authentication-only SASL mechanisms or deployed clear-text password
   login commands.

   Many sites have a high investment in authentication infrastructure
   (e.g., a large database of a one-way-function applied to user
   passwords), so a privacy layer which is not tightly bound to user
   authentication can protect against network eavesdropping attacks
   without requiring a new authentication infrastructure and/or forcing
   all users to change their password.  Recognizing that such sites will
   desire simple password authentication in combination with TLS
   encryption, this specification defines the PLAIN SASL mechanism for
   use with protocols which lack a simple password authentication
   command such as ACAP and SMTP.  (Note there is a separate RFC for the
   STARTTLS command in SMTP [SMTPTLS].)

   There is a strong desire in the IETF to eliminate the transmission of
   clear-text passwords over unencrypted channels.  While SASL can be
   used for this purpose, TLS provides an additional tool with different
   deployability characteristics.  A server supporting both TLS with




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


   simple passwords and a challenge/response SASL mechanism is likely to
   interoperate with a wide variety of clients without resorting to
   unencrypted clear-text passwords.

   The STARTTLS command rectifies a number of the problems with using a
   separate port for a "secure" protocol variant.  Some of these are
   mentioned in section 7.

1.1. Conventions Used in this Document

   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in "Key words for use in RFCs to Indicate Requirement
   Levels" [KEYWORDS].

   Terms related to authentication are defined in "On Internet
   Authentication" [AUTH].

   Formal syntax is defined using ABNF [ABNF].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

2. Basic Interoperability and Security Requirements

   The following requirements apply to all implementations of the
   STARTTLS extension for IMAP, POP3 and ACAP.

2.1. Cipher Suite Requirements

   Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
   suite is REQUIRED.  This is important as it assures that any two
   compliant implementations can be configured to interoperate.

   All other cipher suites are OPTIONAL.

2.2. Privacy Operational Mode Security Requirements

   Both clients and servers SHOULD have a privacy operational mode which
   refuses authentication unless successful activation of an encryption
   layer (such as that provided by TLS) occurs prior to or at the time
   of authentication and which will terminate the connection if that
   encryption layer is deactivated.  Implementations are encouraged to
   have flexability with respect to the minimal encryption strength or
   cipher suites permitted.  A minimalist approach to this
   recommendation would be an operational mode where the
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
   permitting authentication.



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


   Clients MAY have an operational mode which uses encryption only when
   it is advertised by the server, but authentication continues
   regardless.  For backwards compatibility, servers SHOULD have an
   operational mode where only the authentication mechanisms required by
   the relevant base protocol specification are needed to successfully
   authenticate.

2.3. Clear-Text Password Requirements

   Clients and servers which implement STARTTLS MUST be configurable to
   refuse all clear-text login commands or mechanisms (including both
   standards-track and nonstandard mechanisms) unless an encryption
   layer of adequate strength is active.  Servers which allow
   unencrypted clear-text logins SHOULD be configurable to refuse
   clear-text logins both for the entire server, and on a per-user
   basis.

2.4. Server Identity Check

   During the TLS negotiation, the client MUST check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent man-in-the-middle
   attacks.  Matching is performed according to these rules:

   - The client MUST use the server hostname it used to open the
     connection as the value to compare against the server name as
     expressed in the server certificate.  The client MUST NOT use any
     form of the server hostname derived from an insecure remote source
     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

   - If a subjectAltName extension of type dNSName is present in the
     certificate, it SHOULD be used as the source of the server's
     identity.

   - Matching is case-insensitive.

   - A "*" wildcard character MAY be used as the left-most name
     component in the certificate.  For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com.

   - If the certificate contains multiple names (e.g. more than one
     dNSName field), then a match with any one of the fields is
     considered acceptable.

   If the match fails, the client SHOULD either ask for explicit user
   confirmation, or terminate the connection and indicate the server's
   identity is suspect.



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


2.5. TLS Security Policy Check

   Both the client and server MUST check the result of the STARTTLS
   command and subsequent TLS negotiation to see whether acceptable
   authentication or privacy was achieved.  Ignoring this step
   completely invalidates using TLS for security.  The decision about
   whether acceptable authentication or privacy was achieved is made
   locally, is implementation-dependent, and is beyond the scope of this
   document.

3. IMAP STARTTLS extension

   When the TLS extension is present in IMAP, "STARTTLS" is listed as a
   capability in response to the CAPABILITY command.  This extension
   adds a single command, "STARTTLS" to the IMAP protocol which is used
   to begin a TLS negotiation.

3.1. STARTTLS Command

   Arguments:  none

   Responses:  no specific responses for this command

   Result:     OK - begin TLS negotiation
               BAD - command unknown or arguments invalid

      A TLS negotiation begins immediately after the CRLF at the end of
      the tagged OK response from the server.  Once a client issues a
      STARTTLS command, it MUST NOT issue further commands until a
      server response is seen and the TLS negotiation is complete.

      The STARTTLS command is only valid in non-authenticated state.
      The server remains in non-authenticated state, even if client
      credentials are supplied during the TLS negotiation.  The SASL
      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
      client credentials are successfully exchanged, but servers
      supporting the STARTTLS command are not required to support the
      EXTERNAL mechanism.

      Once TLS has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against
      man-in-the-middle attacks which alter the capabilities list prior
      to STARTTLS.  The server MAY advertise different capabilities
      after STARTTLS.

      The formal syntax for IMAP is amended as follows:




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


        command_any   =/  "STARTTLS"

   Example:    C: a001 CAPABILITY
               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
               S: a001 OK CAPABILITY completed
               C: a002 STARTTLS
               S: a002 OK Begin TLS negotiation now
               <TLS negotiation, further commands are under TLS layer>
               C: a003 CAPABILITY
               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
               S: a003 OK CAPABILITY completed
               C: a004 LOGIN joe password
               S: a004 OK LOGIN completed

3.2. IMAP LOGINDISABLED capability

   The current IMAP protocol specification (RFC 2060) requires the
   implementation of the LOGIN command which uses clear-text passwords.
   Many sites may choose to disable this command unless encryption is
   active for security reasons.  An IMAP server MAY advertise that the
   LOGIN command is disabled by including the LOGINDISABLED capability
   in the capability response.  Such a server will respond with a tagged
   "NO" response to any attempt to use the LOGIN command.

   An IMAP server which implements STARTTLS MUST implement support for
   the LOGINDISABLED capability on unencrypted connections.

   An IMAP client which complies with this specification MUST NOT issue
   the LOGIN command if this capability is present.

   This capability is useful to prevent clients compliant with this
   specification from sending an unencrypted password in an environment
   subject to passive attacks.  It has no impact on an environment
   subject to active attacks as a man-in-the-middle attacker can remove
   this capability.  Therefore this does not relieve clients of the need
   to follow the privacy mode recommendation in section 2.2.

   Servers advertising this capability will fail to interoperate with
   many existing compliant IMAP clients and will be unable to prevent
   those clients from disclosing the user's password.

4. POP3 STARTTLS extension

   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
   also be implemented to avoid the need for client probing of multiple
   commands.  The capability name "STLS" indicates this command is
   present and permitted in the current state.



Newman                      Standards Track                     [Page 5]