翻译披露：本页为对 IETF RFC 2595《Using TLS with IMAP, POP3 and ACAP》 的中文翻译，原文著作权归 IETF/原作者所有，内容以人类原始 RFC 为准。本译本由 ztpop.net 整理，仅供学习参考；RFC 受 BCP 78 与 IETF 信托法律条款约束，译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc2595。

RFC 2595：在 IMAP、POP3 与 ACAP 中使用 TLS

IETF · RFC 2595 · 标准跟踪（Standards Track） · C. Newman（Innosoft） · 1999 年 6 月

本备忘录的状态

本文档为互联网社区规定了一项互联网标准跟踪（standards track）协议，并征求改进意见与建议。有关本协议的标准化状态与状况，请参阅《互联网官方协议标准》（STD 1）的当前版本。本备忘录的分发不受限制。

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. 动机

TLS 协议（旧称 SSL）提供了一种保护应用协议免遭篡改与窃听的方式。由于连接窃听与劫持攻击十分常见 [AUTH]，为 IMAP、POP 与 ACAP 提供使用此类安全机制的选项是可取的。虽然高级的 SASL 认证机制可以提供该服务的轻量版本，但 TLS 与"仅做认证"的简单 SASL 机制或已部署的明文口令登录命令是互补关系。

许多站点在认证基础设施上投入很高（例如一个对用户口令施加单向函数后形成的大型数据库），因此一个不与用户认证紧耦合的隐私层，能够在不需要新建认证基础设施、也不强迫所有用户更改口令的前提下，抵御网络窃听攻击。考虑到此类站点会希望把简单口令认证与 TLS 加密结合使用，本规范为缺少简单口令认证命令的协议（如 ACAP 与 SMTP）定义了 PLAIN SASL 机制。（注意，SMTP 中的 STARTTLS 命令另有独立的 RFC [SMTPTLS]。）

IETF 内部有强烈意愿要消除在未加密信道上传输明文口令的做法。虽然 SASL 可用于此目的，但 TLS 提供了另一种具有不同可部署性特征的工具。一台同时支持"TLS 加简单口令"与"挑战/响应式 SASL 机制"的服务器，很可能无需诉诸未加密的明文口令即可与种类繁多的客户端互操作。

STARTTLS 命令纠正了"为'安全'协议变体使用单独端口"所带来的若干问题，其中一些问题在第 7 节中论及。

1.1 本文档使用的约定

本文档中的关键词 "REQUIRED"（需要）、"MUST"（必须）、"MUST NOT"（不得）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"MAY"（可以）与 "OPTIONAL"（可选），应按 [KEYWORDS] 中的描述来解释。

与认证相关的术语在《On Internet Authentication》[AUTH] 中定义。形式化语法使用 ABNF [ABNF] 定义。在示例中，"C:" 与 "S:" 分别表示由客户端与服务器发送的行。

2. 基本互操作性与安全要求

以下要求适用于 IMAP、POP3 与 ACAP 的 STARTTLS 扩展的所有实现。

2.1 密码套件要求

需要实现 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] 密码套件。这一点很重要，因为它确保任意两个合规实现都能被配置为可互操作。所有其他密码套件均为可选。

2.2 隐私运行模式的安全要求

客户端与服务器都应当具备一种"隐私运行模式"：除非在认证之前或认证之时成功启用了加密层（例如由 TLS 提供的加密层），否则拒绝认证；并且一旦该加密层被停用即终止连接。鼓励各实现在所允许的最低加密强度或密码套件方面具有灵活性。对该建议的一种最简做法是：设置一种运行模式，在允许认证之前强制要求使用 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 密码套件。

客户端可以具备一种运行模式：仅当服务器公告加密能力时才使用加密，但无论如何都继续进行认证。为向后兼容，服务器应当具备一种运行模式：只需相关基础协议规范所要求的认证机制即可成功完成认证。

2.3 明文口令要求

实现 STARTTLS 的客户端与服务器必须可被配置为：除非已激活足够强度的加密层，否则拒绝所有明文登录命令或机制（包括标准跟踪机制与非标准机制）。允许未加密明文登录的服务器应当可被配置为拒绝明文登录，且该配置既能针对整台服务器生效，也能按用户逐一生效。

2.4 服务器身份检查

在 TLS 协商过程中，客户端必须将其所理解的服务器主机名与服务器在 Certificate 消息中呈现的身份进行核对，以防范中间人攻击。匹配按以下规则执行：

如果匹配失败，客户端应当要么请求用户明确确认，要么终止连接并指出服务器身份可疑。

2.5 TLS 安全策略检查

客户端与服务器都必须检查 STARTTLS 命令及其后续 TLS 协商的结果，以判断是否达成了可接受的认证或隐私保护。忽略这一步会使"使用 TLS 来保障安全"完全失效。关于是否达成了可接受的认证或隐私保护，该判断在本地作出，取决于具体实现，超出本文档范围。

3. IMAP 的 STARTTLS 扩展

当 IMAP 中存在 TLS 扩展时，"STARTTLS" 会作为一项能力在 CAPABILITY 命令的响应中列出。本扩展向 IMAP 协议添加了单条命令 "STARTTLS"，用于开始一次 TLS 协商。

3.1 STARTTLS 命令

参数：无。响应：本命令无特定响应。结果：OK——开始 TLS 协商；BAD——命令未知或参数无效。

TLS 协商在服务器带标签 OK 响应末尾的 CRLF 之后立即开始。客户端一旦发出 STARTTLS 命令，在看到服务器响应且 TLS 协商完成之前不得发出更多命令。

STARTTLS 命令仅在未认证状态下有效。即使在 TLS 协商过程中提供了客户端凭据，服务器仍保持在未认证状态。一旦 TLS 客户端凭据交换成功，可以使用 SASL [SASL] 的 EXTERNAL 机制进行认证；但支持 STARTTLS 命令的服务器并不要求必须支持 EXTERNAL 机制。

TLS 启动之后，客户端必须丢弃已缓存的服务器能力信息，并应当重新发出 CAPABILITY 命令。这是防范"在 STARTTLS 之前篡改能力列表"的中间人攻击所必需的。服务器在 STARTTLS 之后可以公告不同的能力。

IMAP 的形式化语法作如下修订：

command_any   =/  "STARTTLS"

示例：

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 IMAP 的 LOGINDISABLED 能力

当时的 IMAP 协议规范（RFC 2060）要求实现使用明文口令的 LOGIN 命令。出于安全原因，许多站点可能选择在未启用加密时禁用该命令。IMAP 服务器可以通过在能力响应中包含 LOGINDISABLED 能力，来公告 LOGIN 命令已被禁用。此类服务器对任何使用 LOGIN 命令的尝试都将返回带标签的 "NO" 响应。

实现 STARTTLS 的 IMAP 服务器必须在未加密连接上实现对 LOGINDISABLED 能力的支持。

符合本规范的 IMAP 客户端，在该能力存在时不得发出 LOGIN 命令。

该能力有助于在存在被动攻击的环境中，阻止符合本规范的客户端发送未加密的口令。但它对存在主动攻击的环境毫无作用，因为中间人攻击者可以移除该能力。因此，它并不免除客户端遵循第 2.2 节隐私模式建议的必要。

公告该能力的服务器将无法与许多既有的合规 IMAP 客户端互操作，也无法阻止那些客户端泄露用户口令。

4. POP3 的 STARTTLS 扩展

POP3 的 STARTTLS 扩展向 POP3 服务器添加 STLS 命令。如果实现了该命令，则必须同时实现 POP3 扩展机制 [POP3EXT]，以免客户端需要对多条命令逐一探测。能力名称 "STLS" 表示该命令存在且在当前状态下被允许。

字段内容
命令STLS
参数无
限制仅在 AUTHORIZATION 状态下被允许
可能的响应+OK、-ERR

讨论：TLS 协商在服务器 +OK 响应末尾的 CRLF 之后立即开始。如果安全层已经激活，可以返回 -ERR 响应。客户端一旦发出 STLS 命令，在看到服务器响应且 TLS 协商完成之前不得发出更多命令。

STLS 命令仅在 AUTHORIZATION 状态下被允许；即使在 TLS 协商过程中提供了客户端凭据，服务器仍保持在 AUTHORIZATION 状态。一旦 TLS 客户端凭据交换成功，可以使用带 EXTERNAL 机制 [SASL] 的 AUTH 命令 [POP-AUTH] 进行认证；但支持 STLS 命令的服务器并不要求必须支持 EXTERNAL 机制。

TLS 启动之后，客户端必须丢弃已缓存的服务器能力信息，并应当重新发出 CAPA 命令。这是防范"在 STLS 之前篡改能力列表"的中间人攻击所必需的。服务器在 STLS 之后可以公告不同的能力。

示例：

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

当 ACAP 中存在 TLS 扩展时，"STARTTLS" 会作为一项能力在 ACAP 问候语中列出。当时未为该能力定义任何参数。本扩展向 ACAP 协议添加了单条命令 "STARTTLS"，用于开始一次 TLS 协商。

5.1 STARTTLS 命令

参数：无。响应：本命令无特定响应。结果：OK——开始 TLS 协商；BAD——命令未知或参数无效。

TLS 协商在服务器带标签 OK 响应末尾的 CRLF 之后立即开始。客户端一旦发出 STARTTLS 命令，在看到服务器响应且 TLS 协商完成之前不得发出更多命令。

STARTTLS 命令仅在未认证状态下有效。即使在 TLS 协商过程中提供了客户端凭据，服务器仍保持在未认证状态。一旦 TLS 客户端凭据交换成功，可以使用 SASL [SASL] 的 EXTERNAL 机制进行认证；但支持 STARTTLS 命令的服务器并不要求必须支持 EXTERNAL 机制。

TLS 层建立之后，服务器必须重新发出一条不带标签的 ACAP 问候语。这是防范"在 STARTTLS 之前篡改能力列表"的中间人攻击所必需的。客户端必须丢弃已缓存的能力信息，并以新 ACAP 问候语中的信息取而代之。服务器在 STARTTLS 之后可以公告不同的能力。

ACAP 的形式化语法作如下修订：

command_any   =/  "STARTTLS"

示例：

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

明文口令简单，几乎能与所有现有操作系统的认证数据库互操作，并且有助于平滑过渡到更安全的、基于口令的认证机制。其缺点是：在未加密的网络连接上使用它是不可接受的。

本节定义 "PLAIN" SASL 机制，供 ACAP 以及其他没有明文登录命令的协议使用。除非已激活强加密层（例如 TLS 所提供的加密层），或出于向后兼容的需要，否则不得公告或使用 PLAIN SASL 机制。

该机制由客户端发往服务器的单条消息构成。客户端依次发送：授权身份（authorization identity，即要以之登录的身份）、一个 US-ASCII NUL 字符、认证身份（authentication identity，即将使用其口令的身份）、一个 US-ASCII NUL 字符，以及明文口令。客户端可以将授权身份留空，表示它与认证身份相同。

服务器将依据系统认证数据库核验认证身份与口令，并核验该认证凭据是否允许客户端以该授权身份登录。若两步均成功，则用户登录成功。

服务器还可以利用该口令来初始化任何新的认证数据库，例如适用于 CRAM-MD5 [CRAM-MD5] 的数据库。

只要以 UTF-8 [UTF-8] 表示，就允许使用非 US-ASCII 字符。不鼓励使用不可见字符，或用户在某些键盘上可能无法输入的字符。

客户端消息的形式化文法（使用扩充 BNF [ABNF]）如下：

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
UTF8-4          = %xF0-F7 3UTF8-1
UTF8-5          = %xF8-FB 4UTF8-1
UTF8-6          = %xFC-FD 5UTF8-1

以下示例展示了如何借此为 ACAP 初始化一个 CRAM-MD5 认证数据库：

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

注意：本示例中，<NUL> 表示单个 ASCII NUL 八位组。

7. imaps 与 pop3s 端口

曾为配合 SSL 使用而注册了单独的 "imaps" 与 "pop3s" 端口。不鼓励使用这些端口，而应优先采用 STARTTLS 或 STLS 命令。

为协议的"安全"变体设立单独端口已被观察到存在若干问题，此处尝试列举其中一部分：

8. IANA 考量

本文构成对 IMAP 能力 "STARTTLS" 与 "LOGINDISABLED" 的注册，如 RFC 2060 [IMAP] 第 7.2.1 节所要求。

POP3 "STLS" 能力的注册如下：

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

ACAP "STARTTLS" 能力的注册如下：

Capability name:            STARTTLS
Capability keyword:         STARTTLS
Capability arguments:       none
Published Specification(s): this memo

PLAIN SASL 机制的注册如下：

SASL mechanism name:        PLAIN
Security Considerations:    See section 9 of this memo
Published specification:    this memo
Intended usage:             COMMON

9. 安全考量

TLS 只为在网络连接上发送的数据提供保护。经由 IMAP 或 POP3 传输的邮件对服务器管理员而言仍然可见，并且在通过 SMTP 或 NNTP 传输时通常仍会遭受窃听、篡改与伪造。TLS 不能替代使用 MIME 安全多部分 [MIME-SEC] 的端到端邮件安全机制。

中间人攻击者可以从能力列表中移除 STARTTLS，或对 STARTTLS 命令生成一个失败响应。为检测此类攻击，客户端应当在会话隐私未激活时向用户告警，和/或可被配置为在未达到可接受安全级别时拒绝继续。

中间人攻击者总能促成降级协商至可用的最弱认证机制或密码套件。因此，各实现应当可被配置为拒绝弱机制或弱密码套件。

TLS 握手之前的任何协议交互都是明文进行的，可被中间人攻击者修改。因此，客户端必须丢弃在 TLS 握手开始之前所公告的、已缓存的服务器能力信息。

鼓励客户端在已知当前加密强度以现代硬件即可攻破时（例如熵值不超过 56 位的加密密钥），明确加以提示。

IMAP 的 LOGINDISABLED 能力（见第 3.2 节讨论）只能降低遭受被动攻击的可能性，对主动攻击不提供任何保护。避免在脆弱信道上发送口令的责任仍在客户端一方。

PLAIN 机制的安全性依赖于 TLS 加密层。在不使用 TLS 的情况下，它易遭受常见的网络窃听攻击。因此，除非已激活合适的 TLS 加密层，或出于向后兼容的需要，否则不得公告或使用 PLAIN。

使用 PLAIN 机制时，服务器将获得"以该用户身份冒充其访问所有使用相同口令的服务"的能力——无论 TLS 或其他网络隐私机制提供了何种加密，都无法避免这一点。虽然许多其他认证机制也有类似弱点，但诸如 Kerberos 这样更强的 SASL 机制解决了该问题。鼓励客户端提供一种运行模式，在该模式下禁用所有可能向服务器泄露用户口令的机制。

作者地址

Chris Newman，Innosoft International, Inc.，1050 Lakes Drive, West Covina, CA 91790, USA。邮箱：chris.newman@innosoft.com

完整版权声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

本文档及其译本可以被复制并提供给他人；对其进行注释或以其他方式解释、或协助其实现的衍生作品，也可以被全部或部分地准备、复制、发布与分发，不受任何形式的限制，前提是在所有此类副本与衍生作品上都包含上述版权声明与本段文字。但本文档本身不得以任何方式修改；除非是出于制定互联网标准的需要（此时必须遵循互联网标准流程中定义的版权程序），或者是将其翻译为英语以外的语言所必需。

上述授予的有限许可是永久性的，不会被互联网协会或其继任者或受让人撤销。

本文档及其中所含信息以"按现状"（AS IS）的方式提供，互联网协会与互联网工程任务组不作任何明示或默示的担保。

来源（Source）

本页译自 IETF 人类原始文本，英文原文与权威版本：

如中文表述与英文原文存在歧义，一律以 ietf.org / rfc-editor.org 英文原文为准。