doc/rfc2595.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Request for Comments: 2595                                      Innosoft
   9 Category: Standards Track                                      June 1999
  10
  11
  12                    Using TLS with IMAP, POP3 and ACAP
  13
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  26
  27 1. Motivation
  28
  29    The TLS protocol (formerly known as SSL) provides a way to secure an
  30    application protocol from tampering and eavesdropping.  The option of
  31    using such security is desirable for IMAP, POP and ACAP due to common
  32    connection eavesdropping and hijacking attacks [AUTH].  Although
  33    advanced SASL authentication mechanisms can provide a lightweight
  34    version of this service, TLS is complimentary to simple
  35    authentication-only SASL mechanisms or deployed clear-text password
  36    login commands.
  37
  38    Many sites have a high investment in authentication infrastructure
  39    (e.g., a large database of a one-way-function applied to user
  40    passwords), so a privacy layer which is not tightly bound to user
  41    authentication can protect against network eavesdropping attacks
  42    without requiring a new authentication infrastructure and/or forcing
  43    all users to change their password.  Recognizing that such sites will
  44    desire simple password authentication in combination with TLS
  45    encryption, this specification defines the PLAIN SASL mechanism for
  46    use with protocols which lack a simple password authentication
  47    command such as ACAP and SMTP.  (Note there is a separate RFC for the
  48    STARTTLS command in SMTP [SMTPTLS].)
  49
  50    There is a strong desire in the IETF to eliminate the transmission of
  51    clear-text passwords over unencrypted channels.  While SASL can be
  52    used for this purpose, TLS provides an additional tool with different
  53    deployability characteristics.  A server supporting both TLS with
  54
  55
  56
  57
  58 Newman                      Standards Track                     [Page 1]
  59 \f
  60 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
  61
  62
  63    simple passwords and a challenge/response SASL mechanism is likely to
  64    interoperate with a wide variety of clients without resorting to
  65    unencrypted clear-text passwords.
  66
  67    The STARTTLS command rectifies a number of the problems with using a
  68    separate port for a "secure" protocol variant.  Some of these are
  69    mentioned in section 7.
  70
  71 1.1. Conventions Used in this Document
  72
  73    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
  74    "MAY", and "OPTIONAL" in this document are to be interpreted as
  75    described in "Key words for use in RFCs to Indicate Requirement
  76    Levels" [KEYWORDS].
  77
  78    Terms related to authentication are defined in "On Internet
  79    Authentication" [AUTH].
  80
  81    Formal syntax is defined using ABNF [ABNF].
  82
  83    In examples, "C:" and "S:" indicate lines sent by the client and
  84    server respectively.
  85
  86 2. Basic Interoperability and Security Requirements
  87
  88    The following requirements apply to all implementations of the
  89    STARTTLS extension for IMAP, POP3 and ACAP.
  90
  91 2.1. Cipher Suite Requirements
  92
  93    Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
  94    suite is REQUIRED.  This is important as it assures that any two
  95    compliant implementations can be configured to interoperate.
  96
  97    All other cipher suites are OPTIONAL.
  98
  99 2.2. Privacy Operational Mode Security Requirements
 100
 101    Both clients and servers SHOULD have a privacy operational mode which
 102    refuses authentication unless successful activation of an encryption
 103    layer (such as that provided by TLS) occurs prior to or at the time
 104    of authentication and which will terminate the connection if that
 105    encryption layer is deactivated.  Implementations are encouraged to
 106    have flexibility with respect to the minimal encryption strength or
 107    cipher suites permitted.  A minimalist approach to this
 108    recommendation would be an operational mode where the
 109    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to
 110    permitting authentication.
 111
 112
 113
 114 Newman                      Standards Track                     [Page 2]
 115 \f
 116 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 117
 118
 119    Clients MAY have an operational mode which uses encryption only when
 120    it is advertised by the server, but authentication continues
 121    regardless.  For backwards compatibility, servers SHOULD have an
 122    operational mode where only the authentication mechanisms required by
 123    the relevant base protocol specification are needed to successfully
 124    authenticate.
 125
 126 2.3. Clear-Text Password Requirements
 127
 128    Clients and servers which implement STARTTLS MUST be configurable to
 129    refuse all clear-text login commands or mechanisms (including both
 130    standards-track and nonstandard mechanisms) unless an encryption
 131    layer of adequate strength is active.  Servers which allow
 132    unencrypted clear-text logins SHOULD be configurable to refuse
 133    clear-text logins both for the entire server, and on a per-user
 134    basis.
 135
 136 2.4. Server Identity Check
 137
 138    During the TLS negotiation, the client MUST check its understanding
 139    of the server hostname against the server's identity as presented in
 140    the server Certificate message, in order to prevent man-in-the-middle
 141    attacks.  Matching is performed according to these rules:
 142
 143    - The client MUST use the server hostname it used to open the
 144      connection as the value to compare against the server name as
 145      expressed in the server certificate.  The client MUST NOT use any
 146      form of the server hostname derived from an insecure remote source
 147      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
 148
 149    - If a subjectAltName extension of type dNSName is present in the
 150      certificate, it SHOULD be used as the source of the server's
 151      identity.
 152
 153    - Matching is case-insensitive.
 154
 155    - A "*" wildcard character MAY be used as the left-most name
 156      component in the certificate.  For example, *.example.com would
 157      match a.example.com, foo.example.com, etc. but would not match
 158      example.com.
 159
 160    - If the certificate contains multiple names (e.g. more than one
 161      dNSName field), then a match with any one of the fields is
 162      considered acceptable.
 163
 164    If the match fails, the client SHOULD either ask for explicit user
 165    confirmation, or terminate the connection and indicate the server's
 166    identity is suspect.
 167
 168
 169
 170 Newman                      Standards Track                     [Page 3]
 171 \f
 172 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 173
 174
 175 2.5. TLS Security Policy Check
 176
 177    Both the client and server MUST check the result of the STARTTLS
 178    command and subsequent TLS negotiation to see whether acceptable
 179    authentication or privacy was achieved.  Ignoring this step
 180    completely invalidates using TLS for security.  The decision about
 181    whether acceptable authentication or privacy was achieved is made
 182    locally, is implementation-dependent, and is beyond the scope of this
 183    document.
 184
 185 3. IMAP STARTTLS extension
 186
 187    When the TLS extension is present in IMAP, "STARTTLS" is listed as a
 188    capability in response to the CAPABILITY command.  This extension
 189    adds a single command, "STARTTLS" to the IMAP protocol which is used
 190    to begin a TLS negotiation.
 191
 192 3.1. STARTTLS Command
 193
 194    Arguments:  none
 195
 196    Responses:  no specific responses for this command
 197
 198    Result:     OK - begin TLS negotiation
 199                BAD - command unknown or arguments invalid
 200
 201       A TLS negotiation begins immediately after the CRLF at the end of
 202       the tagged OK response from the server.  Once a client issues a
 203       STARTTLS command, it MUST NOT issue further commands until a
 204       server response is seen and the TLS negotiation is complete.
 205
 206       The STARTTLS command is only valid in non-authenticated state.
 207       The server remains in non-authenticated state, even if client
 208       credentials are supplied during the TLS negotiation.  The SASL
 209       [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
 210       client credentials are successfully exchanged, but servers
 211       supporting the STARTTLS command are not required to support the
 212       EXTERNAL mechanism.
 213
 214       Once TLS has been started, the client MUST discard cached
 215       information about server capabilities and SHOULD re-issue the
 216       CAPABILITY command.  This is necessary to protect against
 217       man-in-the-middle attacks which alter the capabilities list prior
 218       to STARTTLS.  The server MAY advertise different capabilities
 219       after STARTTLS.
 220
 221       The formal syntax for IMAP is amended as follows:
 222
 223
 224
 225
 226 Newman                      Standards Track                     [Page 4]
 227 \f
 228 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 229
 230
 231         command_any   =/  "STARTTLS"
 232
 233    Example:    C: a001 CAPABILITY
 234                S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
 235                S: a001 OK CAPABILITY completed
 236                C: a002 STARTTLS
 237                S: a002 OK Begin TLS negotiation now
 238                <TLS negotiation, further commands are under TLS layer>
 239                C: a003 CAPABILITY
 240                S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
 241                S: a003 OK CAPABILITY completed
 242                C: a004 LOGIN joe password
 243                S: a004 OK LOGIN completed
 244
 245 3.2. IMAP LOGINDISABLED capability
 246
 247    The current IMAP protocol specification (RFC 2060) requires the
 248    implementation of the LOGIN command which uses clear-text passwords.
 249    Many sites may choose to disable this command unless encryption is
 250    active for security reasons.  An IMAP server MAY advertise that the
 251    LOGIN command is disabled by including the LOGINDISABLED capability
 252    in the capability response.  Such a server will respond with a tagged
 253    "NO" response to any attempt to use the LOGIN command.
 254
 255    An IMAP server which implements STARTTLS MUST implement support for
 256    the LOGINDISABLED capability on unencrypted connections.
 257
 258    An IMAP client which complies with this specification MUST NOT issue
 259    the LOGIN command if this capability is present.
 260
 261    This capability is useful to prevent clients compliant with this
 262    specification from sending an unencrypted password in an environment
 263    subject to passive attacks.  It has no impact on an environment
 264    subject to active attacks as a man-in-the-middle attacker can remove
 265    this capability.  Therefore this does not relieve clients of the need
 266    to follow the privacy mode recommendation in section 2.2.
 267
 268    Servers advertising this capability will fail to interoperate with
 269    many existing compliant IMAP clients and will be unable to prevent
 270    those clients from disclosing the user's password.
 271
 272 4. POP3 STARTTLS extension
 273
 274    The POP3 STARTTLS extension adds the STLS command to POP3 servers.
 275    If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
 276    also be implemented to avoid the need for client probing of multiple
 277    commands.  The capability name "STLS" indicates this command is
 278    present and permitted in the current state.
 279
 280
 281
 282 Newman                      Standards Track                     [Page 5]
 283 \f
 284 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 285
 286
 287       STLS
 288
 289          Arguments: none
 290
 291          Restrictions:
 292              Only permitted in AUTHORIZATION state.
 293
 294          Discussion:
 295              A TLS negotiation begins immediately after the CRLF at the
 296              end of the +OK response from the server.  A -ERR response
 297              MAY result if a security layer is already active.  Once a
 298              client issues a STLS command, it MUST NOT issue further
 299              commands until a server response is seen and the TLS
 300              negotiation is complete.
 301
 302              The STLS command is only permitted in AUTHORIZATION state
 303              and the server remains in AUTHORIZATION state, even if
 304              client credentials are supplied during the TLS negotiation.
 305              The AUTH command [POP-AUTH] with the EXTERNAL mechanism
 306              [SASL] MAY be used to authenticate once TLS client
 307              credentials are successfully exchanged, but servers
 308              supporting the STLS command are not required to support the
 309              EXTERNAL mechanism.
 310
 311              Once TLS has been started, the client MUST discard cached
 312              information about server capabilities and SHOULD re-issue
 313              the CAPA command.  This is necessary to protect against
 314              man-in-the-middle attacks which alter the capabilities list
 315              prior to STLS.  The server MAY advertise different
 316              capabilities after STLS.
 317
 318          Possible Responses:
 319              +OK -ERR
 320
 321          Examples:
 322              C: STLS
 323              S: +OK Begin TLS negotiation
 324              <TLS negotiation, further commands are under TLS layer>
 325                ...
 326              C: STLS
 327              S: -ERR Command not permitted when TLS active
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Newman                      Standards Track                     [Page 6]
 339 \f
 340 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 341
 342
 343 5. ACAP STARTTLS extension
 344
 345    When the TLS extension is present in ACAP, "STARTTLS" is listed as a
 346    capability in the ACAP greeting.  No arguments to this capability are
 347    defined at this time.  This extension adds a single command,
 348    "STARTTLS" to the ACAP protocol which is used to begin a TLS
 349    negotiation.
 350
 351 5.1. STARTTLS Command
 352
 353    Arguments:  none
 354
 355    Responses:  no specific responses for this command
 356
 357    Result:     OK - begin TLS negotiation
 358                BAD - command unknown or arguments invalid
 359
 360       A TLS negotiation begins immediately after the CRLF at the end of
 361       the tagged OK response from the server.  Once a client issues a
 362       STARTTLS command, it MUST NOT issue further commands until a
 363       server response is seen and the TLS negotiation is complete.
 364
 365       The STARTTLS command is only valid in non-authenticated state.
 366       The server remains in non-authenticated state, even if client
 367       credentials are supplied during the TLS negotiation.  The SASL
 368       [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
 369       client credentials are successfully exchanged, but servers
 370       supporting the STARTTLS command are not required to support the
 371       EXTERNAL mechanism.
 372
 373       After the TLS layer is established, the server MUST re-issue an
 374       untagged ACAP greeting.  This is necessary to protect against
 375       man-in-the-middle attacks which alter the capabilities list prior
 376       to STARTTLS.  The client MUST discard cached capability
 377       information and replace it with the information from the new ACAP
 378       greeting.  The server MAY advertise different capabilities after
 379       STARTTLS.
 380
 381       The formal syntax for ACAP is amended as follows:
 382
 383         command_any   =/  "STARTTLS"
 384
 385    Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
 386                C: a002 STARTTLS
 387                S: a002 OK "Begin TLS negotiation now"
 388                <TLS negotiation, further commands are under TLS layer>
 389                S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
 390
 391
 392
 393
 394 Newman                      Standards Track                     [Page 7]
 395 \f
 396 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 397
 398
 399 6. PLAIN SASL mechanism
 400
 401    Clear-text passwords are simple, interoperate with almost all
 402    existing operating system authentication databases, and are useful
 403    for a smooth transition to a more secure password-based
 404    authentication mechanism.  The drawback is that they are unacceptable
 405    for use over an unencrypted network connection.
 406
 407    This defines the "PLAIN" SASL mechanism for use with ACAP and other
 408    protocols with no clear-text login command.  The PLAIN SASL mechanism
 409    MUST NOT be advertised or used unless a strong encryption layer (such
 410    as the provided by TLS) is active or backwards compatibility dictates
 411    otherwise.
 412
 413    The mechanism consists of a single message from the client to the
 414    server.  The client sends the authorization identity (identity to
 415    login as), followed by a US-ASCII NUL character, followed by the
 416    authentication identity (identity whose password will be used),
 417    followed by a US-ASCII NUL character, followed by the clear-text
 418    password.  The client may leave the authorization identity empty to
 419    indicate that it is the same as the authentication identity.
 420
 421    The server will verify the authentication identity and password with
 422    the system authentication database and verify that the authentication
 423    credentials permit the client to login as the authorization identity.
 424    If both steps succeed, the user is logged in.
 425
 426    The server MAY also use the password to initialize any new
 427    authentication database, such as one suitable for CRAM-MD5
 428    [CRAM-MD5].
 429
 430    Non-US-ASCII characters are permitted as long as they are represented
 431    in UTF-8 [UTF-8].  Use of non-visible characters or characters which
 432    a user may be unable to enter on some keyboards is discouraged.
 433
 434    The formal grammar for the client message using Augmented BNF [ABNF]
 435    follows.
 436
 437    message         = [authorize-id] NUL authenticate-id NUL password
 438    authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 439    authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 440    password        = 1*UTF8-SAFE      ; MUST accept up to 255 octets
 441    NUL             = %x00
 442    UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
 443                      UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
 444    UTF8-1          = %x80-BF
 445    UTF8-2          = %xC0-DF UTF8-1
 446    UTF8-3          = %xE0-EF 2UTF8-1
 447
 448
 449
 450 Newman                      Standards Track                     [Page 8]
 451 \f
 452 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 453
 454
 455    UTF8-4          = %xF0-F7 3UTF8-1
 456    UTF8-5          = %xF8-FB 4UTF8-1
 457    UTF8-6          = %xFC-FD 5UTF8-1
 458
 459    Here is an example of how this might be used to initialize a CRAM-MD5
 460    authentication database for ACAP:
 461
 462    Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
 463                C: a001 AUTHENTICATE "CRAM-MD5"
 464                S: + "<1896.697170952@postoffice.reston.mci.net>"
 465                C: "tim b913a602c7eda7a495b4e6e7334d3890"
 466                S: a001 NO (TRANSITION-NEEDED)
 467                   "Please change your password, or use TLS to login"
 468                C: a002 STARTTLS
 469                S: a002 OK "Begin TLS negotiation now"
 470                <TLS negotiation, further commands are under TLS layer>
 471                S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
 472                C: a003 AUTHENTICATE "PLAIN" {21+}
 473                C: <NUL>tim<NUL>tanstaaftanstaaf
 474                S: a003 OK CRAM-MD5 password initialized
 475
 476    Note: In this example, <NUL> represents a single ASCII NUL octet.
 477
 478 7. imaps and pop3s ports
 479
 480    Separate "imaps" and "pop3s" ports were registered for use with SSL.
 481    Use of these ports is discouraged in favor of the STARTTLS or STLS
 482    commands.
 483
 484    A number of problems have been observed with separate ports for
 485    "secure" variants of protocols.  This is an attempt to enumerate some
 486    of those problems.
 487
 488    - Separate ports lead to a separate URL scheme which intrudes into
 489      the user interface in inappropriate ways.  For example, many web
 490      pages use language like "click here if your browser supports SSL."
 491      This is a decision the browser is often more capable of making than
 492      the user.
 493
 494    - Separate ports imply a model of either "secure" or "not secure."
 495      This can be misleading in a number of ways.  First, the "secure"
 496      port may not in fact be acceptably secure as an export-crippled
 497      cipher suite might be in use.  This can mislead users into a false
 498      sense of security.  Second, the normal port might in fact be
 499      secured by using a SASL mechanism which includes a security layer.
 500      Thus the separate port distinction makes the complex topic of
 501      security policy even more confusing.  One common result of this
 502      confusion is that firewall administrators are often misled into
 503
 504
 505
 506 Newman                      Standards Track                     [Page 9]
 507 \f
 508 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 509
 510
 511      permitting the "secure" port and blocking the standard port.  This
 512      could be a poor choice given the common use of SSL with a 40-bit
 513      key encryption layer and plain-text password authentication is less
 514      secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
 515
 516    - Use of separate ports for SSL has caused clients to implement only
 517      two security policies: use SSL or don't use SSL.  The desirable
 518      security policy "use TLS when available" would be cumbersome with
 519      the separate port model, but is simple with STARTTLS.
 520
 521    - Port numbers are a limited resource.  While they are not yet in
 522      short supply, it is unwise to set a precedent that could double (or
 523      worse) the speed of their consumption.
 524
 525
 526 8. IANA Considerations
 527
 528    This constitutes registration of the "STARTTLS" and "LOGINDISABLED"
 529    IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
 530
 531    The registration for the POP3 "STLS" capability follows:
 532
 533    CAPA tag:                   STLS
 534    Arguments:                  none
 535    Added commands:             STLS
 536    Standard commands affected: May enable USER/PASS as a side-effect.
 537      CAPA command SHOULD be re-issued after successful completion.
 538    Announced states/Valid states: AUTHORIZATION state only.
 539    Specification reference:    this memo
 540
 541    The registration for the ACAP "STARTTLS" capability follows:
 542
 543    Capability name:            STARTTLS
 544    Capability keyword:         STARTTLS
 545    Capability arguments:       none
 546    Published Specification(s): this memo
 547    Person and email address for further information:
 548        see author's address section below
 549
 550    The registration for the PLAIN SASL mechanism follows:
 551
 552    SASL mechanism name:        PLAIN
 553    Security Considerations:    See section 9 of this memo
 554    Published specification:    this memo
 555    Person & email address to contact for further information:
 556        see author's address section below
 557    Intended usage:             COMMON
 558    Author/Change controller:   see author's address section below
 559
 560
 561
 562 Newman                      Standards Track                    [Page 10]
 563 \f
 564 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 565
 566
 567 9. Security Considerations
 568
 569    TLS only provides protection for data sent over a network connection.
 570    Messages transferred over IMAP or POP3 are still available to server
 571    administrators and usually subject to eavesdropping, tampering and
 572    forgery when transmitted through SMTP or NNTP.  TLS is no substitute
 573    for an end-to-end message security mechanism using MIME security
 574    multiparts [MIME-SEC].
 575
 576    A man-in-the-middle attacker can remove STARTTLS from the capability
 577    list or generate a failure response to the STARTTLS command.  In
 578    order to detect such an attack, clients SHOULD warn the user when
 579    session privacy is not active and/or be configurable to refuse to
 580    proceed without an acceptable level of security.
 581
 582    A man-in-the-middle attacker can always cause a down-negotiation to
 583    the weakest authentication mechanism or cipher suite available.  For
 584    this reason, implementations SHOULD be configurable to refuse weak
 585    mechanisms or cipher suites.
 586
 587    Any protocol interactions prior to the TLS handshake are performed in
 588    the clear and can be modified by a man-in-the-middle attacker.  For
 589    this reason, clients MUST discard cached information about server
 590    capabilities advertised prior to the start of the TLS handshake.
 591
 592    Clients are encouraged to clearly indicate when the level of
 593    encryption active is known to be vulnerable to attack using modern
 594    hardware (such as encryption keys with 56 bits of entropy or less).
 595
 596    The LOGINDISABLED IMAP capability (discussed in section 3.2) only
 597    reduces the potential for passive attacks, it provides no protection
 598    against active attacks.  The responsibility remains with the client
 599    to avoid sending a password over a vulnerable channel.
 600
 601    The PLAIN mechanism relies on the TLS encryption layer for security.
 602    When used without TLS, it is vulnerable to a common network
 603    eavesdropping attack.  Therefore PLAIN MUST NOT be advertised or used
 604    unless a suitable TLS encryption layer is active or backwards
 605    compatibility dictates otherwise.
 606
 607    When the PLAIN mechanism is used, the server gains the ability to
 608    impersonate the user to all services with the same password
 609    regardless of any encryption provided by TLS or other network privacy
 610    mechanisms.  While many other authentication mechanisms have similar
 611    weaknesses, stronger SASL mechanisms such as Kerberos address this
 612    issue.  Clients are encouraged to have an operational mode where all
 613    mechanisms which are likely to reveal the user's password to the
 614    server are disabled.
 615
 616
 617
 618 Newman                      Standards Track                    [Page 11]
 619 \f
 620 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 621
 622
 623    The security considerations for TLS apply to STARTTLS and the
 624    security considerations for SASL apply to the PLAIN mechanism.
 625    Additional security requirements are discussed in section 2.
 626
 627 10. References
 628
 629    [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
 630               Specifications: ABNF", RFC 2234, November 1997.
 631
 632    [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
 633               Configuration Access Protocol", RFC 2244, November 1997.
 634
 635    [AUTH]     Haller, N. and R. Atkinson, "On Internet Authentication",
 636               RFC 1704, October 1994.
 637
 638    [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
 639               AUTHorize Extension for Simple Challenge/Response", RFC
 640               2195, September 1997.
 641
 642    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
 643               4rev1", RFC 2060, December 1996.
 644
 645    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 646               Requirement Levels", BCP 14, RFC 2119, March 1997.
 647
 648    [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
 649               "Security Multiparts for MIME: Multipart/Signed and
 650               Multipart/Encrypted", RFC 1847, October 1995.
 651
 652    [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
 653               STD 53, RFC 1939, May 1996.
 654
 655    [POP3EXT]  Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension
 656               Mechanism", RFC 2449, November 1998.
 657
 658    [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
 659               December 1994.
 660
 661    [SASL]     Myers, J., "Simple Authentication and Security Layer
 662               (SASL)", RFC 2222, October 1997.
 663
 664    [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
 665               TLS", RFC 2487, January 1999.
 666
 667    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 668               RFC 2246, January 1999.
 669
 670
 671
 672
 673
 674 Newman                      Standards Track                    [Page 12]
 675 \f
 676 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 677
 678
 679    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
 680               10646", RFC 2279, January 1998.
 681
 682
 683 11. Author's Address
 684
 685    Chris Newman
 686    Innosoft International, Inc.
 687    1050 Lakes Drive
 688    West Covina, CA 91790 USA
 689
 690    EMail: chris.newman@innosoft.com
 691
 692
 693 A. Appendix -- Compliance Checklist
 694
 695    An implementation is not compliant if it fails to satisfy one or more
 696    of the MUST requirements for the protocols it implements.  An
 697    implementation that satisfies all the MUST and all the SHOULD
 698    requirements for its protocols is said to be "unconditionally
 699    compliant"; one that satisfies all the MUST requirements but not all
 700    the SHOULD requirements for its protocols is said to be
 701    "conditionally compliant".
 702
 703    Rules                                                 Section
 704    -----                                                 -------
 705    Mandatory-to-implement Cipher Suite                      2.1
 706    SHOULD have mode where encryption required               2.2
 707    server SHOULD have mode where TLS not required           2.2
 708    MUST be configurable to refuse all clear-text login
 709      commands or mechanisms                                 2.3
 710    server SHOULD be configurable to refuse clear-text
 711      login commands on entire server and on per-user basis  2.3
 712    client MUST check server identity                        2.4
 713    client MUST use hostname used to open connection         2.4
 714    client MUST NOT use hostname from insecure remote lookup 2.4
 715    client SHOULD support subjectAltName of dNSName type     2.4
 716    client SHOULD ask for confirmation or terminate on fail  2.4
 717    MUST check result of STARTTLS for acceptable privacy     2.5
 718    client MUST NOT issue commands after STARTTLS
 719       until server response and negotiation done        3.1,4,5.1
 720    client MUST discard cached information             3.1,4,5.1,9
 721    client SHOULD re-issue CAPABILITY/CAPA command       3.1,4
 722    IMAP server with STARTTLS MUST implement LOGINDISABLED   3.2
 723    IMAP client MUST NOT issue LOGIN if LOGINDISABLED        3.2
 724    POP server MUST implement POP3 extensions                4
 725    ACAP server MUST re-issue ACAP greeting                  5.1
 726
 727
 728
 729
 730 Newman                      Standards Track                    [Page 13]
 731 \f
 732 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 733
 734
 735    client SHOULD warn when session privacy not active and/or
 736      refuse to proceed without acceptable security level    9
 737    SHOULD be configurable to refuse weak mechanisms or
 738      cipher suites                                          9
 739
 740    The PLAIN mechanism is an optional part of this specification.
 741    However if it is implemented the following rules apply:
 742
 743    Rules                                                 Section
 744    -----                                                 -------
 745    MUST NOT use PLAIN unless strong encryption active
 746      or backwards compatibility dictates otherwise         6,9
 747    MUST use UTF-8 encoding for characters in PLAIN          6
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Newman                      Standards Track                    [Page 14]
 787 \f
 788 RFC 2595           Using TLS with IMAP, POP3 and ACAP          June 1999
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 794
 795    This document and translations of it may be copied and furnished to
 796    others, and derivative works that comment on or otherwise explain it
 797    or assist in its implementation may be prepared, copied, published
 798    and distributed, in whole or in part, without restriction of any
 799    kind, provided that the above copyright notice and this paragraph are
 800    included on all such copies and derivative works.  However, this
 801    document itself may not be modified in any way, such as by removing
 802    the copyright notice or references to the Internet Society or other
 803    Internet organizations, except as needed for the purpose of
 804    developing Internet standards in which case the procedures for
 805    copyrights defined in the Internet Standards process must be
 806    followed, or as required to translate it into languages other than
 807    English.
 808
 809    The limited permissions granted above are perpetual and will not be
 810    revoked by the Internet Society or its successors or assigns.
 811
 812    This document and the information contained herein is provided on an
 813    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 814    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 815    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 816    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 817    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 818
 819 Acknowledgement
 820
 821    Funding for the RFC Editor function is currently provided by the
 822    Internet Society.
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Newman                      Standards Track                    [Page 15]
 843 \f