Network Working Group R. Siemborski
Request for Comments: 4959 Google, Inc.
Category: Standards Track A. Gulbrandsen
Oryx Mail Systems GmbH
September 2007
Network Working Group R. Siemborski
Request for Comments: 4959 Google, Inc.
Category: Standards Track A. Gulbrandsen
Oryx Mail Systems GmbH
September 2007
IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response
用于简单身份验证和安全层（SASL）初始客户端响应的IMAP扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.
迄今为止，Internet消息访问协议（IMAP）使用了简单身份验证和安全层（SASL）配置文件，该配置文件始终要求至少一次完整的身份验证往返，因为它不支持初始客户端响应参数。在会话开始时这种额外的往返是不可取的，尤其是在往返成本很高的情况下。
This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command.
本文档定义了IMAP的扩展，它允许客户端和服务器通过允许IMAP AUTHENTICATE命令的初始客户端响应参数来避免这种往返。
The SASL initial client response extension is present in any IMAP [RFC3501] server implementation which returns "SASL-IR" as one of the supported capabilities in its CAPABILITY response.
SASL初始客户端响应扩展存在于任何IMAP[RFC3501]服务器实现中，该服务器实现将“SASL-IR”作为其功能响应中支持的功能之一返回。
Servers which support this extension will accept an optional initial client response with the AUTHENTICATE command for any SASL [RFC4422] mechanisms which support it.
支持此扩展的服务器将接受可选的初始客户机响应，该响应带有任何支持该扩展的SASL[RFC4422]机制的AUTHENTICATE命令。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
Formal syntax is defined by [RFC4234] as extended by [RFC3501].
形式语法由[RFC4234]定义，并由[RFC3501]扩展。
This extension adds an optional second argument to the AUTHENTICATE command that is defined in Section 6.2.2 of [RFC3501]. If this second argument is present, it represents the contents of the "initial client response" defined in Section 5.1 of [RFC4422].
此扩展将可选的第二个参数添加到[RFC3501]第6.2.2节中定义的AUTHENTICATE命令中。如果存在第二个参数，则表示[RFC4422]第5.1节中定义的“初始客户机响应”的内容。
As with any other client response, this initial client response MUST be encoded as defined in Section 4 of [RFC4648]. It also MUST be transmitted outside of a quoted string or literal. To send a zero-length initial response, the client MUST send a single pad character ("="). This indicates that the response is present, but is a zero-length string.
与任何其他客户端响应一样，此初始客户端响应必须按照[RFC4648]第4节中的定义进行编码。它还必须在带引号的字符串或文字之外传输。要发送零长度的初始响应，客户端必须发送单个填充字符（“=”）。这表示响应存在，但为零长度字符串。
When decoding the BASE64 [RFC4648] data in the initial client response, decoding errors MUST be treated as IMAP [RFC3501] would handle them in any normal SASL client response. In particular, the server should check for any characters not explicitly allowed by the BASE64 alphabet, as well as any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
在初始客户端响应中解码BASE64[RFC4648]数据时，解码错误必须被视为IMAP[RFC3501]将在任何正常SASL客户端响应中处理它们。特别是，服务器应检查BASE64字母表不明确允许的任何字符，以及任何包含填充字符（'='）的BASE64字符序列，而不是字符串末尾（例如，不允许“=AAA”和“AAA=BBB”）。
If the client uses an initial response with a SASL mechanism that does not support an initial response, the server MUST reject the command with a tagged BAD response.
如果客户端使用不支持初始响应的SASL机制的初始响应，则服务器必须拒绝带有标记错误响应的命令。
Note: support and use of the initial client response is optional for both clients and servers. Servers that implement this extension MUST support clients that omit the initial client response, and clients that implement this extension MUST NOT send an initial client response to servers that do not advertise the SASL-IR capability. In such a situation, clients MUST fall back to an IMAP [RFC3501] compatible mode.
注意：对于客户端和服务器，初始客户端响应的支持和使用都是可选的。实现此扩展的服务器必须支持省略初始客户端响应的客户端，并且实现此扩展的客户端不得将初始客户端响应发送到不公布SASL-IR功能的服务器。在这种情况下，客户端必须退回到IMAP[RFC3501]兼容模式。
If either the client or the server do not support the SASL-IR capability, a mechanism which uses an initial client response is negotiated using the challenge/response exchange described in [RFC3501], with an initial zero-length server challenge.
如果客户机或服务器不支持SASL-IR功能，则使用[RFC3501]中所述的质询/响应交换协商使用初始零长度服务器质询的机制。
The following is an example authentication using the PLAIN (see [RFC4616]) SASL mechanism (under a TLS protection layer, see [RFC4346]) and an initial client response:
以下是使用普通（请参见[RFC4616]）SASL机制（在TLS保护层下，请参见[RFC4346]）和初始客户端响应的验证示例：
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
S: C01 OK Completed
C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A01 OK Success (tls protection)
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
S: C01 OK Completed
C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A01 OK Success (tls protection)
Note that even when a server supports this extension, the following negotiation (which does not use the initial response) is still valid and MUST be supported by the server:
请注意，即使服务器支持此扩展，以下协商（不使用初始响应）仍然有效，并且必须由服务器支持：
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
S: C01 OK Completed
C: A01 AUTHENTICATE PLAIN
(note that there is a space following the "+" in the
following line)
S: +
C: dGVzdAB0ZXN0AHRlc3Q=
S: A01 OK Success (tls protection)
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN
S: C01 OK Completed
C: A01 AUTHENTICATE PLAIN
(note that there is a space following the "+" in the
following line)
S: +
C: dGVzdAB0ZXN0AHRlc3Q=
S: A01 OK Success (tls protection)
The following is an example authentication using the SASL EXTERNAL mechanism (defined in [RFC4422]) under a TLS protection layer (see [RFC4346]) and an empty initial client response:
以下是使用TLS保护层（参见[RFC4346]）下的SASL外部机制（在[RFC4422]中定义）和空初始客户端响应进行身份验证的示例：
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
S: C01 OK Completed
C: A01 AUTHENTICATE EXTERNAL =
S: A01 OK Success (tls protection)
... client connects to server and negotiates a TLS
protection layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
S: C01 OK Completed
C: A01 AUTHENTICATE EXTERNAL =
S: A01 OK Success (tls protection)
This is in contrast with the handling of such a situation when an initial response is omitted:
这与忽略初始响应时处理此类情况形成对比：
... client connects to server and negotiates a TLS protection
layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
S: C01 OK Completed
C: A01 AUTHENTICATE EXTERNAL
(note that there is a space following the "+" in the
following line)
S: +
C:
S: A01 OK Success (tls protection)
... client connects to server and negotiates a TLS protection
layer ...
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
S: C01 OK Completed
C: A01 AUTHENTICATE EXTERNAL
(note that there is a space following the "+" in the
following line)
S: +
C:
S: A01 OK Success (tls protection)
The IANA has added SASL-IR to the IMAP4 Capabilities Registry.
IANA已将SASL-IR添加到IMAP4功能注册表中。
The extension defined in this document is subject to many of the Security Considerations defined in [RFC3501] and [RFC4422].
本文档中定义的扩展受[RFC3501]和[RFC4422]中定义的许多安全注意事项的约束。
Server implementations MUST treat the omission of an initial client response from the AUTHENTICATE command as defined by [RFC3501] (as if this extension did not exist).
服务器实现必须按照[RFC3501]的定义，将初始客户机响应从AUTHENTICATE命令中忽略（就好像此扩展不存在一样）。
Although [RFC3501] has no express line length limitations, some implementations choose to enforce them anyway. Such implementations MUST be aware that the addition of the initial response parameter to AUTHENTICATE may increase the maximum line length that IMAP parsers may expect to support. Server implementations MUST be able to receive the largest possible initial client response that their supported mechanisms might receive.
尽管[RFC3501]没有express行长度限制，但有些实现还是选择强制执行这些限制。此类实现必须意识到，添加初始响应参数进行身份验证可能会增加IMAP解析器预期支持的最大行长度。服务器实现必须能够接收其支持的机制可能接收到的最大可能的初始客户端响应。
The following syntax specification uses the Augmented Backus-Naur Form [RFC4234] notation. [RFC3501] defines the non-terminals capability, auth-type, and base64.
以下语法规范使用增广的Backus-Naur形式[RFC4234]表示法。[RFC3501]定义非终端功能、身份验证类型和base64。
capability =/ "SASL-IR"
能力=/“SASL-IR”
authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
*(CRLF base64)
;;redefine AUTHENTICATE from [RFC3501]
authenticate = "AUTHENTICATE" SP auth-type [SP (base64 / "=")]
*(CRLF base64)
;;redefine AUTHENTICATE from [RFC3501]
The authors would like to acknowledge the contributions of Ken Murchison and Mark Crispin, along with the rest of the IMAPEXT Working Group for their assistance in reviewing this document.
作者要感谢Ken Murchison和Mark Crispin以及IMAPEXT工作组其他成员在审查本文件方面的贡献。
Alexey Melnikov and Cyrus Daboo also had some early discussions about this extension.
Alexey Melnikov和Cyrus Daboo也对该扩展进行了一些早期讨论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616]Zeilenga，K.，“简单认证和安全层（SASL）机制”，RFC4616，2006年8月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
Authors' Addresses
作者地址
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043
Robert Siemborski Google，Inc.加利福尼亚州安比塞特公园山景大道1600号，邮编94043
Phone: +1 650 623 6925
EMail: robsiemb@google.com
Phone: +1 650 623 6925
EMail: robsiemb@google.com
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Oryx邮件系统有限公司Schweppermannstr。德国慕尼黑8D-81671
EMail: arnt@oryx.com
EMail: arnt@oryx.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.