Network Working Group J. Vinocur
Request for Comments: 4643 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Network Working Group J. Vinocur
Request for Comments: 4643 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Network News Transfer Protocol (NNTP) Extension for Authentication
用于身份验证的网络新闻传输协议（NNTP）扩展
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.
本文档定义了网络新闻传输协议（NNTP）的扩展，该扩展允许客户端向服务器指示身份验证机制，执行身份验证协议交换，并可选地在NNTP会话的剩余时间内协商安全层以进行后续协议交互。
This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP.
本文档更新并规范RFC 2980中指定的AUTHINFO用户/通行证身份验证方法，并反对AUTHINFO简单身份验证方法和AUTHINFO通用身份验证方法。此外，本文档还为NNTP定义了简单身份验证和安全层（SASL）的概要文件。
Table of Contents
目录
1. Introduction ............................................. 3
1.1. Conventions Used in This Document ................... 3
2. The AUTHINFO Extension ................................... 4
2.1. Advertising the AUTHINFO Extension .................. 4
2.2. Authenticating with the AUTHINFO Extension .......... 5
2.3. AUTHINFO USER/PASS Command .......................... 6
2.3.1. Usage ........................................ 7
2.3.2. Description .................................. 7
2.3.3. Examples ..................................... 9
2.4. AUTHINFO SASL Command ............................... 9
2.4.1. Usage ........................................ 10
2.4.2. Description .................................. 11
2.4.3. Examples ..................................... 14
3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16
3.1. Commands ............................................ 16
3.2. Command Continuation ................................ 17
3.3. Responses ........................................... 17
3.4. Capability Entries .................................. 17
3.5. General Non-terminals ............................... 18
4. Summary of Response Codes ................................ 18
5. Authentication Tracking/Logging .......................... 18
6. Security Considerations .................................. 19
7. IANA Considerations ...................................... 20
7.1. IANA Considerations for SASL/GSSAPI Services ........ 20
7.2. IANA Considerations for NNTP Extensions ............. 20
8. Acknowledgements ......................................... 21
9. References ............................................... 22
9.1. Normative References ................................ 22
9.2. Informative References .............................. 22
1. Introduction ............................................. 3
1.1. Conventions Used in This Document ................... 3
2. The AUTHINFO Extension ................................... 4
2.1. Advertising the AUTHINFO Extension .................. 4
2.2. Authenticating with the AUTHINFO Extension .......... 5
2.3. AUTHINFO USER/PASS Command .......................... 6
2.3.1. Usage ........................................ 7
2.3.2. Description .................................. 7
2.3.3. Examples ..................................... 9
2.4. AUTHINFO SASL Command ............................... 9
2.4.1. Usage ........................................ 10
2.4.2. Description .................................. 11
2.4.3. Examples ..................................... 14
3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16
3.1. Commands ............................................ 16
3.2. Command Continuation ................................ 17
3.3. Responses ........................................... 17
3.4. Capability Entries .................................. 17
3.5. General Non-terminals ............................... 18
4. Summary of Response Codes ................................ 18
5. Authentication Tracking/Logging .......................... 18
6. Security Considerations .................................. 19
7. IANA Considerations ...................................... 20
7.1. IANA Considerations for SASL/GSSAPI Services ........ 20
7.2. IANA Considerations for NNTP Extensions ............. 20
8. Acknowledgements ......................................... 21
9. References ............................................... 22
9.1. Normative References ................................ 22
9.2. Informative References .............................. 22
Although NNTP [NNTP] has traditionally been used to provide public access to newsgroups, authentication is often useful for several purposes; for example, to control resource consumption, to allow abusers of the POST command to be identified, and to restrict access to "local" newsgroups.
尽管NNTP[NNTP]传统上用于提供对新闻组的公共访问，但身份验证通常有多种用途；例如，控制资源消耗，允许识别滥用POST命令的人，并限制对“本地”新闻组的访问。
The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in [NNTP-COMMON], provide a very weak authentication mechanism in widespread use by the installed base. Due to their ubiquity, they are formalized in this specification but (because of their insecurity) only for use in combination with appropriate security layers.
[NNTP-COMMON]中记录的特设AUTHINFO USER和AUTHINFO PASS命令提供了一种非常弱的身份验证机制，已安装用户广泛使用。由于它们的普遍性，在本规范中对它们进行了形式化描述，但（由于它们的不安全性）仅用于与适当的安全层结合使用。
The ad hoc AUTHINFO GENERIC command, also documented in [NNTP-COMMON] but much less ubiquitous, provided an NNTP-specific equivalent of the generic SASL [SASL] facility. This document deprecates AUTHINFO GENERIC in favor of an AUTHINFO SASL replacement so that NNTP can benefit from authentication mechanisms developed for other SASL-enabled application protocols, including Simple Mail Transfer Protocol (SMTP) [SMTP-AUTH], Post Office Protocol (POP) [POP-AUTH], Internet Message Access Protocol (IMAP) [IMAP], Lightweight Directory Access Protocol (LDAP) [LDAP-AUTH], and Blocks Extensive Exchange Protocol (BEEP) [BEEP].
特设AUTHINFO GENERIC命令也记录在[NNTP-COMMON]中，但不太普遍，它提供了一个特定于NNTP的通用SASL[SASL]功能。本文档不支持AUTHINFO GENERIC，而支持使用AUTHINFO SASL替换，因此NNTP可以从为其他启用SASL的应用程序协议开发的身份验证机制中获益，包括简单邮件传输协议（SMTP）[SMTP-AUH]、邮局协议（POP）[POP-AUH]、Internet邮件访问协议（IMAP）[IMAP]，轻量级目录访问协议（LDAP）[LDAP-AUH]和块扩展交换协议（BEEP）[BEEP]。
This specification is to be read in conjunction with the NNTP base specification [NNTP]. Except where specifically stated otherwise, in the case of a conflict between these two documents, [NNTP] takes precedence over this one.
本规范应与NNTP基本规范[NNTP]一起阅读。除非另有特别说明，如果这两份文件之间存在冲突，[NNTP]优先于本文件。
It is also recommended that this specification be read in conjunction with the SASL base specification [SASL].
还建议结合SASL基本规范[SASL]阅读本规范。
The notational conventions used in this document are the same as those in [NNTP], and any term not defined in this document has the same meaning as it does in that one.
本文件中使用的符号约定与[NNTP]中的符号约定相同，且本文件中未定义的任何术语具有与该文件中相同的含义。
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]中定义。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S].
在示例中，来自客户端的命令用[C]表示，来自服务器的响应用[S]表示。
The AUTHINFO extension is used to authenticate a user. Note that authorization is a matter of site policy, not network protocol, and therefore it is not discussed in this document. The server determines authorization in whatever manner is defined by its implementation as configured by the site administrator.
AUTHINFO扩展用于对用户进行身份验证。请注意，授权是站点策略的问题，而不是网络协议的问题，因此本文档中不讨论此问题。服务器以站点管理员配置的实现定义的任何方式确定授权。
This extension provides three new commands: AUTHINFO USER, AUTHINFO PASS, and AUTHINFO SASL. The capability label for this extension is AUTHINFO.
此扩展提供了三个新命令：AUTHINFO USER、AUTHINFO PASS和AUTHINFO SASL。此扩展的功能标签为AUTHINFO。
A server MUST implement at least one of the AUTHINFO USER or AUTHINFO SASL commands in order to advertise the "AUTHINFO" capability label in response to the CAPABILITIES command ([NNTP] Section 5.2). However, this capability MUST NOT be advertised after successful authentication (see Section 2.2). This capability MAY be advertised both before and after any use of the MODE READER command ([NNTP] Section 5.3), with the same semantics.
服务器必须实现至少一个AUTHINFO USER或AUTHINFO SASL命令，以便公布“AUTHINFO”功能标签，以响应CAPABILITIES命令（[NNTP]第5.2节）。但必须在认证成功后发布（请参见第2.2节）。在使用模式读取器命令之前和之后（[NNTP]第5.3节），可以使用相同的语义公布此功能。
The AUTHINFO capability label contains an argument list detailing which authentication commands are available.
AUTHINFO功能标签包含一个参数列表，详细说明哪些身份验证命令可用。
The "USER" argument indicates that AUTHINFO USER/PASS is supported as defined by Section 2.3 of this document. The "USER" argument MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD NOT be provided, unless a strong encryption layer (e.g., Transport Layer Security (TLS) [NNTP-TLS]) is in use or backward compatibility dictates otherwise.
“USER”参数表示本文档第2.3节定义的AUTHINFO USER/PASS受支持。除非使用强加密层（例如，传输层安全性（TLS）[NNTP-TLS]），否则不得公布“用户”参数，也不得提供AUTHINFO USER/PASS命令。
The "SASL" argument indicates that AUTHINFO SASL is supported as defined by Section 2.4 of this document. If the server advertises the "SASL" argument, then it MUST also advertise the "SASL" capability in response to the CAPABILITIES command. The SASL capability is followed by a whitespace-separated list of available SASL mechanism names.
“SASL”参数表示本文档第2.4节定义的AUTHINFO SASL受支持。如果服务器播发“SASL”参数，那么它还必须播发“SASL”功能以响应CAPABILITIES命令。SASL功能后面是可用SASL机制名称的空白分隔列表。
The server MAY list the AUTHINFO capability with no arguments, which indicates that it complies with this specification and does not permit any authentication commands in its current state. In this case, the client MUST NOT attempt to utilize any AUTHINFO commands, even if it contains logic that might otherwise cause it to do so
服务器可以不带参数地列出AUTHINFO功能，这表明它符合此规范，并且不允许在其当前状态下使用任何身份验证命令。在这种情况下，客户机不得尝试使用任何AUTHINFO命令，即使它包含可能导致它这样做的逻辑
(e.g., for backward compatibility with servers that are not compliant with this specification).
（例如，与不符合本规范的服务器向后兼容）。
Future extensions may add additional arguments to this capability. Unrecognized arguments MUST be ignored by the client.
将来的扩展可能会为此功能添加其他参数。客户端必须忽略无法识别的参数。
As the AUTHINFO command is related to security, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [NNTP]. However, a client MAY use such cached results in order to detect active down-negotiation attacks.
根据[NNTP]第12.6节的规定，由于AUTHINFO命令与安全性相关，因此不得依赖上一个会话的缓存功能结果。然而，客户机可以使用这种缓存结果来检测主动向下协商攻击。
Example of AUTHINFO capabilities before and after the use of the STARTTLS [NNTP-TLS] extension:
使用STARTTLS[NNTP-TLS]扩展前后的AUTHINFO功能示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] STARTTLS
[S] AUTHINFO SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation proceeds, further commands protected by TLS]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] AUTHINFO USER SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] STARTTLS
[S] AUTHINFO SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation proceeds, further commands protected by TLS]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] AUTHINFO USER SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL
[S] LIST ACTIVE NEWSGROUPS
[S] .
An NNTP server responds to a client command with a 480 response to indicate that the client MUST authenticate and/or authorize in order to use that command or access the indicated resource. Use of the AUTHINFO command as described below is one such way that a client can authenticate/authorize to the server. The client MAY therefore use an AUTHINFO command after receiving a 480 response. A client intending to use an AUTHINFO command SHOULD issue the CAPABILITIES command to obtain the available authentication commands and mechanisms before attempting authentication.
NNTP服务器以480响应响应客户机命令，以指示客户机必须进行身份验证和/或授权才能使用该命令或访问所指示的资源。如下所述使用AUTHINFO命令是客户端可以向服务器进行身份验证/授权的一种方式。因此，客户端可以在收到480响应后使用AUTHINFO命令。打算使用AUTHINFO命令的客户端应发出CAPABILITIES命令，以在尝试身份验证之前获取可用的身份验证命令和机制。
If a server advertises the AUTHINFO capability, a client MAY attempt the first step of authentication at any time during a session to acquire additional privileges without having received a 480 response. Servers SHOULD accept such unsolicited authentication requests. A server MUST NOT under any circumstances reply to an AUTHINFO command with a 480 response.
如果服务器播发AUTHINFO功能，则客户端可以在会话期间的任何时间尝试身份验证的第一步，以获取附加权限，而无需收到480响应。服务器应接受此类未经请求的身份验证请求。服务器在任何情况下都不得以480响应回复AUTHINFO命令。
A client MUST NOT under any circumstances continue with any steps of authentication beyond the first, unless the response code from the server indicates that the authentication exchange is welcomed. In particular, anything other than a 38x response code indicates that the client MUST NOT continue the authentication exchange.
客户机在任何情况下都不得继续执行第一步以外的任何身份验证步骤，除非来自服务器的响应代码表明欢迎身份验证交换。特别是，除38x响应代码以外的任何代码都指示客户端不得继续身份验证交换。
After a successful authentication, the client MUST NOT issue another AUTHINFO command in the same session. A server MUST NOT return the AUTHINFO capability in response to a CAPABILITIES command, and a server MUST reject any subsequent AUTHINFO commands with a 502 response. Additionally, the client MUST NOT issue a MODE READER command after authentication, and a server MUST NOT advertise the MODE-READER capability.
成功身份验证后，客户端不得在同一会话中发出另一个AUTHINFO命令。服务器不得返回AUTHINFO功能以响应CAPABILITIES命令，并且服务器必须拒绝具有502响应的任何后续AUTHINFO命令。此外，客户端在身份验证后不得发出模式读取器命令，服务器不得公布模式读取器功能。
In agreement with [SASL], the server MUST continue to advertise the SASL capability in response to a CAPABILITIES command with the same list of SASL mechanisms that it did before authentication (thereby enabling the client to detect a possible active down-negotiation attack). Other capabilities returned in response to a CAPABILITIES command received after authentication MAY be different from those returned before authentication. For example, an NNTP server may not want to advertise support for a specific extension unless a client has been authenticated.
在与[SASL]达成一致的情况下，服务器必须继续公布SASL能力，以响应与身份验证之前相同的SASL机制列表的能力命令（从而使客户端能够检测到可能的主动向下协商攻击）。在验证后接收到的capabilities命令响应时返回的其他功能可能与验证前返回的功能不同。例如，NNTP服务器可能不希望公布对特定扩展的支持，除非客户端已通过身份验证。
Note that a server may perform a successful authentication exchange with a client and yet still deny access to some or all resources; the permanent 502 response indicates that a resource is unavailable even though authentication has been performed (this is in contrast to the temporary 480 error, which indicates that a resource is unavailable now but may become available after authentication).
请注意，服务器可能会成功地与客户机进行身份验证交换，但仍然拒绝对部分或所有资源的访问；永久502响应指示即使已执行身份验证，资源也不可用（这与临时480错误相反，临时480错误指示资源现在不可用，但在身份验证后可能变为可用）。
This section supersedes the definition of the AUTHINFO USER and AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP-COMMON].
本节取代[NNTP-COMMON]第3.1.1节中记录的AUTHINFO USER和AUTHINFO PASS命令的定义。
These commands MUST NOT be pipelined.
这些命令不得以管道方式传输。
Syntax AUTHINFO USER username AUTHINFO PASS password
语法AUTHINFO用户用户名AUTHINFO密码
Responses 281 Authentication accepted 381 Password required [1] 481 Authentication failed/rejected 482 Authentication commands issued out of sequence 502 Command unavailable [2]
响应281身份验证接受381密码要求[1]481身份验证失败/拒绝482身份验证命令顺序错误发出502命令不可用[2]
[1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx codes, which indicate that the client may continue the current command, the legacy 381 code means that the AUTHINFO PASS command must be used to complete the authentication exchange.
[1] 仅对AUTHINFO用户有效。请注意，与传统的3xx代码不同，传统的381代码表示客户端可以继续当前命令，传统的381代码意味着必须使用AUTHINFO PASS命令来完成身份验证交换。
[2] If authentication has already occurred, AUTHINFO USER/PASS are not valid commands (see Section 2.2).
[2] 如果已进行身份验证，则AUTHINFO USER/PASS命令无效（请参阅第2.2节）。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST NOT return 480 in response to AUTHINFO USER/PASS.
注意：尽管有[NNTP]第3.2.1节的规定，服务器不得返回480以响应AUTHINFO USER/PASS。
Parameters username = string identifying the user/client password = string representing the user's password
参数username=标识用户/客户端密码的字符串=表示用户密码的字符串
The AUTHINFO USER and AUTHINFO PASS commands are used to present clear text credentials to the server. These credentials consist of a username or a username plus a password (the distinction is that a password is expected to be kept secret, whereas a username is not; this does not directly affect the protocol but may have an impact on user interfaces). The username is supplied through the AUTHINFO USER command, and the password through the AUTHINFO PASS command.
AUTHINFO USER和AUTHINFO PASS命令用于向服务器提供明文凭据。这些凭证由用户名或用户名加密码组成（区别在于密码应保密，而用户名不保密；这不会直接影响协议，但可能会影响用户界面）。用户名通过AUTHINFO USER命令提供，密码通过AUTHINFO PASS命令提供。
If the server requires only a username, it MUST NOT give a 381 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO PASS.
如果服务器只需要用户名，则它不能向AUTHINFO用户提供381响应，而必须向AUTHINFO PASS提供482响应。
If the server requires both username and password, the former MUST be sent before the latter. The server will need to cache the username until the password is received; it MAY require that the password be
如果服务器同时需要用户名和密码，则必须先发送用户名和密码，再发送密码。服务器需要缓存用户名，直到收到密码；可能需要输入密码
sent in the immediately next command (in other words, only caching the username until the next command is sent). The server:
在紧接下一个命令中发送（换句话说，在下一个命令发送之前只缓存用户名）。服务器：
- MUST return a 381 response to AUTHINFO USER;
- 必须向AUTHINFO用户返回381响应；
- MUST return a 482 response to AUTHINFO PASS if there is no cached username;
- 如果没有缓存的用户名，则必须返回对AUTHINFO PASS的482响应；
- MUST use the argument of the most recent AUTHINFO USER for authentication; and
- 必须使用最新AUTHINFO用户的参数进行身份验证；和
- MUST NOT return a 381 response to AUTHINFO PASS.
- 不能返回对AUTHINFO PASS的381响应。
The server MAY determine whether a password is needed for a given username. Thus the same server can respond with both 381 and other response codes to AUTHINFO USER.
服务器可以确定给定用户名是否需要密码。因此，同一服务器可以使用381和其他响应代码响应AUTHINFO用户。
Should the client successfully present proper credentials, the server issues a 281 reply. If the server is unable to authenticate the client, it MUST reject the AUTHINFO USER/PASS command with a 481 reply. If an AUTHINFO USER/PASS command fails, the client MAY proceed without authentication. Alternatively, the client MAY try another authentication mechanism or present different credentials by issuing another AUTHINFO command.
如果客户端成功地提供了正确的凭据，服务器将发出281回复。如果服务器无法对客户端进行身份验证，则必须拒绝带有481回复的AUTHINFO USER/PASS命令。如果AUTHINFO USER/PASS命令失败，则客户端可以在不进行身份验证的情况下继续。或者，客户端可以尝试另一种身份验证机制，或者通过发出另一个AUTHINFO命令来提供不同的凭据。
The AUTHINFO PASS command permits the client to use a clear-text password to authenticate. A compliant implementation MUST NOT implement this command without also implementing support for TLS [NNTP-TLS]. Use of this command without an active strong encryption layer is deprecated, as it exposes the user's password to all parties on the network between the client and the server. Any implementation of this command SHOULD be configurable to disable it whenever a strong encryption layer (such as that provided by [NNTP-TLS]) is not active, and this configuration SHOULD be the default. The server will use the 483 response code to indicate that the datastream is insufficiently secure for the command being attempted (see Section 3.2.1 of [NNTP]).
authinfopass命令允许客户端使用明文密码进行身份验证。兼容实现必须在未实现对TLS[NNTP-TLS]的支持的情况下实现此命令。不推荐在没有活动强加密层的情况下使用此命令，因为它会向客户端和服务器之间的网络上的所有各方公开用户密码。只要强加密层（如[NNTP-TLS]提供的层）未激活，该命令的任何实现都应可配置为禁用该命令，并且该配置应为默认配置。服务器将使用483响应代码来指示数据流对于正在尝试的命令不够安全（参见[NNTP]第3.2.1节）。
Note that a server MAY (but is not required to) allow white space characters in usernames and passwords. A server implementation MAY blindly split command arguments at white space and therefore may not preserve the exact sequence of white space characters in the username or password. Therefore, a client SHOULD scan the username and password for white space and, if any is detected, warn the user of the likelihood of problems. The SASL PLAIN [PLAIN] mechanism is recommended as an alternative, as it does not suffer from these issues.
请注意，服务器可能（但不是必须）允许用户名和密码中使用空格字符。服务器实现可能会在空白处盲目分割命令参数，因此可能无法在用户名或密码中保留空白字符的精确序列。因此，客户机应扫描用户名和密码中的空白，如果检测到任何空白，应警告用户可能出现问题。建议将SASL平原[平原]机制作为替代方案，因为它不会受到这些问题的影响。
Also note that historically the username is not canonicalized in any way. Servers MAY use the [SASLprep] profile of the [StringPrep] algorithm to prepare usernames for comparison, but doing so may cause interoperability problems with legacy implementations. If canonicalization is desired, the SASL PLAIN [PLAIN] mechanism is recommended as an alternative.
还要注意，从历史上看，用户名没有以任何方式规范化。服务器可以使用[StringPrep]算法的[SASLprep]配置文件来准备用户名进行比较，但这样做可能会导致与传统实现的互操作性问题。如果需要规范化，建议使用SASL平原[平原]机制作为替代方案。
Example of successful AUTHINFO USER:
成功的AUTHINFO用户示例：
[C] AUTHINFO USER wilma [S] 281 Authentication accepted
[C] 已接受AUTHINFO用户wilma[S]281身份验证
Example of successful AUTHINFO USER/PASS:
成功的AUTHINFO用户/通过示例：
[C] AUTHINFO USER fred
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 281 Authentication accepted
[C] AUTHINFO USER fred
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 281 Authentication accepted
Example of AUTHINFO USER/PASS requiring a security layer:
需要安全层的AUTHINFO用户/密码示例：
[C] AUTHINFO USER fred@stonecanyon.example.com [S] 483 Encryption or stronger authentication required
[C] AUTHINFO用户fred@stonecanyon.example.com[S]483需要加密或更强的身份验证
Example of failed AUTHINFO USER/PASS:
失败的AUTHINFO用户/通行证示例：
[C] AUTHINFO USER barney
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 481 Authentication failed
[C] AUTHINFO USER barney
[S] 381 Enter passphrase
[C] AUTHINFO PASS flintstone
[S] 481 Authentication failed
Example of AUTHINFO PASS before AUTHINFO USER:
AUTHINFO用户之前的AUTHINFO传递示例：
[C] AUTHINFO PASS flintstone [S] 482 Authentication commands issued out of sequence
[C] AUTHINFO PASS flintstone[S]482身份验证命令发出顺序不正确
This section defines a formal profile of the Simple Authentication and Security Layer [SASL]. The use of the AUTHINFO GENERIC command as documented in Section 3.1.3 of [NNTP-COMMON], as a way to perform SASL authentication, is deprecated in favor of the AUTHINFO SASL command. A server SHOULD NOT advertise AUTHINFO GENERIC in the list of capabilities returned by CAPABILITIES.
本节定义了简单身份验证和安全层[SASL]的正式概要。不赞成使用[NNTP-COMMON]第3.1.3节中记录的AUTHINFO通用命令作为执行SASL身份验证的方法，而赞成使用AUTHINFO SASL命令。服务器不应在功能返回的功能列表中公布AUTHINFO GENERIC。
This command MUST NOT be pipelined.
此命令不能通过管道传输。
Syntax AUTHINFO SASL mechanism [initial-response]
语法AUTHINFO SASL机制[初始响应]
This command MAY exceed 512 octets. The maximum length of this command is increased to that which can accommodate the largest encoded initial response possible for any of the SASL mechanisms supported by the implementation.
此命令可能超过512个八位字节。此命令的最大长度将增加到可以容纳实现支持的任何SASL机制可能的最大编码初始响应的长度。
Responses
281 Authentication accepted
283 challenge Authentication accepted (with success data) [1]
383 challenge Continue with SASL exchange [1]
481 Authentication failed/rejected
482 SASL protocol error
502 Command unavailable [2]
Responses
281 Authentication accepted
283 challenge Authentication accepted (with success data) [1]
383 challenge Continue with SASL exchange [1]
481 Authentication failed/rejected
482 SASL protocol error
502 Command unavailable [2]
[1] These responses MAY exceed 512 octets. The maximum length of these responses is increased to that which can accommodate the largest encoded challenge possible for any of the SASL mechanisms supported by the implementation.
[1] 这些响应可能超过512个八位字节。这些响应的最大长度增加到可以容纳实现支持的任何SASL机制可能的最大编码挑战的长度。
[2] If authentication has already occurred, AUTHINFO SASL is not a valid command (see Section 2.2).
[2] 如果已进行身份验证，则AUTHINFO SASL不是有效的命令（请参阅第2.2节）。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST NOT return 480 in response to AUTHINFO SASL.
注意：尽管有[NNTP]第3.2.1节的规定，服务器不得返回480以响应AUTHINFO SASL。
Parameters mechanism = String identifying a [SASL] authentication mechanism. initial-response = Optional initial client response. If present, the response MUST be encoded as specified in Section 4 of [BASE64]. [3] challenge = Server challenge. The challenge MUST be encoded as specified in Section 4 of [BASE64].
参数机制=标识[SASL]身份验证机制的字符串。初始响应=可选的初始客户端响应。如果存在，响应必须按照[BASE64]第4节的规定进行编码。[3] 挑战=服务器挑战。质询必须按照[BASE64]第4节的规定进行编码。
[3] This argument MAY exceed 497 octets. The maximum length of this argument is increased to that which can accommodate the largest encoded initial response possible for any of the SASL mechanisms supported by the implementation.
[3] 此参数可能超过497个八位字节。此参数的最大长度增加到可以容纳实现支持的任何SASL机制可能的最大编码初始响应的长度。
The AUTHINFO SASL command initiates a [SASL] exchange between the client and the server. The client identifies the SASL mechanism to be used with the first parameter of the AUTHINFO SASL command. If the server supports the requested authentication mechanism, it performs the SASL exchange to authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions during this session. If the requested authentication mechanism is invalid (e.g., is not supported), the server rejects the AUTHINFO SASL command with a 503 reply (see Section 3.2.1 of [NNTP]). If the requested authentication mechanism requires an encryption layer, the server rejects the AUTHINFO SASL command with a 483 reply (see Section 3.2.1 of [NNTP]).
AUTHINFO SASL命令启动客户端和服务器之间的[SASL]交换。客户端标识要与AUTHINFO SASL命令的第一个参数一起使用的SASL机制。如果服务器支持请求的身份验证机制，它将执行SASL交换以对用户进行身份验证。可选地，它还为会话期间的后续协议交互协商安全层。如果请求的身份验证机制无效（例如，不受支持），服务器将拒绝AUTHINFO SASL命令，并给出503回复（参见[NNTP]第3.2.1节）。如果请求的身份验证机制需要加密层，服务器将拒绝AUTHINFO SASL命令，并给出483回复（请参见[NNTP]第3.2.1节）。
The service name specified by this protocol's profile of SASL is "nntp".
此协议的SASL配置文件指定的服务名称为“nntp”。
The SASL exchange consists of a series of server challenges and client responses that are specific to the chosen [SASL] mechanism.
SASL交换由一系列特定于所选[SASL]机制的服务器挑战和客户端响应组成。
A server challenge is sent as a 383 reply with a single argument containing the [BASE64]-encoded string supplied by the SASL mechanism. A server challenge that has zero length MUST be sent as a single equals sign ("=") and MUST be included (in order to comply with the [NNTP] requirement that responses always have the same number of arguments).
服务器质询作为383应答发送，其中包含SASL机制提供的[BASE64]编码字符串的单个参数。长度为零的服务器质询必须作为单个等号（“=”）发送，并且必须包含在内（以符合响应始终具有相同数量参数的[NNTP]要求）。
A client response consists of a line containing a [BASE64]-encoded string. A client response that has zero length MUST be sent as a single equals sign ("=") and MUST be included (for consistency with the server challenge format). If the client wishes to cancel the authentication exchange, it issues a line with a single "*". If the server receives such a response, it MUST reject the AUTHINFO SASL command by sending a 481 reply.
客户端响应由包含[BASE64]编码字符串的行组成。长度为零的客户端响应必须作为单个等号（“=”）发送，并且必须包含在内（以与服务器质询格式保持一致）。如果客户端希望取消身份验证交换，它将发出一行，其中包含一个“*”。如果服务器收到这样的响应，它必须通过发送481回复来拒绝AUTHINFO SASL命令。
Note that these [BASE64]-encoded strings can be much longer than normal NNTP responses. Clients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported authentication mechanisms. This requirement is independent of any line length limitations the client or server may have in other parts of its protocol implementation.
请注意，这些[BASE64]编码的字符串可能比正常的NNTP响应长得多。客户机和服务器必须能够处理由其支持的身份验证机制生成的挑战和响应的最大编码大小。此要求独立于客户端或服务器在其协议实现的其他部分可能具有的任何线路长度限制。
The optional initial response argument to the AUTHINFO SASL command is used to save a round trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in section 5.1 of
AUTHINFO SASL命令的可选初始响应参数用于在使用支持初始客户端响应的身份验证机制时保存往返。如果省略了initial response参数，并且所选机制需要初始客户机响应，则服务器必须按照第5.1节中的定义进行操作
[SASL]. In NNTP, a server challenge that contains no data is equivalent to a zero-length challenge and is encoded as a single equals sign ("=").
[SASL]。在NNTP中，不包含数据的服务器质询相当于零长度质询，并被编码为一个等号（“=”）。
Note that the [BASE64]-encoded initial response argument can exceed 497 octets, and therefore that the AUTHINFO SASL command can exceed 512 octets. Clients SHOULD and servers MUST be able to handle the maximum encoded size of initial responses possible for their supported authentication mechanisms. This requirement is independent of any command or argument length limitations the client or server may have in other parts of its protocol implementation.
请注意，[BASE64]编码的初始响应参数可以超过497个八位字节，因此AUTHINFO SASL命令可以超过512个八位字节。客户端和服务器必须能够处理其支持的身份验证机制可能的初始响应的最大编码大小。此要求独立于客户端或服务器在其协议实现的其他部分可能具有的任何命令或参数长度限制。
If use of the initial response argument would cause the AUTHINFO SASL command to exceed 512 octets, the client MAY choose to omit the initial response parameter (and instead proceed as defined in Section 5.1 of [SASL]).
如果使用initial response参数会导致AUTHINFO SASL命令超过512个八位字节，则客户端可以选择省略initial response参数（而是按照[SASL]第5.1节中的定义进行操作）。
If the client is transmitting an initial response of zero length, it MUST instead transmit the response as a single equals sign ("="). This indicates that the response is present, but that it contains no data.
如果客户端正在传输长度为零的初始响应，则它必须改为以单个等号（“=”）传输响应。这表示响应存在，但不包含任何数据。
If the client uses an initial-response argument to the AUTHINFO SASL command with a SASL mechanism that does not support an initial client response, the server MUST reject the AUTHINFO SASL command with a 482 reply.
如果客户端对AUTHINFO SASL命令使用不支持初始客户端响应的SASL机制的initial response参数，则服务器必须以482回复拒绝AUTHINFO SASL命令。
If the server cannot [BASE64] decode any client response, it MUST reject the AUTHINFO SASL command with a 504 reply (see Section 3.2.1 of [NNTP]). If the client cannot BASE64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response. In particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the BASE64 alphabet, and they MUST reject 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]解码任何客户端响应，则必须拒绝带有504回复的AUTHINFO SASL命令（参见[NNTP]第3.2.1节）。如果客户端无法BASE64解码服务器的任何挑战，则必须使用“*”响应取消身份验证。特别是，服务器和客户端必须拒绝（而不是忽略）BASE64字母表不明确允许的任何字符，并且必须拒绝任何包含填充字符（'='）的BASE64字符序列，而不是字符串末尾（例如，不允许“=AAA”和“AAA=BBB”）。
The authorization identity generated by this [SASL] exchange is a simple username, and both client and server MUST use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication with a 481 reply.
此[SASL]交换生成的授权标识是一个简单的用户名，客户端和服务器都必须使用[StringPrep]算法的[SASLprep]配置文件来准备这些名称以便传输或比较。如果授权标识的准备失败或导致空字符串（除非它作为空字符串传输），服务器必须通过481应答使身份验证失败。
Should the client successfully complete the exchange, the server issues either a 281 or a 283 reply. If the server is unable to authenticate the client, it MUST reject the AUTHINFO SASL command
如果客户端成功完成交换，服务器将发出281或283回复。如果服务器无法对客户端进行身份验证，则必须拒绝AUTHINFO SASL命令
with a 481 reply. If an AUTHINFO SASL command fails, the client MAY proceed without authentication. Alternatively, the client MAY try another authentication mechanism, or present different credentials by issuing another AUTHINFO command.
答复是481。如果AUTHINFO SASL命令失败，则客户端可以在不进行身份验证的情况下继续。或者，客户端可以尝试另一种身份验证机制，或者通过发出另一个AUTHINFO命令来提供不同的凭据。
If the SASL mechanism returns additional data on success (e.g., server authentication), the NNTP server issues a 283 reply with a single argument containing the [BASE64]-encoded string supplied by the SASL mechanism. If no additional data is returned on success, the server issues a 281 reply.
如果SASL机制在成功时返回附加数据（例如，服务器身份验证），NNTP服务器将发出一个283回复，其中包含SASL机制提供的[BASE64]编码字符串的单个参数。如果成功后没有返回其他数据，服务器将发出281回复。
If a security layer is negotiated during the SASL exchange, it takes effect for the client on the octet immediately following the CRLF that concludes the last response generated by the client. For the server, it takes effect immediately following the CRLF of its success reply.
如果在SASL交换期间协商了安全层，则它将在CRLF结束客户端生成的最后一个响应后立即对客户端的八位字节生效。对于服务器，它在成功回复的CRLF之后立即生效。
When a security layer takes effect, the NNTP protocol is reset to the state immediately after the initial greeting response (see 5.1 of [NNTP]) has been sent, with the exception that if a MODE READER command has been issued, the effects of it (if any) are not reversed. The server MUST discard any knowledge obtained from the client, such as the current newsgroup and article number, that was not obtained from the SASL negotiation itself. Likewise, the client SHOULD discard and MUST NOT rely on any knowledge obtained from the server, such as the capability list, that was not obtained from the SASL negotiation itself. (Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack.)
当安全层生效时，NNTP协议立即重置为初始问候响应（见[NNTP]第5.1节）发送后的状态，但如果发出了模式读取器命令，其效果（如果有）不会逆转。服务器必须放弃从客户端获得的、而不是从SASL协商本身获得的任何知识，例如当前新闻组和文章编号。同样，客户机应该放弃，并且不能依赖从服务器获得的任何知识，例如不是从SASL协商本身获得的能力列表。（请注意，客户端可能会比较身份验证前后公布的SASL机制，以检测主动向下协商攻击。）
When both TLS [NNTP-TLS] and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding (the cleartext data is always SASL encoded first, and then the resultant data is TLS encoded).
当TLS[NNTP-TLS]和SASL安全层都有效时，必须在SASL编码之后应用TLS编码（明文数据总是先进行SASL编码，然后再对结果数据进行TLS编码）。
To ensure interoperability, client and server implementations of this extension MUST implement the [DIGEST-MD5] SASL mechanism.
为了确保互操作性，此扩展的客户端和服务器实现必须实现[DIGEST-MD5]SASL机制。
If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the SASL [PLAIN] mechanism SHOULD also be implemented, as the functionality of DIGEST-MD5 is insufficient for some environments (e.g., the server may need to pass off the plaintext password to an external authentication service). The SASL PLAIN mechanism is preferred over AUTHINFO USER, even if there is not a strong encryption layer active, because it eliminates limitations that AUTHINFO USER/PASS has with regards to the use of white space characters being used in usernames and passwords.
如果AUTHINFO USER/PASS和AUTHINFO SASL都已实现，则还应实现SASL[PLAIN]机制，因为DIGEST-MD5的功能对于某些环境是不够的（例如，服务器可能需要将明文密码传递给外部身份验证服务）。SASL普通机制优于AUTHINFO USER，即使没有活动的强加密层，因为它消除了AUTHINFO USER/PASS在用户名和密码中使用空白字符方面的限制。
Example of the [PLAIN] SASL mechanism under a TLS layer, using an initial client response:
TLS层下使用初始客户端响应的[PLAIN]SASL机制示例：
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] STARTTLS
[S] AUTHINFO SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation proceeds, further commands protected by TLS]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA==
[S] 281 Authentication accepted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] STARTTLS
[S] AUTHINFO SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation proceeds, further commands protected by TLS]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] AUTHINFO USER SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA==
[S] 281 Authentication accepted
Example of the EXTERNAL SASL mechanism under a TLS layer, using the authorization identity derived from the client TLS certificate, and thus a zero-length initial client response (commands prior to AUTHINFO SASL are the same as the previous example and have been omitted):
TLS层下的外部SASL机制示例，使用从客户端TLS证书派生的授权标识，从而获得零长度的初始客户端响应（AUTHINFO SASL之前的命令与前面的示例相同，已被省略）：
[C] AUTHINFO SASL EXTERNAL = [S] 281 Authentication accepted
[C] AUTHINFO SASL EXTERNAL=[S]281已接受身份验证
Example of the [DIGEST-MD5] SASL mechanism, which includes a server challenge and server success data (white space has been inserted for clarity; base64-encoded data is actually sent as a single line with no embedded white space):
[DIGEST-MD5]SASL机制的示例，其中包括服务器质询和服务器成功数据（为了清晰起见，插入了空格；base64编码的数据实际上是作为单行发送的，没有嵌入空格）：
[C] AUTHINFO SASL DIGEST-MD5 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 aG09bWQ1LXNlc3M=
[C] 作者信息SASL DIGEST-MD5[S]383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 Enplqr1ave9IIXYZWFSBT0IZWFNBGUb2N2LYW5HLMNVBSISCW9WPSJDHDRO LGF1DGGTAW50LGF1DGT29UZIISY2WAGVYPSJYZQTNDASCMM0LTU2LHJJ NCXKZXM2LCYISBWF4YNvYPTQWOTYSY2HHCN11DGT10AGBWLX10LxLX=
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ==
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ==translate error, please retry
Example of a failed authentication due to bad [GSSAPI] credentials. Note that although the mechanism can utilize the initial response, the client chooses not to use it because of its length, resulting in a zero-length server challenge (here, white space has been inserted for clarity; base64-encoded data is actually sent as a single line with no embedded white space):
由于[GSSAPI]凭据错误而导致身份验证失败的示例。请注意，尽管该机制可以利用初始响应，但由于其长度，客户端选择不使用它，从而导致零长度服务器挑战（此处，为清晰起见插入了空格；base64编码的数据实际上是作为单行发送的，没有嵌入空格）：
[C] AUTHINFO SASL GSSAPI
[S] 383 =
[C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj
ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw
IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB
EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198
vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP
ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E
95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ
djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6
Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj
RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL
kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0
0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF
iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw=
[S] 481 Authentication error
[C] AUTHINFO SASL GSSAPI
[S] 383 =
[C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj
ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw
IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB
EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198
vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP
ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E
95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ
djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6
Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj
RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL
kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0
0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF
iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw=
[S] 481 Authentication error
Example of a client aborting in the midst of an exchange:
客户端在交换过程中中止的示例：
[C] AUTHINFO SASL GSSAPI
[S] 383 =
[C] *
[S] 481 Authentication aborted as requested
[C] AUTHINFO SASL GSSAPI
[S] 383 =
[C] *
[S] 481 Authentication aborted as requested
Example of attempting to use a mechanism that is not supported by the server:
尝试使用服务器不支持的机制的示例：
[C] AUTHINFO SASL EXAMPLE [S] 503 Mechanism not recognized
[C] 无法识别AUTHINFO SASL示例[S]503机制
Example of attempting to use a mechanism that requires a security layer:
尝试使用需要安全层的机制的示例：
[C] AUTHINFO SASL PLAIN [S] 483 Encryption or stronger authentication required
[C] 需要AUTHINFO SASL普通[S]483加密或更强的身份验证
Example of using an initial response with a mechanism that doesn't support it (the server must start the exchange when using [CRAM-MD5]):
使用不支持初始响应的机制（使用[CRAM-MD5]时服务器必须启动exchange）的示例：
[C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== [S] 482 SASL protocol error
[C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA==[S]482 SASL协议错误
Example of an authentication that failed due to an incorrectly encoded response:
由于错误编码的响应而失败的身份验证示例：
[C] AUTHINFO SASL CRAM-MD5
[S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+
[C] abcd=efg
[S] 504 Base64 encoding error
[C] AUTHINFO SASL CRAM-MD5
[S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+
[C] abcd=efg
[S] 504 Base64 encoding error
This section describes the formal syntax of the AUTHINFO extension using ABNF [ABNF]. It extends the syntax in Section 9 of [NNTP], and non-terminals not defined in this document are defined there. The [NNTP] ABNF should be imported first before attempting to validate these rules.
本节使用ABNF[ABNF]描述AUTHINFO扩展的形式语法。它扩展了[NNTP]第9节中的语法，本文件中未定义的非终端在此处定义。在尝试验证这些规则之前，应首先导入[NNTP]ABNF。
This syntax extends the non-terminal "command", which represents an NNTP command.
此语法扩展了表示NNTP命令的非终端“命令”。
command =/ authinfo-sasl-command / authinfo-user-command / authinfo-pass-command
command=/authinfo sasl command/authinfo user command/authinfo pass command
authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism [WS initial-response] authinfo-user-command = "AUTHINFO" WS "USER" WS username authinfo-pass-command = "AUTHINFO" WS "PASS" WS password
authinfo sasl command=“authinfo”WS“sasl”WS机制[WS初始响应]authinfo user command=“authinfo”WS“user”WS username authinfo pass command=“authinfo”WS“pass”WS password
initial-response = base64-opt
username = 1*user-pass-char
password = 1*user-pass-char
user-pass-char = B-CHAR
initial-response = base64-opt
username = 1*user-pass-char
password = 1*user-pass-char
user-pass-char = B-CHAR
NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO PASS specially so as to allow white space to be used within the username or password. Such implementations accept the additional syntax (making these two items inconsistent with "token" in Section 9.8 of [NNTP]):
注意：服务器实现可能会专门解析AUTHINFO USER和AUTHINFO PASS，以便在用户名或密码中使用空格。此类实现接受附加语法（使这两项与[NNTP]第9.8节中的“令牌”不一致）：
user-pass-char =/ SP / TAB
user-pass-char =/ SP / TAB
In doing so, the grammar can become ambiguous if the username or password begins or ends with white space. To solve this ambiguity, such implementations typically treat everything after the first white space character following "USER"/"PASS", up to, but not including, the CRLF, as the username/password.
在这样做时，如果用户名或密码以空格开头或结尾，语法可能会变得模棱两可。为了解决这种模糊性，这种实现通常将“USER”/“PASS”之后第一个空格字符之后的所有内容（最多但不包括CRLF）视为用户名/密码。
This syntax extends the non-terminal "command-continuation", which represents the further material sent by the client in the case of multi-stage commands.
此语法扩展了非终端“命令继续”，它表示在多阶段命令的情况下客户端发送的进一步材料。
command-continuation =/ authinfo-sasl-383-continuation
命令继续=/authinfo-sasl-383-continuation
authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF
authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF
This syntax extends the non-terminal "initial-response-content", which represents an initial response line sent by the server.
此语法扩展了非终端“初始响应内容”，它表示服务器发送的初始响应行。
initial-response-content =/ response-283-content / response-383-content
初始响应内容=/response-283-content/response-383-content
response-283-content = "283" SP base64 response-383-content = "383" SP base64-opt
response-283-content=“283”SP base64 response-383-content=“383”SP base64 opt
This syntax extends the non-terminal "capability-entry", which represents a capability that may be advertised by the server.
此语法扩展了非终端“能力条目”，它表示可能由服务器公布的能力。
capability-entry =/ authinfo-capability / sasl-capability
能力条目=/authinfo能力/sasl能力
authinfo-capability = "AUTHINFO" *(WS authinfo-variant)
authinfo-variant = "USER" / "SASL"
sasl-capability = "SASL" 1*(WS mechanism)
authinfo-capability = "AUTHINFO" *(WS authinfo-variant)
authinfo-variant = "USER" / "SASL"
sasl-capability = "SASL" 1*(WS mechanism)
base64-opt = "=" / base64
mechanism = 1*20mech-char
mech-char = UPPER / DIGIT / "-" / "_"
base64-opt = "=" / base64
mechanism = 1*20mech-char
mech-char = UPPER / DIGIT / "-" / "_"
This section contains a list of each new response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is.
本节包含本文档中定义的每个新响应代码的列表，并指出它是否为多行代码、哪些命令可以生成它、它有哪些参数以及它的含义。
Response code 281 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication accepted
响应代码281由以下人员生成：AUTHINFO USER、AUTHINFO PASS、AUTHINFO SASL意思是：已接受身份验证
Response code 283 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: authentication accepted (with success data)
响应代码283生成者：AUTHINFO SASL 1参数：质询含义：已接受身份验证（带有成功数据）
Response code 381 Generated by: AUTHINFO USER Meaning: password required via AUTHINFO PASS command. Note that this code is used for backwards compatibility and does not conform to the traditional use of 3xx codes.
响应代码381由：AUTHINFO用户生成，意思是：通过AUTHINFO PASS命令需要密码。请注意，此代码用于向后兼容，不符合3xx代码的传统用法。
Response code 383 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: continue with SASL exchange
响应代码383生成者：AUTHINFO SASL 1参数：质询含义：继续SASL交换
Response code 481 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication failed/rejected
响应代码481由以下人员生成：AUTHINFO USER、AUTHINFO PASS、AUTHINFO SASL意思是：身份验证失败/被拒绝
Response code 482 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication commands issued out of sequence or SASL protocol error
生成的响应代码482：AUTHINFO USER、AUTHINFO PASS、AUTHINFO SASL意思是：发出的验证命令顺序错误或SASL协议错误
This section contains implementation suggestions and notes of best current practice; it does not specify further network protocol requirements.
本节包含实施建议和当前最佳实践注释；它没有规定进一步的网络协议要求。
Once authenticated, the authorization identity presented in the AUTHINFO exchange (username when using USER/PASS) SHOULD be included in an audit trail associating the identity with any articles supplied during a POST operation, and this configuration SHOULD be the default. This may be accomplished, for example, by inserting headers in the posted articles or by a server logging mechanism. The server MAY provide a facility for disabling the procedure described above, as some users or administrators may consider it a violation of privacy.
经过身份验证后，AUTHINFO交换中显示的授权标识（使用USER/PASS时的用户名）应包含在审核跟踪中，该跟踪将该标识与POST操作期间提供的任何项目相关联，并且此配置应为默认配置。这可以通过在发布的文章中插入标题或通过服务器日志机制来实现。服务器可以提供用于禁用上述过程的设施，因为一些用户或管理员可能认为这是对隐私的侵犯。
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
In general, the security considerations of [SASL] and any implemented SASL mechanisms are applicable here; only the most important are highlighted specifically below. Also, this extension is not intended to cure the security considerations described in section 12 of [NNTP]; those considerations remain relevant to any NNTP implementation.
一般而言，[SASL]的安全考虑因素和任何已实施的SASL机制在此适用；只有最重要的部分在下面特别强调。此外，该扩展并非旨在解决[NNTP]第12节所述的安全问题；这些考虑仍然与任何NNTP实施相关。
Before the [SASL] negotiation has begun, any protocol interactions may have been performed in the clear and may have been modified by an active attacker. For this reason, clients and servers MUST discard any sensitive knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer. Furthermore, the CAPABILITIES command SHOULD be re-issued upon the establishment of a security layer, and other protocol state SHOULD be re-negotiated as well.
在[SASL]协商开始之前，任何协议交互都可能已在clear中执行，并且可能已被活动攻击者修改。因此，客户机和服务器必须丢弃在建立安全层后开始SASL协商之前获得的任何敏感知识。此外，应在建立安全层后重新发布“能力”命令，并重新协商其他协议状态。
Servers MAY implement a policy whereby the connection is dropped after a number of failed authentication attempts. If they do so, they SHOULD NOT drop the connection until at least 3 attempts at authentication have failed.
服务器可以实现一种策略，即在多次身份验证尝试失败后断开连接。如果他们这样做，则在至少3次身份验证尝试失败之前，他们不应断开连接。
Implementations MUST support a configuration where authentication mechanisms that are vulnerable to passive eavesdropping attacks (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or used without the presence of an external security layer such as TLS [NNTP-TLS], and this configuration SHOULD be the default.
实现必须支持一种配置，即在没有外部安全层（如TLS[NNTP-TLS]）的情况下，不会公布或使用易受被动窃听攻击的身份验证机制（如AUTHINFO USER/PASS和SASL[PLAIN]），并且此配置应为默认配置。
When multiple authentication mechanisms are permitted by both client and server, an active attacker can cause a down-negotiation to the weakest mechanism. For this reason, both clients and servers SHOULD be configurable to forbid use of weak mechanisms. The minimum strength acceptable is a policy decision that is outside the scope of this specification.
当客户端和服务器都允许使用多个身份验证机制时，主动攻击者可导致与最薄弱的机制进行向下协商。因此，客户机和服务器都应该是可配置的，以禁止使用弱机制。可接受的最小强度是超出本规范范围的政策决定。
The IANA has registered the SASL/GSSAPI service name "nntp". This service name refers to authenticated use of Usenet news service when it is provided via the [NNTP] protocol.
IANA已注册SASL/GSSAPI服务名称“nntp”。此服务名称指通过[NNTP]协议提供的Usenet新闻服务的认证使用。
o Published Specification: This document.
o 已发布规范：本文件。
o Contact for Further Information: Authors of this document.
o 更多信息请联系：本文件作者。
o Change Controller: IESG <iesg@ietf.org>.
o 更改控制器：IESG<iesg@ietf.org>.
This section gives a formal definition of the AUTHINFO extension, as required by Section 3.3.3 of [NNTP] for the IANA registry.
本节给出了IANA注册中心[NNTP]第3.3.3节要求的AUTHINFO扩展的正式定义。
o This extension provides an extensible mechanism for NNTP authentication via a variety of methods.
o 此扩展通过多种方法为NNTP身份验证提供了一种可扩展的机制。
o The capability label for this extension is "AUTHINFO".
o 此扩展的功能标签为“AUTHINFO”。
o The "AUTHINFO" capability label has two possible optional arguments, "USER" and "SASL" (as defined in Section 2.1), indicating which variants of the AUTHINFO command are supported.
o “AUTHINFO”功能标签有两个可能的可选参数，“USER”和“SASL”（定义见第2.1节），指示支持哪些AUTHINFO命令变体。
o This extension also provides the "SASL" capability label, whose arguments list the available SASL mechanisms.
o 此扩展还提供了“SASL”功能标签，其参数列出了可用的SASL机制。
o This extension defines three new commands, AUTHINFO USER, AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and responses are defined in Sections 2.3 and 2.4.
o 此扩展定义了三个新命令AUTHINFO USER、AUTHINFO PASS和AUTHINFO SASL，其行为、参数和响应在第2.3节和第2.4节中定义。
o This extension does not associate any new responses with pre-existing NNTP commands.
o 此扩展不会将任何新响应与预先存在的NNTP命令相关联。
o This extension may affect the overall behavior of both server and client in that the AUTHINFO SASL command may require that subsequent communication be transmitted via an intermediary security layer.
o 此扩展可能会影响服务器和客户端的整体行为，因为AUTHINFO SASL命令可能要求通过中间安全层传输后续通信。
o The length of the AUTHINFO SASL command (as defined in this document) may exceed 512 octets. The maximum length of this command is increased to that which can accommodate the largest initial response possible for any of the SASL mechanisms supported by the implementation.
o AUTHINFO SASL命令的长度（如本文档中所定义）可能超过512个八位字节。此命令的最大长度将增加到可以容纳实现支持的任何SASL机制的最大初始响应的长度。
o This extension defines two new responses, 283 and 383, whose lengths may exceed 512 octets. The maximum length of these responses is increased to that which can accommodate the largest challenge possible for any of the SASL mechanisms supported by the implementation.
o 这个扩展定义了两个新的响应，283和383，它们的长度可能超过512个八位字节。这些响应的最大长度将增加到能够容纳实现支持的任何SASL机制可能面临的最大挑战的长度。
o This extension does not alter pipelining, but AUTHINFO commands cannot be pipelined.
o 此扩展不会改变管道，但AUTHINFO命令不能管道化。
o Use of this extension may alter the capabilities list; once the AUTHINFO command has been used successfully, the AUTHINFO capability can no longer be advertised by CAPABILITIES. Additionally, the MODE-READER capability MUST NOT be advertised after successful authentication.
o 使用此扩展可能会改变功能列表；成功使用AUTHINFO命令后，AUTHINFO功能将不再由功能播发。此外，模式读取器功能在成功身份验证后不得公布。
o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response.
o 此扩展不会导致任何预先存在的命令生成401、480或483响应。
o This extension is unaffected by any use of the MODE READER command; however, the MODE READER command MUST NOT be used in the same session following successful authentication.
o 此扩展不受任何使用模式读取器命令的影响；但是，成功身份验证后，不能在同一会话中使用模式读取器命令。
o Published Specification: This document.
o 已发布规范：本文件。
o Contact for Further Information: Authors of this document.
o 更多信息请联系：本文件作者。
o Change Controller: IESG <iesg@ietf.org>.
o 更改控制器：IESG<iesg@ietf.org>.
This RFC originated from a document initially written by Chris Newman.
该RFC源于最初由Chris Newman编写的文档。
A significant amount of the authentication text was originally from the NNTP revision or common authentication specs written by Stan Barber. A significant amount of the SASL text was lifted from the revisions to RFC 1734 and RFC 2554 by Rob Siemborski.
大量认证文本最初来自NNTP修订版或Stan Barber编写的通用认证规范。Rob Siemborski从RFC 1734和RFC 2554的修订版中删除了大量SASL文本。
Special acknowledgement also goes to Russ Allbery, Clive Feather, and others who commented privately on intermediate revisions of this document, as well as the members of the IETF NNTP Working Group for continual (yet sporadic) insight in discussion.
特别感谢Russ Allbery、Clive Feather和其他私下评论本文件中间版本的人，以及IETF NNTP工作组成员在讨论中的持续（但零星）见解。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[AUTH]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[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月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]Feather，C.，“网络新闻传输协议（NNTP）”，RFC 3977，2006年10月。
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS]Murchison，K.，Vinocur，J.，和C.Newman，“将传输层安全（TLS）与网络新闻传输协议（NNTP）结合使用”，RFC 4642，2006年10月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga，K.，“SASLprep:Stringprep用户名和密码配置文件”，RFC 4013，2005年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep]Hoffman，P.和M.Blanchet，“国际化弦的准备（“StringPrep”）”，RFC 3454，2002年12月。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[BEEP]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[CRAM-MD5]Nerenberg，L.，“CRAM-MD5 SASL机制”，正在进行中。
[GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", Work in Progress.
[GSSAPI]Melnikov，A.，“SASL GSSAPI机制”，正在进行中。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH]Harrison，R.，“轻量级目录访问协议（LDAP）：认证方法和安全机制”，RFC 4513，2006年6月。
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[NNTP-COMMON]Barber，S.，“通用NNTP扩展”，RFC 29802000年10月。
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[普通]Zeilenga，K.，Ed.“普通简单认证和安全层（SASL）机制”，RFC4616，2006年8月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]迈尔斯，J.，“POP3认证命令”，RFC 17341994年12月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
Authors' Addresses
作者地址
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853 USA
美国纽约州伊萨卡康奈尔大学厄普森霍尔分校计算机科学系Jeffrey M.Vinocur 14853
EMail: vinocur@cs.cornell.edu
EMail: vinocur@cs.cornell.edu
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
肯尼斯·默奇森卡内基梅隆大学福布斯大道5000号塞尔特大厅美国宾夕法尼亚州匹兹堡285号15213
EMail: murch@andrew.cmu.edu
EMail: murch@andrew.cmu.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。