Network Working Group M. Nystrom
Request for Comments: 2808 RSA Laboratories
Category: Informational April 2000
Network Working Group M. Nystrom
Request for Comments: 2808 RSA Laboratories
Category: Informational April 2000
The SecurID(r) SASL Mechanism
SecurID（r）SASL机制
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
SecurID是RSA Security Inc.生产的用于最终用户身份验证的硬件令牌卡产品（或其软件仿真）。本文档定义了使用这些令牌的SASL[RFC2222]身份验证机制，从而提供了在SASL环境中使用这些令牌的方法。此机制仅用于身份验证，对协议编码没有影响，并且不用于提供完整性或机密性服务。
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.
本备忘录假设读者基本熟悉SecurID令牌、其关联的身份验证协议和SASL。
How to read this document
如何阅读此文档
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this document are to be interpreted as defined in [RFC2119].
本文件中的关键词“必须”、“不得”、“应”、“应”和“可”应按照[RFC2119]中的定义进行解释。
In examples, "C:" and "S:" indicate messages sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的消息。
The SECURID SASL mechanism is a good choice for usage scenarios where a client, acting on behalf of a user, is untrusted, as a one-time passcode will only give the client a single opportunity to act maliciously. This mechanism provides authentication only.
对于代表用户的客户端不受信任的使用场景，SECURID SASL机制是一个不错的选择，因为一次性密码只会给客户端一次恶意操作的机会。此机制仅提供身份验证。
The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 [RFC2251].
SECURID SASL机制提供了一种将现有SECURID身份验证方法集成到支持SASL的协议中的正式方法，这些协议包括IMAP[RFC2060]、ACAP[RFC2244]、POP3[RFC1734]和LDAPv3[RFC2251]。
The SECURID SASL mechanism provides two-factor based user authentication as defined below.
SECURID SASL机制提供以下定义的基于两个因素的用户身份验证。
There are basically three entities in the authentication mechanism described here: A user, possessing a SecurID token, an application server, to which the user wants to connect, and an authentication server, capable of authenticating the user. Even though the application server in practice may function as a client with respect to the authentication server, relaying authentication credentials etc. as needed, both servers are, unless explicitly mentioned, collectively termed "the server" here. The protocol used between the application server and the authentication server is outside the scope of this memo. The application client, acting on behalf of the user, is termed "the client".
这里描述的身份验证机制中基本上有三个实体：拥有SecurID令牌的用户、用户希望连接到的应用程序服务器和能够对用户进行身份验证的身份验证服务器。尽管实际上应用服务器可以作为认证服务器的客户端，根据需要中继认证凭证等，但除非明确提及，否则这两个服务器在这里统称为“服务器”。应用程序服务器和身份验证服务器之间使用的协议不在本备忘录的范围内。代表用户的应用程序客户端称为“客户端”。
The mechanism is based on the use of a shared secret key, or "seed", and a personal identification number (PIN), which is known both by the user and the authentication server. The secret seed is stored on a token that the user possesses, as well as on the authentication server. Hence the term "two-factor authentication", a user needs not only physical access to the token but also knowledge about the PIN in order to perform an authentication. Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is generated by the user's token and sent to the server.
该机制基于使用共享密钥或“种子”以及用户和认证服务器都知道的个人标识号（PIN）。秘密种子存储在用户拥有的令牌以及身份验证服务器上。因此，术语“双因素认证”，用户不仅需要对令牌的物理访问，还需要关于PIN的知识，以便执行认证。给定种子、当前时间和PIN，用户的令牌将生成“密码（r）”并发送到服务器。
The SECURID SASL mechanism provides one service:
SECURID SASL机制提供一种服务：
- User authentication where the user provides information to the server, so that the server can authenticate the user.
- 用户身份验证，其中用户向服务器提供信息，以便服务器可以对用户进行身份验证。
This mechanism is identified with the SASL key "SECURID".
该机制由SASL密钥“SECURID”标识。
a) The client generates the credentials using local information (seed, current time and user PIN/password).
a) 客户端使用本地信息（种子、当前时间和用户PIN/密码）生成凭据。
b) If the underlying protocol permits, the client sends credentials to the server in an initial response message. Otherwise, the client sends a request to the server to initiate the authentication mechanism, and sends credentials after the server's response (see [RFC2222] section 5.1 for more information regarding the initial response option).
b) 如果基础协议允许，客户端将在初始响应消息中向服务器发送凭据。否则，客户端将向服务器发送请求以启动身份验证机制，并在服务器响应后发送凭据（有关初始响应选项的更多信息，请参阅[RFC2222]第5.1节）。
Unless the server requests a new PIN (see below), the contents of the client's initial response SHALL be as follows:
除非服务器请求新PIN码（见下文），否则客户端的初始响应内容应如下所示：
(1) An authorization identity. When this field is empty, it defaults to the authentication identity. This field MAY be used by system administrators or proxy servers to login with a different user identity. This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded [RFC2279] printable characters only (US-ASCII [X3.4] is a subset of UTF-8).
(1) 授权标识。此字段为空时，默认为身份验证标识。系统管理员或代理服务器可以使用此字段以不同的用户身份登录。该字段的长度不得超过255个八位字节，以NUL（0）个八位字节结尾，并且必须仅由UTF-8编码的[RFC2279]可打印字符组成（US-ASCII[X3.4]是UTF-8的子集）。
(2) An authentication identity. The identity whose passcode will be used. If this field is empty, it is assumed to have been transferred by other means (e.g. if the underlying protocol has support for this, like [RFC2251]). This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only.
(2) 身份验证标识。将使用其密码的标识。如果此字段为空，则假定已通过其他方式传输（例如，如果基础协议对此有支持，如[RFC2251]）。此字段的长度不得超过255个八位字节，以NUL（0）个八位字节结尾，并且必须仅由UTF-8编码的可打印字符组成。
(3) A passcode. The one-time password that will be used to grant access. This field MUST NOT be shorter than 4 octets, MUST NOT be longer than 32 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only. Passcodes usually consist of 4-8 digits.
(3) 密码。将用于授予访问权限的一次性密码。该字段不得短于4个八位字节，不得长于32个八位字节，应以NUL（0）个八位字节结尾，且必须仅由UTF-8编码的可打印字符组成。密码通常由4-8位数字组成。
The ABNF [RFC2234] form of this message is as follows:
此消息的ABNF[RFC2234]格式如下：
credential-pdu = authorization-id authentication-id passcode [pin]
凭证pdu=授权id身份验证id密码[pin]
authorization-id = 0*255VUTF8 %x00
授权id=0*255VUTF8%x00
authentication-id = 0*255VUTF8 %x00
身份验证id=0*255VUTF8%x00
passcode = 4*32VUTF8 %x00
密码=4*32VUTF8%x00
pin ::= 4*32VUTF8 %x00
pin ::= 4*32VUTF8 %x00
VUTF8 = <Visible (printable) UTF8-encoded characters>
VUTF8 = <Visible (printable) UTF8-encoded characters>
Regarding the <pin> rule, see d) below.
关于<pin>规则，见下文d）。
c) The server verifies these credentials using its own information. If the verification succeeds, the server sends back a response indicating success to the client. After receiving this response, the client is authenticated. Otherwise, the verification either failed or the server needs an additional set of credentials from the client in order to authenticate the user.
c) 服务器使用自己的信息验证这些凭据。如果验证成功，服务器将向客户端发回一个指示成功的响应。收到此响应后，客户端将进行身份验证。否则，验证将失败，或者服务器需要来自客户端的一组附加凭据才能对用户进行身份验证。
d) If the server needs an additional set of credentials, it requests them now. This request has the following format, described in ABNF notation:
d) 如果服务器需要一组额外的凭据，它会立即请求这些凭据。此请求采用ABNF符号中描述的以下格式：
server-request = passcode | pin
服务器请求=密码| pin
passcode = "passcode" %x00
passcode=“passcode”%x00
pin = "pin" %x00 [suggested-pin]
pin=“pin”%x00[建议的pin]
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
The 'passcode' choice will be sent when the server requests another passcode. The 'pin' choice will be sent when the server requests a new user PIN. The server will either send an empty string or suggest a new user PIN in this message.
当服务器请求另一个密码时，将发送“密码”选项。“pin”选项将在服务器请求新用户pin时发送。服务器将在此消息中发送空字符串或建议新用户PIN。
e) The client generates a new set of credentials using local information and depending on the server's request and sends them to the server. Authentication now continues as in c) above.
e) 客户端使用本地信息并根据服务器的请求生成一组新凭据，并将其发送到服务器。身份验证现在继续进行，如上文c）所述。
Note 1: Case d) above may occur e.g. when the clocks on which the server and the client relies are not synchronized.
注1：上述情况d）可能发生，例如，当服务器和客户端所依赖的时钟不同步时。
Note 2: If the server requests a new user PIN, the client MUST respond with a new user PIN (together with a passcode), encoded as a UTF-8 string. If the server supplies the client with a suggested PIN, the client accepts this by replying with the same PIN, but MAY replace it with another one. The length of the PIN is application-dependent as are any other requirements for the PIN, e.g. allowed characters. If the server for some reason does not accept the received PIN, the client MUST be prepared to receive either a message indicating the failure of the authentication or a repeated request for a new PIN. Mechanisms for transferring knowledge about PIN requirements from the server to the client are outside the scope of this memo. However, some information MAY be provided in error messages transferred from the server to the client when applicable.
注2：如果服务器请求一个新的用户PIN，客户端必须用一个新的用户PIN（连同一个密码）响应，该PIN编码为UTF-8字符串。如果服务器向客户机提供建议的PIN，客户机将通过使用相同的PIN进行回复来接受该PIN，但可以使用另一个PIN进行替换。PIN的长度取决于应用，PIN的任何其他要求（例如允许的字符）也取决于应用。如果服务器出于某种原因不接受收到的PIN，则客户端必须准备好接收指示身份验证失败的消息或重复请求新PIN的消息。将有关PIN要求的知识从服务器传输到客户端的机制不在本备忘录的范围内。但是，如果适用，可以在从服务器传输到客户端的错误消息中提供一些信息。
The following example shows the use of the SECURID SASL mechanism with IMAP4. The example is only designed to illustrate the protocol interaction but do provide valid encoding examples.
下面的示例显示了在IMAP4中使用SECURID SASL机制。该示例仅用于说明协议交互，但提供了有效的编码示例。
The base64 encoding of the last client response, as well as the "+ " preceding the response, is part of the IMAP4 profile, and not a part of this specification itself.
最后一个客户端响应的base64编码以及响应前的“+”是IMAP4配置文件的一部分，而不是本规范本身的一部分。
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID
S: A001 OK done
C: A002 AUTHENTICATE SECURID
S: +
C: AG1hZ251cwAxMjM0NTY3OAA=
S: A002 OK Welcome, SECURID authenticated user: magnus
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID
S: A001 OK done
C: A002 AUTHENTICATE SECURID
S: +
C: AG1hZ251cwAxMjM0NTY3OAA=
S: A002 OK Welcome, SECURID authenticated user: magnus
The following examples show the use of the SECURID SASL mechanism with LDAPv3. The examples are only designed to illustrate the protocol interaction, but do provide valid encoding examples. Usernames, passcodes and PINs are of course fictitious. For readability, all messages are shown in the value-notation defined in [X680]. <credential-pdu> values are shown hex-encoded in the 'credentials' field of LDAP's 'BindRequest' and <server-request> values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's 'BindResponse'.
以下示例显示了将SECURID SASL机制与LDAPv3结合使用。这些示例仅用于说明协议交互，但确实提供了有效的编码示例。用户名、密码和PIN码当然是虚构的。为便于阅读，所有消息均以[X680]中定义的值表示法显示<凭证pdu>值在LDAP的“BindRequest”的“credentials”字段中显示为十六进制编码，<server request>值在LDAP的“BindResponse”的“ServersAllCreds”字段中显示为十六进制编码。
Initial response message, successful authentication.
初始响应消息，验证成功。
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
Initial response message, server requires second passcode.
初始响应消息，服务器需要第二个密码。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70617373636f646500'H
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70617373636f646500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300383736353433323100'H
}
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300383736353433323100'H
}
}
}
S: { messageID 1,
S:{messageID 1，
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
Initial response message, server requires new PIN and passcode, and supplies client with a suggested new PIN (which the client accepts).
初始响应消息，服务器需要新的PIN和密码，并向客户端提供建议的新PIN（客户端接受）。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70696e006b616c6c6500'H
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70696e006b616c6c6500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e7573003837343434363734006b616c6c6500'H
}
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e7573003837343434363734006b616c6c6500'H
}
}
}
S: { messageID 1,
S:{messageID 1，
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
This mechanism only provides protection against passive eavesdropping attacks. It does not provide session privacy, server authentication or protection from active attacks. In particular, man-in-the-middle attacks, were an attacker acts as an application server in order to acquire a valid passcode are possible.
此机制仅针对被动窃听攻击提供保护。它不提供会话隐私、服务器身份验证或主动攻击保护。特别是中间人攻击，即攻击者充当应用程序服务器以获取有效密码是可能的。
In order to protect against such attacks, the client SHOULD make sure that the server is properly authenticated. When user PINs are transmitted, user authentication SHOULD take place on a server-authenticated and confidentiality-protected connection.
为了防止此类攻击，客户端应确保服务器已正确验证。当传输用户PIN时，用户身份验证应在经过身份验证且受保密保护的服务器连接上进行。
Server implementations MUST protect against replay attacks, since an attacker could otherwise gain access by replaying a previous, valid request. Clients MUST also protect against replay of PIN-change messages.
服务器实现必须防止重播攻击，因为攻击者可以通过重播以前的有效请求来获得访问权限。客户端还必须防止PIN更改消息重播。
It is possible for an attacker to listen to most of a passcode, guess the remainder, and then race the legitimate user to complete the authentication. As for OTP [RFC2289], conforming server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [RFC2289]; implementations MAY use this approach or MAY select an alternative defense.
攻击者可能会侦听大部分密码，猜测剩余密码，然后与合法用户竞争以完成身份验证。对于OTP[RFC2289]，一致性服务器实现必须针对这种竞争条件进行保护。针对这种攻击的一种防御措施概述如下，并借鉴了[RFC2289]；实施可以使用这种方法，也可以选择替代防御。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial of service attack.
一种可能的防御措施是防止用户同时启动多个身份验证会话。这意味着，一旦合法用户启动了身份验证，攻击者将被阻止，直到第一个身份验证过程完成。在这种方法中，需要超时来阻止拒绝服务攻击。
By registering the SecurID protocol as a SASL mechanism, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SECURID SASL mechanism:
通过将SecurID协议注册为SASL机制，实现者将有一种定义良好的方式将此身份验证机制添加到他们的产品中。以下是SECURID SASL机制的注册模板：
SASL mechanism name: SECURID Security Considerations: See corresponding section of this memo Published specification: This memo Person & email address to contact for further information: See author's address section below Intended usage: COMMON Author/Change controller: See author's address section below
SASL机制名称：SECURID安全注意事项：参见本备忘录发布规范的相应部分：本备忘录联系人和电子邮件地址以了解更多信息：参见下面的作者地址部分预期用途：通用作者/变更控制者：参见下面的作者地址部分
RSA Security Inc. does not make any claims on the general constructions described in this memo, although underlying techniques may be covered. Among the underlying techniques, the SecurID technology is covered by a number of US patents (and foreign counterparts), in particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
RSA Security Inc.不对本备忘录中所述的一般结构提出任何索赔，尽管可能涉及底层技术。在基础技术中，SecurID技术包括许多美国专利（以及国外专利），特别是美国专利号4885778、5097505、5168520和5657388。
SecurID is a registered trademark, and PASSCODE is a trademark, of RSA Security Inc.
SecurID是RSA Security Inc.的注册商标，Password是其商标。
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734]迈尔斯，J.，“POP3认证命令”，RFC17341994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC20601996年12月。
[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月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222]迈尔斯，J.，“简单认证和安全层”，RFC22221997年10月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC2244，1997年11月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[RFC2289]Haller，N.，Metz，C.，Nesser，P.和M.Straw，“一次性密码系统”，RFC 2289，1998年2月。
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)," American National Standards Institute.
[X3.4]ANSI，“ANSI X3.4：信息系统-编码字符集-信息交换用7位美国国家标准代码（7位ASCII）”，美国国家标准协会。
[X680] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation," International Telecommunication Union, 1997.
[X680]ITU-T，“信息技术-抽象语法符号1（ASN.1）：基本符号规范”，国际电信联盟，1997年。
The author gratefully acknowledges the contributions of various reviewers of this memo, in particular the ones from John Myers. They have significantly clarified and improved the utility of this specification.
作者衷心感谢本备忘录各评论员的贡献，特别是约翰·迈尔斯的贡献。他们极大地澄清和改进了本规范的实用性。
Magnus Nystrom RSA Laboratories Box 10704 121 29 Stockholm Sweden
瑞典斯德哥尔摩Magnus Nystrom RSA实验室信箱10704 121 29
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.com
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。