Network Working Group C. Newman
Request for Comments: 2595 Innosoft
Category: Standards Track June 1999
Network Working Group C. Newman
Request for Comments: 2595 Innosoft
Category: Standards Track June 1999
Using TLS with IMAP, POP3 and ACAP
将TLS与IMAP、POP3和ACAP一起使用
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for IMAP, POP and ACAP due to common connection eavesdropping and hijacking attacks [AUTH]. Although advanced SASL authentication mechanisms can provide a lightweight version of this service, TLS is complimentary to simple authentication-only SASL mechanisms or deployed clear-text password login commands.
TLS协议（以前称为SSL）提供了一种保护应用程序协议免受篡改和窃听的方法。由于常见的连接窃听和劫持攻击[AUTH]，IMAP、POP和ACAP需要使用这种安全性。尽管高级SASL身份验证机制可以提供此服务的轻量级版本，但TLS是对简单的仅限身份验证的SASL机制或已部署的明文密码登录命令的补充。
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. (Note there is a separate RFC for the STARTTLS command in SMTP [SMTPTLS].)
许多站点在身份验证基础设施（例如，应用于用户密码的单向功能的大型数据库）方面有较高的投资，因此，不与用户身份验证紧密绑定的隐私层可以防止网络窃听攻击，而无需新的身份验证基础设施和/或强制所有用户更改密码。认识到此类站点需要结合TLS加密的简单密码验证，本规范定义了用于缺少简单密码验证命令（如ACAP和SMTP）的协议的普通SASL机制。（注意，SMTP[SMTPTLS]中的STARTTLS命令有一个单独的RFC。）
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
IETF强烈希望消除未加密信道上的明文密码传输。虽然SASL可用于此目的，但TLS提供了具有不同可部署性特征的附加工具。支持两个TLS的服务器
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.
简单的密码和质询/响应SASL机制有可能在不使用未加密的明文密码的情况下与多种客户端进行互操作。
The STARTTLS command rectifies a number of the problems with using a separate port for a "secure" protocol variant. Some of these are mentioned in section 7.
STARTTLS命令纠正了为“安全”协议变体使用单独端口时出现的许多问题。其中一些在第7节中提到。
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].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”、“可能”和“可选”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
Terms related to authentication are defined in "On Internet Authentication" [AUTH].
与身份验证相关的术语在“网上身份验证”[AUTH]中定义。
Formal syntax is defined using ABNF [ABNF].
形式语法是使用ABNF[ABNF]定义的。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The following requirements apply to all implementations of the STARTTLS extension for IMAP, POP3 and ACAP.
以下要求适用于IMAP、POP3和ACAP的STARTTLS扩展的所有实现。
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite is REQUIRED. This is important as it assures that any two compliant implementations can be configured to interoperate.
需要使用CBC SHA[TLS]密码套件实现TLS_DHE_DSS_。这一点很重要，因为它可以确保任何两个兼容的实现都可以配置为互操作。
All other cipher suites are OPTIONAL.
所有其他密码套件都是可选的。
Both clients and servers SHOULD have a privacy operational mode which refuses authentication unless successful activation of an encryption layer (such as that provided by TLS) occurs prior to or at the time of authentication and which will terminate the connection if that encryption layer is deactivated. Implementations are encouraged to have flexability with respect to the minimal encryption strength or cipher suites permitted. A minimalist approach to this recommendation would be an operational mode where the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to permitting authentication.
客户端和服务器都应具有隐私操作模式，该模式拒绝验证，除非在验证之前或验证时成功激活加密层（如TLS提供的加密层），并且如果该加密层被停用，将终止连接。鼓励实现在允许的最小加密强度或密码套件方面具有灵活性。此建议的最低限度方法将是一种操作模式，其中TLS_DHE_DSS_与_3DES_EDE_CBC_SHA密码套件在允许身份验证之前是强制性的。
Clients MAY have an operational mode which uses encryption only when it is advertised by the server, but authentication continues regardless. For backwards compatibility, servers SHOULD have an operational mode where only the authentication mechanisms required by the relevant base protocol specification are needed to successfully authenticate.
客户端可能有一种操作模式，该模式仅在服务器播发加密时使用，但身份验证将继续。为了向后兼容，服务器应该具有一种操作模式，在这种模式下，只有相关基本协议规范所要求的身份验证机制才能成功地进行身份验证。
Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active. Servers which allow unencrypted clear-text logins SHOULD be configurable to refuse clear-text logins both for the entire server, and on a per-user basis.
实现STARTTLS的客户端和服务器必须可配置为拒绝所有明文登录命令或机制（包括标准跟踪和非标准机制），除非有足够强度的加密层处于活动状态。允许未加密明文登录的服务器应可配置为拒绝整个服务器的明文登录，并基于每个用户。
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:
在TLS协商期间，客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解，以防止中间人攻击。根据以下规则执行匹配：
- 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 lookup). CNAME canonicalization is not done.
- 客户端必须使用用于打开连接的服务器主机名作为值，以与服务器证书中表示的服务器名称进行比较。客户端不得使用从不安全的远程源（例如，不安全的DNS查找）派生的任何形式的服务器主机名。CNAME规范化未完成。
- If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
- 如果证书中存在dNSName类型的subjectAltName扩展名，则应将其用作服务器标识的源。
- Matching is case-insensitive.
- 匹配不区分大小写。
- 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 example.com.
- “*”通配符可以用作证书中最左边的名称组件。例如，*.example.com将与a.example.com、foo.example.com等匹配，但与example.com不匹配。
- 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.
- 如果证书包含多个名称（例如，多个dNSName字段），则认为与其中任何一个字段匹配是可以接受的。
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.
如果匹配失败，客户端应该请求明确的用户确认，或者终止连接并指出服务器的身份可疑。
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-dependent, and is beyond the scope of this document.
客户机和服务器都必须检查STARTTLS命令和后续TLS协商的结果，以查看是否实现了可接受的身份验证或隐私。忽略此步骤将使使用TLS进行安全保护完全无效。关于是否实现了可接受的身份验证或隐私的决定是在本地做出的，取决于实现，并且超出了本文档的范围。
When the TLS extension is present in IMAP, "STARTTLS" is listed as a capability in response to the CAPABILITY command. This extension adds a single command, "STARTTLS" to the IMAP protocol which is used to begin a TLS negotiation.
当IMAP中存在TLS扩展时，“STARTTLS”将作为一项功能列出，以响应capability命令。此扩展将单个命令“STARTTLS”添加到IMAP协议中，该协议用于开始TLS协商。
Arguments: none
论点：无
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid
结果：确定-开始TLS协商错误-命令未知或参数无效
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.
TLS协商在服务器标记的OK响应结束时的CRLF之后立即开始。一旦客户机发出STARTTLS命令，在看到服务器响应和TLS协商完成之前，不得发出进一步的命令。
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.
STARTTLS命令仅在未经身份验证的状态下有效。即使在TLS协商期间提供了客户端凭据，服务器仍保持未经身份验证的状态。成功交换TLS客户端凭据后，可以使用SASL[SASL]外部机制进行身份验证，但不需要支持STARTTLS命令的服务器来支持外部机制。
Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD 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.
启动TLS后，客户端必须丢弃有关服务器功能的缓存信息，并应重新发出CAPABILITY命令。这对于防止中间人攻击是必要的，中间人攻击会在STARTTLS之前改变功能列表。服务器可能会在STARTTLS之后公布不同的功能。
The formal syntax for IMAP is amended as follows:
IMAP的正式语法修改如下：
command_any =/ "STARTTLS"
命令\u 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
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
The current IMAP protocol specification (RFC 2060) requires the implementation of the LOGIN command which uses clear-text passwords. Many sites may choose to disable this command unless encryption is active for security reasons. An IMAP server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. Such a server will respond with a tagged "NO" response to any attempt to use the LOGIN command.
当前的IMAP协议规范（RFC 2060）要求实现使用明文密码的登录命令。许多站点可能会选择禁用此命令，除非出于安全原因加密处于活动状态。IMAP服务器可以通过在功能响应中包含LOGINDISABLED功能来通告已禁用登录命令。这样的服务器将对任何使用LOGIN命令的尝试做出标记为“NO”的响应。
An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections.
实现STARTTLS的IMAP服务器必须在未加密连接上实现对LOGINDISABLED功能的支持。
An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present.
如果存在此功能，则符合此规范的IMAP客户端不得发出登录命令。
This capability is useful to prevent clients compliant with this specification from sending an unencrypted password in an environment subject to passive attacks. It has no impact on an environment subject to active attacks as a man-in-the-middle attacker can remove this capability. Therefore this does not relieve clients of the need to follow the privacy mode recommendation in section 2.2.
此功能有助于防止符合此规范的客户端在受到被动攻击的环境中发送未加密的密码。它对受到主动攻击的环境没有影响，因为中间人攻击者可以删除此功能。因此，这并不免除客户遵循第2.2节中隐私模式建议的需要。
Servers advertising this capability will fail to interoperate with many existing compliant IMAP clients and will be unable to prevent those clients from disclosing the user's password.
宣传此功能的服务器将无法与许多现有兼容IMAP客户端进行互操作，并且无法阻止这些客户端泄露用户密码。
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 and permitted in the current state.
POP3 STARTTLS扩展将STLS命令添加到POP3服务器。如果实现了这一点，还必须实现POP3扩展机制[POP3EXT]，以避免需要客户端探测多个命令。功能名称“STLS”表示当前状态下存在并允许此命令。
STLS
STL
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.
讨论：在服务器的+OK响应结束时，在CRLF之后立即开始TLS协商。如果安全层已处于活动状态，则可能会导致-ERR响应。一旦客户机发出STL命令，在看到服务器响应和TLS协商完成之前，不得发出进一步的命令。
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.
STLS命令仅允许在授权状态下使用，即使在TLS协商期间提供了客户端凭据，服务器仍保持在授权状态。一旦成功交换TLS客户端凭据，可以使用带有外部机制[SASL]的AUTH命令[POP-AUTH]进行身份验证，但支持STLS命令的服务器不需要支持外部机制。
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.
TLS启动后，客户端必须丢弃有关服务器功能的缓存信息，并应重新发出CAPA命令。这对于防止中间人攻击是必要的，中间人攻击会改变STL之前的功能列表。服务器可能会在STL之后公布不同的功能。
Possible Responses: +OK -ERR
可能的响应：+OK-错误
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
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
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.
当ACAP中存在TLS扩展时，“STARTTLS”在ACAP问候语中列为一项功能。此时未定义此功能的参数。此扩展将一个命令“STARTTLS”添加到用于开始TLS协商的ACAP协议中。
Arguments: none
论点：无
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid
结果：确定-开始TLS协商错误-命令未知或参数无效
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.
TLS协商在服务器标记的OK响应结束时的CRLF之后立即开始。一旦客户机发出STARTTLS命令，在看到服务器响应和TLS协商完成之前，不得发出进一步的命令。
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.
STARTTLS命令仅在未经身份验证的状态下有效。即使在TLS协商期间提供了客户端凭据，服务器仍保持未经身份验证的状态。成功交换TLS客户端凭据后，可以使用SASL[SASL]外部机制进行身份验证，但不需要支持STARTTLS命令的服务器来支持外部机制。
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.
TLS层建立后，服务器必须重新发出未标记的ACAP问候语。这对于防止中间人攻击是必要的，中间人攻击会在STARTTLS之前改变功能列表。客户端必须丢弃缓存的功能信息，并用新ACAP问候语中的信息替换它。服务器可能会在STARTTLS之后公布不同的功能。
The formal syntax for ACAP is amended as follows:
ACAP的正式语法修改如下：
command_any =/ "STARTTLS"
命令\u 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")
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")
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.
这定义了用于ACAP和其他协议的“普通”SASL机制，无需明文登录命令。除非强加密层（如TLS提供的）处于活动状态或向后兼容另有规定，否则不得公布或使用普通SASL机制。
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.
该机制由从客户端到服务器的单个消息组成。客户端发送授权标识（登录身份），后跟US-ASCII NUL字符，后跟身份验证标识（将使用其密码的标识），后跟US-ASCII NUL字符，后跟明文密码。客户端可以将授权标识保留为空，以指示它与身份验证标识相同。
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].
服务器还可以使用密码初始化任何新的身份验证数据库，例如适合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.
只要以UTF-8[UTF-8]表示，就允许使用非美国ASCII字符。不鼓励使用不可见字符或用户无法在某些键盘上输入的字符。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
使用增广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
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
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:
下面是一个示例，说明了如何使用此选项初始化ACAP的CRAM-MD5身份验证数据库：
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
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.
注意：在本例中，<NUL>表示单个ASCII NUL八位字节。
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.
注册了单独的“imaps”和“POP3”端口，以便与SSL一起使用。不鼓励使用这些端口，而支持STARTTLS或STLS命令。
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.
- 单独的端口导致单独的URL方案，该方案以不适当的方式侵入用户界面。例如，许多网页使用“如果您的浏览器支持SSL，请单击此处”之类的语言。这是浏览器通常比用户更能做出的决定。
- 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
- 单独的端口意味着“安全”或“不安全”的模式。这可能在许多方面产生误导。首先，“安全”端口的安全性实际上可能不可接受，因为可能正在使用禁用导出的密码套件。这会误导用户产生错误的安全感。第二，普通端口实际上可能通过使用包含安全层的SASL机制来保护。因此，独立端口的区别使得安全策略这个复杂的主题更加令人困惑。这种混乱的一个常见结果是，防火墙管理员经常被误导进入防火墙
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.
允许“安全”端口并阻塞标准端口。这可能是一个糟糕的选择，因为SSL通常使用40位密钥加密层，而纯文本密码身份验证不如强大的SASL机制（如带有Kerberos 5的GSSAPI）安全。
- 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.
- 为SSL使用单独的端口导致客户端只实现两个安全策略：使用SSL或不使用SSL。理想的安全策略“在可用时使用TLS”对于单独的端口模型来说会很麻烦，但是对于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.
- 端口号是有限的资源。虽然它们还没有供不应求，但开创一个可能使其消费速度加倍（或更糟）的先例是不明智的。
This constitutes registration of the "STARTTLS" and "LOGINDISABLED" IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
这构成了RFC 2060[IMAP]第7.2.1节要求的“STARTTLS”和“LOGINDISABLED”IMAP功能的注册。
The registration for the POP3 "STLS" capability follows:
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
CAPA标记：STL参数：未添加命令：受影响的STL标准命令：可能会作为副作用启用用户/过程。成功完成后应重新发出CAPA命令。宣布状态/有效状态：仅授权状态。规格参考：本备忘录
The registration for the ACAP "STARTTLS" capability follows:
ACAP“STARTTLS”功能的注册如下：
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
能力名称：STARTTLS能力关键字：STARTTLS能力参数：无已发布规范：此备忘录人员和电子邮件地址了解更多信息：请参阅下面的作者地址部分
The registration for the PLAIN SASL mechanism follows:
普通SASL机制的注册如下：
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
SASL机制名称：普通安全注意事项：参见本备忘录第9节发布规范：本备忘录联系人和电子邮件地址以获取更多信息：参见下面的作者地址部分预期用途：通用作者/变更控制者：参见下面的作者地址部分
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].
TLS仅为通过网络连接发送的数据提供保护。通过IMAP或POP3传输的邮件仍可供服务器管理员使用，并且在通过SMTP或NNTP传输时通常会被窃听、篡改和伪造。TLS不能替代使用MIME安全多部分[MIME-SEC]的端到端消息安全机制。
A man-in-the-middle attacker can remove STARTTLS from the capability list or generate a failure response to the STARTTLS command. In order to detect such an attack, clients SHOULD warn the user when session privacy is not active and/or be configurable to refuse to proceed without an acceptable level of security.
中间人攻击者可以从功能列表中删除STARTTLS，或对STARTTLS命令生成失败响应。为了检测此类攻击，当会话隐私未激活和/或可配置为在没有可接受的安全级别的情况下拒绝继续时，客户端应向用户发出警告。
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 SHOULD 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 MUST discard cached information about server capabilities advertised prior to the start of the TLS handshake.
TLS握手之前的任何协议交互都是在clear中执行的，中间人攻击者可以对其进行修改。因此，客户机必须在TLS握手开始之前丢弃有关公布的服务器功能的缓存信息。
Clients are encouraged to clearly indicate when the level of encryption active is known to be vulnerable to attack using modern hardware (such as encryption keys with 56 bits of entropy or less).
鼓励客户明确指出，当使用现代硬件（如熵小于等于56位的加密密钥）时，活动加密级别易受攻击。
The LOGINDISABLED IMAP capability (discussed in section 3.2) only reduces the potential for passive attacks, it provides no protection against active attacks. The responsibility remains with the client to avoid sending a password over a vulnerable channel.
LOGINDISABLED IMAP功能（在第3.2节中讨论）仅降低被动攻击的可能性，不提供主动攻击的保护。客户端仍有责任避免通过易受攻击的通道发送密码。
The PLAIN mechanism relies on the TLS encryption layer for security. When used without TLS, it is vulnerable to a common network eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used unless a suitable TLS encryption layer is active or backwards compatibility dictates otherwise.
普通机制依赖于TLS加密层来实现安全性。在没有TLS的情况下使用时，它容易受到常见的网络窃听攻击。因此，除非适当的TLS加密层处于活动状态或向后兼容性另有规定，否则不得宣传或使用平原。
When the PLAIN mechanism 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. While many other authentication mechanisms have similar weaknesses, stronger SASL mechanisms such as Kerberos address this issue. Clients are encouraged to have an operational mode where all mechanisms which are likely to reveal the user's password to the server are disabled.
使用普通机制时，无论TLS或其他网络隐私机制提供何种加密，服务器都可以使用相同的密码模拟用户访问所有服务。虽然许多其他身份验证机制也有类似的弱点，但更强大的SASL机制（如Kerberos）可以解决这个问题。鼓励客户机采用一种操作模式，在这种模式下，所有可能向服务器泄露用户密码的机制都被禁用。
The security considerations for TLS apply to STARTTLS and the security considerations for SASL apply to the PLAIN mechanism. Additional security requirements are discussed in section 2.
TLS的安全注意事项适用于STARTTLS，SASL的安全注意事项适用于普通机制。第2节讨论了其他安全要求。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[AUTH]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[CRAM-MD5]Klensin，J.，Catoe，R.和P.Krumviede，“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 20601996年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[MIME-SEC]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[POP3 EXT]Gellens，R.，Newman，C.和L.Lundblade，“POP3扩展机制”，RFC 2449，1998年11月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]迈尔斯，J.，“POP3认证命令”，RFC 17341994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[SMTPTLS]Hoffman，P.，“TLS上安全SMTP的SMTP服务扩展”，RFC2487，1999年1月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Chris Newman Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
EMail: chris.newman@innosoft.com
EMail: chris.newman@innosoft.com
A. Appendix -- Compliance Checklist
A.附录——合规性检查表
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 encryption required 2.2
server SHOULD have mode where TLS not required 2.2
MUST be configurable to refuse all clear-text login
commands or mechanisms 2.3
server SHOULD be configurable to refuse clear-text
login commands on entire server and on per-user basis 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 MUST discard cached information 3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
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
Rules Section
----- -------
Mandatory-to-implement Cipher Suite 2.1
SHOULD have mode where encryption required 2.2
server SHOULD have mode where TLS not required 2.2
MUST be configurable to refuse all clear-text login
commands or mechanisms 2.3
server SHOULD be configurable to refuse clear-text
login commands on entire server and on per-user basis 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 MUST discard cached information 3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
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 and/or refuse to proceed without acceptable security level 9 SHOULD be configurable to refuse weak mechanisms or cipher suites 9
当会话隐私未激活和/或拒绝在没有可接受的安全级别9的情况下继续时，客户端应发出警告。应配置为拒绝弱机制或密码套件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 strong encryption active
or backwards compatibility dictates otherwise 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
Rules Section
----- -------
MUST NOT use PLAIN unless strong encryption active
or backwards compatibility dictates otherwise 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。