rfc2595.txt

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


RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999


      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 MUST discard cached
             information about server capabilities and SHOULD 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










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


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
               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 MUST 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")




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


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 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 advertised or used unless a strong encryption layer (such
   as the provided by TLS) is active or backwards compatibility dictates
   otherwise.

   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.

   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        = 1*UTF8-SAFE      ; MUST accept 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



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


   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: + "<[e-mail]>"
               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.

7. imaps and pop3s ports

   Separate "imaps" and "pop3s" ports were registered for use with SSL.
   Use of these ports is discouraged in favor of the STARTTLS or STLS
   commands.

   A number of problems have been observed with separate ports for
   "secure" variants of protocols.  This is an attempt to enumerate some
   of those problems.

   - Separate ports lead to a separate URL scheme which intrudes into
     the user interface in inappropriate ways.  For example, many web
     pages use language like "click here if your browser supports SSL."
     This is a decision the browser is often more capable of making than
     the user.

   - Separate ports imply a model of either "secure" or "not secure."
     This can be misleading in a number of ways.  First, the "secure"
     port may not in fact be acceptably secure as an export-crippled
     cipher suite might be in use.  This can mislead users into a false
     sense of security.  Second, the normal port might in fact be
     secured by using a SASL mechanism which includes a security layer.
     Thus the separate port distinction makes the complex topic of
     security policy even more confusing.  One common result of this
     confusion is that firewall administrators are often misled into



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


     permitting the "secure" port and blocking the standard port.  This
     could be a poor choice given the common use of SSL with a 40-bit
     key encryption layer and plain-text password authentication is less
     secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.

   - Use of separate ports for SSL has caused clients to implement only
     two security policies: use SSL or don't use SSL.  The desirable
     security policy "use TLS when available" would be cumbersome with
     the separate port model, but is simple with STARTTLS.

   - Port numbers are a limited resource.  While they are not yet in
     short supply, it is unwise to set a precedent that could double (or
     worse) the speed of their consumption.


8. IANA Considerations

   This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
   IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].

   The registration for the POP3 "STLS" capability 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

   The registration for the ACAP "STARTTLS" capability 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

   The registration for the PLAIN SASL mechanism 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                      Standards Track                    [Page 10]

RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999