Network Working Group C. Metz
Request for Comments: 2243 The Inner Net
Category: Standards Track November 1997
Network Working Group C. Metz
Request for Comments: 2243 The Inner Net
Category: Standards Track November 1997
OTP Extended Responses
检察官办公室扩大答复
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 (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Abstract
摘要
This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented.
本文档为OTP[RFC 1938]质询的一种响应类型提供了规范，该质询带有响应编码的明确指示。介绍了使用这种新型响应的两种强制性OTP数据格式的编码。
This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase.
本文档还提供了一个响应规范，允许OTP生成器请求服务器重新初始化序列并更改密码短语等参数。
This document specifies the data formats and software behaviors needed to use OTP extended responses. The data formats are described three ways: using an ad-hoc UNIX manual page style syntax, using augmented BNF described in sections two and three of RFC 822, and by examples. Should there be any conflict between these descriptions, the augmented BNF takes precedence. The software behaviors are described in words, and specific behavior compliance requirements are itemized using the requirements terminology (specifically, the words MUST, SHOULD, and MAY) defined in RFC 2119.
本文件规定了使用OTP扩展响应所需的数据格式和软件行为。数据格式有三种描述方式：使用特别的UNIX手动页面样式语法，使用RFC 822第二节和第三节中描述的扩充BNF，以及通过示例。如果这些描述之间存在任何冲突，则以扩充BNF为准。软件行为用文字描述，具体的行为符合性需求使用RFC 2119中定义的需求术语（特别是“必须”、“应该”和“可以”）逐项列出。
This document builds on the protocol and terminology specified in RFC 1938 and assumes that you have already read this document and understand its contents.
本文件以RFC 1938中规定的协议和术语为基础，假设您已经阅读本文件并理解其内容。
An extended challenge is a single line of printable text terminated by either a new line sequence appropriate for the context of its use (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It contains a standard OTP challenge, a whitespace character, and a list that generators use to determine which extended responses are supported by a server.
扩展挑战是一行可打印文本，以适合其使用上下文的新行序列（例如，ASCII CR后跟ASCII LF）或空白字符结尾。它包含一个标准OTP质询、一个空白字符和一个列表，生成器使用该列表确定服务器支持哪些扩展响应。
An extended response is a single line of printable text terminated by a new line sequence appropriate for the context of its use. It contains two or more tokens that are separated with a single colon (':') character. The first token contains a type specifier that indicates the format of the rest of the response. The tokens that follow are argument data for the OTP extended response. At least one token of data MUST be present.
扩展响应是一行可打印文本，由适合其使用上下文的新行序列终止。它包含两个或多个用单个冒号（“：”）字符分隔的标记。第一个标记包含一个类型说明符，该说明符指示响应其余部分的格式。后面的标记是OTP扩展响应的参数数据。必须至少存在一个数据标记。
In UNIX manual page like syntax, the general form of an extended challenge could be described as:
在UNIX手册类似页面的语法中，扩展质询的一般形式可以描述为：
<standard OTP challenge> ext[,<extension set id>[, ...]]
<standard OTP challenge> ext[,<extension set id>[, ...]]
And the general form of an extended response could be described as:
扩展响应的一般形式可以描述为：
<type-specifier>:<arg1>[:<arg2>[:...]]
<type-specifier>:<arg1>[:<arg2>[:...]]
In augmented BNF syntax, the syntax of the general form of an extended challenge and an extended response is:
在扩充BNF语法中，扩展质询和扩展响应的一般形式的语法为：
extended-challenge = otp-challenge 1*LWSP-char capability-list
(NL / *LWSP-char)
otp-challenge = <a standard OTP challenge>
capability-list = "ext" *("," extension-set-id)
extension-set-id = *<any CHAR except LWSP, CTLs, or ",">
extended-response = type 1*(":" argument) NL
type = token
argument = token
token = 1*<any CHAR except ":" and CTLs>
NL = <new line sequence appropriate for the context
in which OTP is being used>
extended-challenge = otp-challenge 1*LWSP-char capability-list
(NL / *LWSP-char)
otp-challenge = <a standard OTP challenge>
capability-list = "ext" *("," extension-set-id)
extension-set-id = *<any CHAR except LWSP, CTLs, or ",">
extended-response = type 1*(":" argument) NL
type = token
argument = token
token = 1*<any CHAR except ":" and CTLs>
NL = <new line sequence appropriate for the context
in which OTP is being used>
An example of an extended challenge indicating support for OTP extended responses and for a mythical response set "foo" is:
表示支持OTP扩展响应和虚构响应集“foo”的扩展质询示例如下：
otp-md5 123 mi1234 ext,foo
otp-md5 123 mi1234分机，foo
An example of an extended response using a mythical type named "foo" is:
使用名为“foo”的虚构类型的扩展响应示例如下：
foo:some data:some more data:12345
foo:some data:some more data:12345
A server compliant with this specification:
符合此规范的服务器：
1. MUST be able to receive and parse the general form of an extended response 2. MUST be able to receive, parse, and correctly process all extended responses specified in this document 3. MUST process the type field in a case-insensitive manner 4. MUST reject any authentication attempt using an extended response if it does not support that type of response 5. SHOULD provide an appropriate indication to the generator if the response was rejected because of (4) 6. MUST limit the length of the input reasonably 7. MUST accept otherwise arbitrary amounts of whitespace wherever a response allows it 8. MUST be able to receive and correctly process standard OTP responses
1. 必须能够接收和解析扩展响应的一般形式2。必须能够接收、解析并正确处理本文档3中指定的所有扩展响应。必须以不区分大小写的方式处理类型字段4。如果扩展响应不支持该类型的响应，则必须拒绝使用扩展响应的任何身份验证尝试5。如果响应因（4）6而被拒绝，则应向发电机提供适当的指示。必须合理限制输入的长度7。在响应允许的情况下，必须接受任意数量的空格8。必须能够接收并正确处理标准OTP响应
A generator compliant with this specification:
符合本规范的发电机：
1. MUST be able to generate standard OTP responses 2. MUST use standard responses unless an extended challenge has been received for the particular server AND seed 3. MUST generate the type field in lower case 4. MUST NOT send a response type for which the server has not indicated support through an extended challenge
1. 必须能够生成标准OTP响应2。必须使用标准响应，除非已收到特定服务器和种子3的扩展质询。必须以小写4生成类型字段。不得发送服务器未通过扩展质询表示支持的响应类型
Extension set identifiers and extension type identifiers named with the prefix "x-" are reserved for private use among mutually consenting implementations. Implementations that do not recognise a particular "x-" extension MUST ignore that extension. This means that all "x-" extensions are likely to be non-interoperable with other extensions. Careful consideration should be given to the possibility of a server interacting with with a generator implementation which, although it recognizes a given "x-" extension, uses it for a different purpose. All of the remaining extension namespace is reserved to IANA, which will only officially assign the extension
以前缀“x-”命名的扩展集标识符和扩展类型标识符保留给相互同意的实现之间的私人使用。不识别特定“x-”扩展的实现必须忽略该扩展。这意味着所有“x-”扩展都可能无法与其他扩展互操作。应该仔细考虑服务器与生成器实现交互的可能性，该生成器实现虽然可以识别给定的“x-”扩展，但用于不同的目的。所有剩余的扩展名称空间都保留给IANA，IANA只会正式分配扩展
into this namespace after the IESG approves of such an assignment. During the lifetime of the OTP WG, it is recommended that the IESG consult with the OTP WG prior to approving such an assignment.
在IESG批准此类分配后，将其导入此命名空间。在OTP工作组任期内，建议IESG在批准此类转让之前与OTP工作组协商。
There exists a very rare case in which a standard OTP response could be a valid coding in both the hexadecimal and six-word formats. An example of this is the response "ABE ACE ADA ADD BAD A." The solution to this problem mandated by the OTP specification is that compliant servers MUST attempt to parse and verify a standard response in both hexadecimal and six-word formats and must consider the authentication successful if either succeeds.
存在一种非常罕见的情况，即标准OTP响应可以是十六进制和六字格式的有效编码。一个例子是响应“ABE ACE艾达添加坏A”的解决方案，由OTP规范授权的问题是，兼容的服务器必须试图解析和验证标准响应在十六进制和六字格式，必须考虑认证成功，如果一个成功。
This problem can be solved easily using extended responses. The "hex" response and the "word" response are two response types that encode an OTP in an extended response that explicitly describes the encoding. These responses start with a type label of "hex" for a hexadecimal OTP and "word" for a six-word coded OTP. These responses contain one argument field that contains a standard OTP response coded in the indicated format.
使用扩展响应可以很容易地解决这个问题。“十六进制”响应和“字”响应是两种响应类型，它们在显式描述编码的扩展响应中对OTP进行编码。这些响应以十六进制OTP的类型标签“hex”和六字编码OTP的类型标签“word”开始。这些响应包含一个参数字段，该字段包含以指定格式编码的标准OTP响应。
In UNIX manual page like syntax, the format of these responses could be described as:
在UNIX手册类似页面的语法中，这些响应的格式可以描述为：
hex:<hexadecimal number>
word:<six dictionary words>
hex:<hexadecimal number>
word:<six dictionary words>
In augmented BNF syntax and with the definitions already provided, the syntax of these responses is:
在扩展BNF语法中，根据已经提供的定义，这些响应的语法为：
hex-response = "hex:" hex-64bit NL
hex-64bit = 16(hex-char *LWSP-char)
hex-char = ("A" / "B" / "C" / "D" / "E" / "F" /
"a" / "b" / "c" / "d" / "e" / "f" /
"0" / "1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9")
hex-response = "hex:" hex-64bit NL
hex-64bit = 16(hex-char *LWSP-char)
hex-char = ("A" / "B" / "C" / "D" / "E" / "F" /
"a" / "b" / "c" / "d" / "e" / "f" /
"0" / "1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9")
word-response = "word:" word-64bit NL
word-64bit = 6(otp-word 1*LWSP-char)
otp-word = <any valid word in the standard OTP coding
dictionary>
word-response = "word:" word-64bit NL
word-64bit = 6(otp-word 1*LWSP-char)
otp-word = <any valid word in the standard OTP coding
dictionary>
Examples of these responses are:
这些答复的例子如下：
hex:8720 33d4 6202 9172 word:VAST SAUL TAKE SODA SUCH BOLT
十六进制：8720 33d4 6202 9172字：大扫罗拿苏打这样的螺栓
A server compliant with this specification:
符合此规范的服务器：
1. MUST process all arguments in a case-insensitive manner
1. 必须以不区分大小写的方式处理所有参数
A generator compliant with this specification:
符合本规范的发电机：
1. SHOULD generate otp-word tokens in upper case with single spaces separating them 2. SHOULD generate hexadecimal numbers using only lower case for letters
1. 应以大写形式生成otp单词标记，并用单个空格分隔它们2。应仅使用小写字母生成十六进制数字
The OTP specification requires that implementations provide a means for a client to re-initialize or change its OTP information with a server but does not require any specific protocol for doing it. Implementations that support the OTP extended responses described in this document MUST support the response with the "init-hex" and "init-word" type specifiers, which provide a standard way for a client to re-initialize its OTP information with a server. This response is intended to be used only by automated clients. Because of this, the recommended form of this response uses the hexadecimal encoding for binary data. It is possible for a user to type an "init-hex" or "init-word" response.
OTP规范要求实现为客户机提供一种方法，使其能够使用服务器重新初始化或更改其OTP信息，但不需要任何特定的协议。支持本文档中描述的OTP扩展响应的实现必须支持带有“init hex”和“init word”类型说明符的响应，这为客户机使用服务器重新初始化其OTP信息提供了标准方法。此响应仅用于自动客户端。因此，此响应的推荐形式对二进制数据使用十六进制编码。用户可以键入“init hex”或“init word”响应。
In UNIX manual page like syntax, the format of these responses could be described as:
在UNIX手册类似页面的语法中，这些响应的格式可以描述为：
init-hex:<current-OTP>:<new-params>:<new-OTP>
init-word:<current-OTP>:<new-params>:<new-OTP>
init-hex:<current-OTP>:<new-params>:<new-OTP>
init-word:<current-OTP>:<new-params>:<new-OTP>
In augmented BNF syntax and with the definitions already provided, the syntax of the "init-hex" response is:
在扩展BNF语法中，根据已经提供的定义，“init hex”响应的语法为：
init-hex-response = "init-hex:" current-OTP ":" new-params ":"
new-OTP NL
init-hex-response = "init-hex:" current-OTP ":" new-params ":"
new-OTP NL
current-OTP = hex-64bit new-OTP = hex-64bit
当前OTP=十六进制64位新OTP=十六进制64位
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
In augmented BNF syntax and with the definitions already provided, the syntax of the "init-word" response is:
在扩展BNF语法中，根据已经提供的定义，“init word”响应的语法为：
init-word-response = "init-word:" current-OTP ":" new-params ":"
new-OTP NL
init-word-response = "init-word:" current-OTP ":" new-params ":"
new-OTP NL
current-OTP = word-64bit new-OTP = word-64bit
当前OTP=word-64位新OTP=word-64位
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
Note that all appropriate fields for the "init-hex" response MUST be hexadecimally coded and that all appropriate fields for the "init-word" response MUST be six-word coded.
请注意，“init hex”响应的所有适当字段必须采用十六进制编码，“init word”响应的所有适当字段必须采用六个字编码。
Examples of these responses are:
这些答复的例子如下：
init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e
init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e
init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e
init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e
init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235:
ARTY WEAR TAD RUG HALO GIVE
init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235:
BABY FAIN OILY NIL TIDY DADE
init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235:
ARTY WEAR TAD RUG HALO GIVE
init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235:
BABY FAIN OILY NIL TIDY DADE
(Note that all of these responses are one line. Due to their length, they had to be split into multiple lines in order to be included here. These responses MUST NOT span more than one line in actual use)
（请注意，所有这些响应都是一行。由于其长度，必须将其拆分为多行才能包含在此处。这些响应在实际使用中不得跨越多行）
The current-OTP field contains the (RFC 1938) response to the OTP challenge. The new-params field contains the parameters for the client's new requested challenge and the new-OTP field contains a response to that challenge. If the re-initialization is successful, a server MUST store the new OTP in its database as the last successful OTP received and the sequence number in the next challenge presented by the server MUST be one less than the sequence number specified in the new-params field.
当前OTP字段包含对OTP质询的（RFC 1938）响应。新参数字段包含客户端新请求质询的参数，新OTP字段包含对该质询的响应。如果重新初始化成功，服务器必须将新OTP作为最后一个成功接收的OTP存储在其数据库中，并且服务器提交的下一个质询中的序列号必须比新参数字段中指定的序列号少一个。
The new-params field is hashed as a string the same way that a seed or secret pass phrase would be. All other field values are hashed in their uncoded binary forms, in network byte order and without any padding.
新的params字段被散列为字符串，散列方式与种子或密码短语相同。所有其他字段值都以未编码的二进制形式进行散列，以网络字节顺序进行，并且没有任何填充。
A server compliant with this specification:
符合此规范的服务器：
1. SHOULD NOT allow a user to use the same value for their seed and secret pass phrase. 2. MUST disable all OTP access to any principal whose sequence number would be less than one 3. MUST decrement the sequence number if a reinitialization response includes a valid current-OTP, but the server is unable to successfully process the new-params or new-OTP for any reason.
1. 不应允许用户对其种子和密码短语使用相同的值。2.必须禁用对序列号小于1 3的任何主体的所有OTP访问。如果重新初始化响应包含有效的当前OTP，但服务器由于任何原因无法成功处理新参数或新OTP，则必须减少序列号。
A generator compliant with this specification:
符合本规范的发电机：
1. SHOULD NOT allow a user to use the same value for their seed and secret pass phrase 2. MUST take specific steps to prevent infinite loops of re-initialization attempts in case of failure 3. SHOULD provide the user with some indication that the re-initialization is taking place 4. SHOULD NOT do a re-initialization without the user's permission, either for that specific instance or as a configuration option 5. SHOULD NOT retry a failed re-initialization without a user's permission 6. SHOULD warn the user if the sequence number falls below ten 7. MUST refuse to generate OTPs with a sequence number below one
1. 不应允许用户对其种子和密码短语2使用相同的值。必须采取特定步骤，以防止在出现故障3时出现无限次的重新初始化尝试循环。应向用户提供重新初始化正在进行的一些指示4。未经用户许可，不得对该特定实例或作为配置选项5重新初始化。未经用户许可，不应重试失败的重新初始化6。如果序列号低于10 7，则应警告用户。必须拒绝生成序列号低于1的OTP
All of the security considerations for the OTP system also apply to the OTP system with extended responses.
OTP系统的所有安全注意事项也适用于具有扩展响应的OTP系统。
These extended responses, like OTP itself, do not protect the user against active attacks. The IPsec Authentication Header (RFC-1826) (or another technique with at least as much strength as IPsec AH) SHOULD be used to protect against such attacks.
这些扩展响应与OTP本身一样，不能保护用户免受主动攻击。应使用IPsec身份验证头（RFC-1826）（或至少与IPsec AH具有同等强度的另一种技术）来防止此类攻击。
The consequences of a successful active attack on the re-initialization response may be more severe than simply hijacking a single session. An attacker could substitute his own response for
成功主动攻击重新初始化响应的后果可能比劫持单个会话更严重。攻击者可以用自己的反应代替
that of a legitimate user. The attacker may then be able to use the OTP system to authenticate himself as the user at will (at least until detected).
合法用户的身份。然后，攻击者可以随意使用OTP系统将自己验证为用户（至少在检测到之前）。
Failure to implement server requirement 3 in section 4.3 opens an implementation to an attack based on replay of the current-OTP part of the response.
如果未能实现第4.3节中的服务器要求3，则会根据响应中当前OTP部分的重播，使实现面临攻击。
Like RFC 1938, the protocol described in this document was created by contributors in the IETF OTP working group. Specific contributions were made by Neil Haller, who provided input on the overall design requirements of a re-initialization protocol, Denis Pinkas, who suggested several modifications to the originally proposed re-initialization protocol, and Phil Servita, who opened the debate with the first real protocol proposal and provided lots of specific input on the design of this and earlier protocols. The extensions to the OTP challenge were suggested by Chris Newman and John Valdes.
与RFC1938一样，本文件中描述的协议由IETF OTP工作组的贡献者创建。尼尔·哈勒（Neil Haller）对重新初始化协议的总体设计要求提供了意见，丹尼斯·平卡斯（Denis Pinkas）对最初提出的重新初始化协议提出了几项修改建议，菲尔·塞维塔（Phil Servita）也做出了具体贡献，世卫组织以第一个真正的协议提案开始了辩论，并就本协议和早期协议的设计提供了大量的具体投入。Chris Newman和John Valdes建议延长OTP挑战。
Randall Atkinson and Ted T'so also contributed their views to discussions about details of the protocol extensions in this document.
Randall Atkinson和Ted T'so也在本文中对协议扩展的细节进行了讨论。
References
工具书类
[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages," RFC 822, August 1982.
[RFC 822]Crocker，D.，“ARPA互联网文本消息格式标准”，RFC 822，1982年8月。
[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol," RFC 1825, August 1995.
[RFC 1825]阿特金森，R.，“互联网协议的安全架构”，RFC 18251995年8月。
[RFC 1938] Haller, N. and C. Metz, "A One-Time Password System," RFC 1938, May 1996.
[RFC 1938]Haller，N.和C.Metz，“一次性密码系统”，RFC 1938，1996年5月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level," RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，1997年3月。
Author's Address
作者地址
Craig Metz The Inner Net Box 10314-1936 Blacksburg, VA 24062-0314 (DSN) 354-8590 cmetz@inner.net
克雷格·梅茨内网信箱10314-1936弗吉尼亚州布莱克斯堡24062-0314（DSN）354-8590cmetz@inner.net
Appendix: Reference Responses
附录：参考回复
The following responses were generated by a development version of the One-Time Passwords in Everything (OPIE) implementation of this specification.
以下响应由本规范的所有内容（OPIE）中一次性密码的开发版本生成。
All of these are responses to the challenge:
所有这些都是对挑战的回应：
otp-md5 499 ke1234 ext
otp-md5 499 ke1234分机
Note that the re-initialization responses use the same secret pass phrase for new and current and a new seed of "ke1235". Also, these responses have been split for formatting purposes into multiple lines; they MUST NOT be multiple lines in actual use.
请注意，重新初始化响应对new和current以及新种子“ke1235”使用相同的密码短语。此外，出于格式化目的，这些响应被拆分为多行；它们在实际使用中不得为多行。
The secret pass phrase for these responses is:
这些回答的秘诀是：
This is a test.
这是一个测试。
The OTP standard hexadecimal response is:
OTP标准十六进制响应为：
5bf0 75d9 959d 036f
5bf0 75d9 959d 036f
The OTP standard six-word response is:
OTP标准六字回复为：
BOND FOGY DRAB NE RISE MART
邦德·福吉·德拉布东北商业街
The OTP extended "hex" response is:
OTP扩展的“十六进制”响应为：
hex:5Bf0 75d9 959d 036f
六角：5Bf0 75d9 959d 036f
The OTP extended "word" response is:
检察官办公室扩展的“word”答复是：
word:BOND FOGY DRAB NE RISE MART
单词：邦德·福吉·德拉布·内瑞斯·玛特
The OTP extended "init-hex" response is:
OTP扩展的“初始十六进制”响应为：
init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1
init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1
The OTP extended "init-word" response is:
OTP扩展的“初始化字”响应为：
init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235: RED HERD NOW BEAN PA BURG
初始单词：邦德·福吉·德拉布东北崛起商业城：md5 499 ke1235：红牛群现在是比恩·巴堡
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。