Network Working Group C. Newman
Internet Draft: Using TLS with IMAP4, POP3 and ACAP Innosoft
Document: draft-newman-tls-imappop-06.txt December 1998
Updates: RFC 1939, 2060, 2244
Using TLS with IMAP4, POP3 and ACAP
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Abstract
This specification defines extensions to IMAP [IMAP4], POP [POP3]
and ACAP [ACAP] which activate TLS [TLS]. This also defines a
simple PLAIN SASL [SASL] mechanism for use underneath strong TLS
encryption with ACAP or other protocols lacking a clear-text login
command.
1. Motivation
The TLS protocol [TLS] (formerly known as SSL) provides a way to
secure an application protocol from tampering and eavesdropping.
Obviously, the option of using such security is desirable for IMAP
[IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL]
authentication mechanisms can provide a lightweight version of this
service, TLS is a full service security layer and is complimentary
to simple authentication-only SASL mechanisms or clear-text
password login commands.
Newman [Page 1]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
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.
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 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 is superior to the use of a separate port for
TLS, as it simplifies implementation of a client security policy of
"use best security available" in addition to the traditional "never
use TLS" and "always use TLS" policies that are common with the
separate port model. Further discussion on this topic is 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].
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 IMAP4, POP3 and ACAP.
2.1. Cipher Suite Requirements
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher
suite is REQUIRED. This is important as it assures that any two
compliant implementations can be configured to interoperate.
Newman [Page 2]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
All other cipher suites are OPTIONAL.
2.2. TLS Operational Mode Security Requirements
Both clients and servers SHOULD have an operational mode where use
of TLS encryption is required to login. Clients MAY have an
operational mode where TLS is used only when advertised by the
server, but login occurs regardless. For backwards compatibility,
servers SHOULD have an operational mode which permits clients to
login when TLS is not used.
2.3. Clear-Text Password Requirements
A server which implements both STARTTLS and a clear-text password
authentication mechanism (including but not limited to the IMAP4
LOGIN command, POP3 PASS command and the PLAIN mechanism in section
6) MUST have an operational mode where all clear-text login
commands and mechanisms are disabled unless TLS encryption is
active.
Furthermore, a server which implements both STARTTLS and a
clear-text password mechanism which is not documented in a
standards track RFC MUST NOT permit use of that mechanism unless
suitable TLS encryption is active.
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:
o 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 reverse lookup).
o If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
o Matching is case-insensitive.
o 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
Newman [Page 3]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
example.com.
o 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.
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-dependant, and is beyond the scope of
this document.
3. IMAP4 STARTTLS extension
When the TLS extension is present in IMAP4, "STARTTLS" is listed as
a capability in response to the CAPABILITY command. This extension
adds a single command, "STARTTLS" to the IMAP4 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.
Newman [Page 4]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
Once TLS has been started, the client SHOULD discard cached
information about server capabilities and 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 IMAP4 is amended as follows:
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. IMAP4 LOGINDISABLED capability
The IMAP4 protocol specification requires the implementation of the
LOGIN command which uses clear-text passwords. Many sites will
choose to disable this command without encryption for all users as
STARTTLS support or stronger SASL mechanisms become available in
IMAP clients. The IMAP4 server MAY advertise that the LOGIN
command is disabled by including the LOGINDISABLED capability in
the capability response.
An IMAP4 client MUST NOT issue the LOGIN command if this capability
is present.
This capability does not remove the need for clients to have an
explicit "don't use clear-text passwords" configuration option or
the equivalent, as a man-in-the-middle attack could remove this
capability from the list of advertised capabilities.
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.
Newman [Page 5]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
STLS
Arguments: none
Restrictions:
Only permitted in AUTHORIZATION state.
Discussion:
A TLS negotiation begins immediately after the CRLF at the
end of the +OK response from the server. A -ERR response
MAY result if a security layer is already active. Once a
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
and the server remains in AUTHORIZATION state, even if
client credentials are supplied during the TLS negotiation.
The AUTH command [POP-AUTH] with the EXTERNAL mechanism
[SASL] MAY be used to authenticate once TLS client
credentials are successfully exchanged, but servers
supporting the STLS command are not required to support the
EXTERNAL mechanism.
Once TLS has been started, the client SHOULD discard cached
information about server capabilities and re-issue the CAPA
command. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list
prior to STLS. The server MAY advertise different
capabilities after STLS.
Possible Responses:
+OK -ERR
Examples:
C: STLS
S: +OK Begin TLS negotiation
<TLS negotiation, further commands are under TLS layer>
...
C: STLS
S: -ERR Command not permitted when TLS active
5. ACAP STARTTLS extension
When the TLS extension is present in ACAP, "STARTTLS" is listed as
a capability in the ACAP greeting. No arguments to this capability
are defined at this time. This extension adds a single command,
"STARTTLS" to the ACAP protocol which is used to begin a TLS
Newman [Page 6]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
negotiation.
5.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.
After the TLS layer is established, the server MUST re-issue an
untagged ACAP greeting. This is necessary to protect against
man-in-the-middle attacks which alter the capabilities list prior
to STARTTLS. The client SHOULD discard cached capability
information and replace it with the information from the new ACAP
greeting. The server MAY advertise different capabilities after
STARTTLS.
The formal syntax for ACAP is amended as follows:
command_any =/ "STARTTLS"
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
6. PLAIN SASL mechanism
Clear-text passwords are simple, interoperate with almost all
existing operating system authentication databases, and are useful
for a smooth transition to a more secure password-based
authentication mechanism. The drawback is that they are
Newman [Page 7]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
unacceptable for use over an unencrypted network connection.
This defines the "PLAIN" SASL mechanism for use with ACAP and other
protocols with no clear-text login command. The PLAIN SASL
mechanism MUST NOT be used unless strong TLS encryption or an
equivalent strong encryption layer is also in use. In particular,
if a strong encryption layer is not currently in use in the
session, a client MUST NOT attempt to authenticate via the PLAIN
SASL mechanism.
The mechanism consists of a single message from the client to the
server. The client sends the authorization identity (identity to
login as), followed by a US-ASCII NUL character, followed by the
authentication identity (identity whose password will be used),
followed by a US-ASCII NUL character, followed by the clear-text
password. The client may leave the authorization identity empty to
indicate that it is the same as the authentication identity.
The server will verify the authentication identity and password
with the system authentication database and verify that the
authentication credentials permit the client to login as the
authorization identity. If both steps succeed, the user is logged
in.
The server MAY also use the password to initialize any new
authentication database, such as one suitable for CRAM-MD5
[CRAM-MD5].
Non-US-ASCII characters are permitted as long as they are
represented in UTF-8 [UTF-8]. Use of non-visible characters or
characters which a user may be unable to enter on some keyboards is
discouraged.
Clients are encouraged to support pure-binary passwords as they may
be safe from dictionary attacks. However, if the client offers a
character-based interface for password entry it MUST use UTF-8
encoding for the characters.
The formal grammar for the client message using Augmented BNF
[ABNF] follows.
message = [authorize-id] NUL authenticate-id NUL password
authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets
password = *NZ-OCTET ; MUST accept up to 255 octets
NUL = %x00
NZ-OCTET = %x01-FF ; all non-NUL octet values
Newman [Page 8]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
Here is an example of how this might be used to initialize a
CRAM-MD5 authentication database for ACAP:
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
C: a001 AUTHENTICATE "CRAM-MD5"
S: + "<1896.697170952@postoffice.reston.mci.net>"
C: "tim b913a602c7eda7a495b4e6e7334d3890"
S: a001 NO (TRANSITION-NEEDED)
"Please change your password, or use TLS to login"
C: a002 STARTTLS
S: a002 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized
Note: In this example, <NUL> represents a single ASCII NUL octet.
Here is an example session where a client erroneously attempts to
use PLAIN prior to starting TLS:
Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS)
C: a001 AUTHENTICATE "PLAIN" {21}
S: a001 NO (ENCRYPT-NEEDED)
"Can't use PLAIN without encryption"
7. imaps and pop3s ports
The common practice of using a separate port for a "secure" version
of each protocol has a number of disadvantages in the IMAP [IMAP4],
ACAP [ACAP] and POP [POP3] environment. Rather than using the best
security available, it means that clients have to be explicitly
configured to use the separate secure port or suffer the
performance loss of probing for active ports. Furthermore this is
even more serious as it would require a new URL scheme which could
only be resolved by TLS-enabled clients.
Separate "imaps" and "pop3s" ports were registered for use with
Newman [Page 9]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
TLS. Use of these ports is discouraged in favor of the STARTTLS or
STLS command.
One of the arguments used in favor of the separate port technique
is that it simplifies configuration of firewalls which filter by IP
port. However, a quality server implementation running on the
standard port can be configured to require use of the STARTTLS
command or a suitably strong SASL mechanism for non-local
connections. This provides superior functionality as the client
need not be re-configured for use outside the firewall and faster
challenge/response SASL mechanisms may be acceptable to many sites
for non-local connections.
8. Registration
This document constitutes registration of the "STARTTLS" and
"LOGINDISABLED" IMAP4 capabilities as required by section 7.2.1 of
RFC 2060 [IMAP4].
This document defines the "STLS" POP3 capability as follows:
CAPA tag: STLS
Arguments: none
Added commands: STLS
Standard commands affected: May enable USER/PASS as a side-effect.
CAPA command should be re-issued after successful completion.
Announced states/Valid states: AUTHORIZATION state only.
Specification reference: this memo
This document defines the "STARTTLS" ACAP capability as follows:
Capability name: STARTTLS
Capability keyword: STARTTLS
Capability arguments: none
Published Specification(s): this memo
Person and email address for further information:
see author's address section below
This document defines the "PLAIN" SASL mechanism as follows:
SASL mechanism name: PLAIN
Security Considerations: See section 9 of this memo
Published specification: this memo
Person & email address to contact for further information:
see author's address section below
Intended usage: COMMON
Author/Change controller: see author's address section below
Newman [Page 10]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
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. In order to detect such an attack, clients SHOULD
either warn the user when session privacy is not active, 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 need to 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 SHOULD discard cached information about
server capabilities advertised prior to the start of the TLS
handshake.
Clients are encouraged to clearly distinguish between a level of
encryption known to be vulnerable to a reasonable attack using
modern hardware (such as encryption with a 40-bit key) and one
which is believed to be safe from such an attack.
When the PLAIN mechanism (or the IMAP LOGIN or POP3 PASS command)
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. Stronger SASL
authentication mechanisms such as Kerberos address this issue.
Use of clear-text login mechanisms (e.g., the IMAP LOGIN command,
POP3 PASS command or the PLAIN mechanism) without a suitable
encryption layer, such as that provided by TLS, expose the user's
password to a common network eavesdropping attack. Therefore, the
PLAIN mechanism MUST NOT be used unless a suitable encryption
layer, such as that provided by TLS, is in use. In addition, this
is the primary motivation for the clear-text password requirements
in section 2.3.
Additional security requirements are discussed in section 2.
Newman [Page 11]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
10. References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997.
[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
Protocol", RFC 2244, Innosoft, Netscape, November 1997.
[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", RFC 2195, MCI, September 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
Carnegie-Mellon University, December 1994.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
[MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for
MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted
Information Systems, CyberCash, Innosoft International, October
1995.
[POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
[POP3EXT] Gellens, R., Newman, C., Lundblade, L., "POP3 Extension
Mechanism", RFC 2449, November 1998.
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
Carnegie Mellon, December 1994.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, Netscape Communications, October 1997.
[TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in
progress.
[UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
RFC 2279, Alis Technologies, January 1998.
11. Author's Address
Chris Newman
Innosoft International, Inc.
Newman [Page 12]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
1050 Lakes Drive
West Covina, CA 91790 USA
Email: chris.newman@innosoft.com
A. Appendix -- Non-Compliant Use of PLAIN
RFC 2316 states that "no protocol that relies on passwords sent
over unencrypted channels is acceptable." Implementations of the
PLAIN mechanism which don't require use of encryption have been
released by multiple vendors. Although such use is not compliant
with this specification, it is mentioned here so that it can be
considered when performing a security analysis of a site or
interpreting security warnings.
Some implementations have invented undocumented mechanisms to
provide unencrypted password authentication. This author believes
it is preferable to abuse the PLAIN mechanism rather than using an
undocumented channel for unencrypted passwords. This is an
additional motivation behind the clear-text password requirements
in section 2.3.
B. 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 TLS required 2.2
server SHOULD have mode where TLS not required 2.2
MUST have mode where unencrypted password not permitted 2.3
MUST NOT permit non-standard unencrypted password use 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 SHOULD discard cached information 3.1,4,5.1,9
Newman [Page 13]
Internet Draft Using TLS with IMAP4, POP3 and ACAP December 1998
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
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
client SHOULD warn when session privacy not active
or refuse to proceed without acceptable security level 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 TLS encryption active 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
Newman [Page 14]