Network Working Group                                          C. Newman
Internet Draft: Using TLS with IMAP4, POP3 and ACAP             Innosoft
Document: draft-newman-tls-imappop-04.txt                     April 1998


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


Introduction

     The TLS protocol [TLS] (formerly known as SSL) provides a way to
     secure a connection 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 also useful in
     combination with plain-text password logins and other simple
     mechanisms as it doesn't require a site to upgrade its
     authentication database.

     This specification defines extensions to IMAP4, POP3 and ACAP which
     activate TLS.  This also defines a simple PLAIN SASL mechanism for
     use underneath strong TLS encryption with ACAP or other protocols
     lacking a plain-text login command.







Newman                                                          [Page 1]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


1. Conventions Used in this Document

     The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
     NOT", and "MAY" 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. Cipher Suite Requirements

     This application profile of TLS follows the standard "Mandatory
     Cipher Suites" requirement as documented in the TLS specification
     [TLS].  Implementations MUST NOT assume any other cipher suites are
     present.


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
               NO - security layer already active
               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



Newman                                                          [Page 2]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


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

4. POP3 STLS extension

   The POP3 STLS 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.

      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.



Newman                                                          [Page 3]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


             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 Security Layer already 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
     negotiation.


5.1. STARTTLS Command

   Arguments:  none

   Responses:  no specific responses for this command

   Result:     OK - begin TLS negotiation
               NO - security layer already active
               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



Newman                                                          [Page 4]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


      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

     Plain-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
     unacceptable for use unencrypted over the network.

     This defines a PLAIN SASL mechanism for use with ACAP and future
     protocols with no plain-text login command.  This MUST NOT be
     implemented unless TLS (or an equivalent security layer) is also
     implemented.

     The SASL [SASL] mechanism name is "PLAIN".

     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),



Newman                                                          [Page 5]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


     followed by a US-ASCII NUL character, followed by the plain-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], ACAP's mandatory-to-implement authentication mechanism.

     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.

     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        = *UTF8-SAFE
                       ; MUST accept passwords up to 255 octets

     NUL             = %x00

     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




Newman                                                          [Page 6]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


     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" "PLAIN" "EXTERNAL")
                    (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>
                 C: a003 AUTHENTICATE "PLAIN" {21+}
                 C: <NUL>tim<NUL>tanstaaftanstaaf
                 S: a003 OK AUTHENTICATE completed

     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" "EXTERNAL")
                    (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.  For IMAP and ACAP,
     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
     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



Newman                                                          [Page 7]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


     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
     non-plain-text SASL mechanisms may be acceptable to many sites for
     non-local connections.


8. Security Considerations

     The mechanisms described in this document only apply to protecting
     a single 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.  Protecting messages requires an object security mechanism
     using MIME security multiparts [MIME-SEC].

     An active attacker can remove STARTTLS from the capability list.
     In order to detect such an attack, clients SHOULD either warn the
     user when session protection is not active, or be configurable to
     refuse to proceed without an acceptable level of security.

     An active 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 an active attacker.  For this
     reason, clients SHOULD discard cached information about server
     capabilities advertised prior to the start of the TLS handshake.

     When the PLAIN mechanism is used with TLS, the server gains the
     ability to impersonate the user to all services with the same
     password.  The PLAIN mechanism MUST NOT be used without an active
     encryption layer using a key with an effective key length greater
     than 56 bits, otherwise a passive attacker can gain the ability to
     impersonate the user.


9. References

     [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
     November 1997.





Newman                                                          [Page 8]


Internet Draft    Using TLS with IMAP4, POP3 and ACAP         April 1998


     [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, "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, Newman, Lundblade "POP3 Extension Mechanism",
     Work in progress.

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

     [SASL] Myers, "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.


10. Author's Address

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

     Email: chris.newman@innosoft.com




Newman                                                          [Page 9]