Using TLS with IMAP, POP3 and ACAP
updated by
Extracted elements (26)
Separate 'imaps' and 'pop3s' ports (use of SSL on dedicated ports) are discouraged in favor of STARTTLS/STLS. Problems with separate ports include: separate URL schemes that intrude on the UI, a false binary 'secure vs. not secure' model that misleads users and firewall admins, and limited port number space.
The PLAIN SASL mechanism is defined because many sites have high investment in clear-text password authentication infrastructure, and a TLS privacy layer not tightly bound to authentication can protect against network eavesdropping without requiring new authentication infrastructure or forcing password changes.
Servers advertising LOGINDISABLED will fail to interoperate with many existing compliant IMAP clients and will be unable to prevent those clients from disclosing the user's password. LOGINDISABLED has no impact against active attacks as a man-in-the-middle attacker can remove this capability.
After the TLS layer is established in ACAP, the server MUST re-issue an untagged ACAP greeting and the client MUST discard cached capability information and replace it with the information from the new ACAP greeting.
An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections. An IMAP client compliant with this specification MUST NOT issue the LOGIN command if LOGINDISABLED is present.
Both client and server MUST check the result of the STARTTLS command and subsequent TLS negotiation to verify whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security.
Both clients and servers SHOULD have a privacy operational mode which refuses authentication unless successful activation of an encryption layer occurs prior to or at the time of authentication, and which will terminate the connection if that encryption layer is deactivated.
Clients and servers MUST be configurable to refuse all clear-text login commands or mechanisms unless an encryption layer of adequate strength is active. Servers which allow unencrypted clear-text logins SHOULD be configurable to refuse them on both a server-wide and per-user basis.
During TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message to prevent man-in-the-middle attacks. The client MUST use the hostname it used to open the connection and MUST NOT use any form derived from an insecure remote source.
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. A '*' wildcard MAY be used as the left-most name component; matching is case-insensitive.
If the POP3 STLS command is implemented, the POP3 extension mechanism 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.
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is REQUIRED to ensure any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL.
Once a client issues a STARTTLS command (IMAP), 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.
Once a POP3 client issues a STLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete. The STLS command is only permitted in AUTHORIZATION state.
Once TLS has been started in IMAP, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command, to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS.
The PLAIN SASL mechanism MUST NOT be advertised or used unless a strong encryption layer (such as that provided by TLS) is active or backwards compatibility dictates otherwise.
The IMAP LOGINDISABLED capability signals that the LOGIN command is disabled; a server MUST respond with a tagged NO to any attempt to use LOGIN when this capability is present. This capability prevents compliant clients from sending unencrypted passwords but provides no protection against active attacks.
The IMAP STARTTLS extension adds the 'STARTTLS' command, advertised in the CAPABILITY response. TLS negotiation begins immediately after the CRLF at the end of the tagged OK response. The SASL EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged.
The PLAIN SASL mechanism uses a single client-to-server message. The client may leave the authorization identity empty to indicate it is the same as the authentication identity. Non-US-ASCII characters are permitted when represented in UTF-8.
The POP3 STLS command initiates TLS negotiation. It is only valid in AUTHORIZATION state; a -ERR response MAY result if a security layer is already active. After STLS, the client SHOULD re-issue the CAPA command.
This document registers the 'STARTTLS' and 'LOGINDISABLED' IMAP capabilities, the POP3 'STLS' capability (CAPA tag, AUTHORIZATION state only), the ACAP 'STARTTLS' capability, and the 'PLAIN' SASL mechanism (intended usage: COMMON).
A man-in-the-middle attacker can always cause a down-negotiation to the weakest authentication mechanism or cipher suite available; implementations SHOULD be configurable to refuse weak mechanisms or cipher suites.
A man-in-the-middle attacker can remove STARTTLS from the capability list or generate a failure response to the STARTTLS command. Clients SHOULD warn users when session privacy is not active and/or be configurable to refuse to proceed without an acceptable level of security. Clients MUST discard cached capabilities advertised prior to the start of the TLS handshake.
TLS only provides protection for data sent over a network connection; messages transferred over IMAP or POP3 remain available to server administrators and subject to eavesdropping when transmitted through SMTP or NNTP. TLS is not a substitute for end-to-end message security using MIME security multiparts.
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services with the same password, regardless of TLS encryption. Clients are encouraged to have an operational mode where all mechanisms likely to reveal the user's password to the server are disabled.
The PLAIN SASL client message consists of: optional authorization-id, NUL (%x00), authentication-id, NUL, password. Each of authenticate-id, authorize-id, and password MUST accept up to 255 octets and are encoded as UTF8-SAFE characters.