Network Working Group R. Housley
Request for Comments: 2943 T. Horting
Category: Standards Track P. Yee
SPYRUS
September 2000
Network Working Group R. Housley
Request for Comments: 2943 T. Horting
Category: Standards Track P. Yee
SPYRUS
September 2000
TELNET Authentication Using DSA
使用DSA的TELNET身份验证
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA) [FIPS186]. It relies on the Telnet Authentication Option [RFC2941].
本文档定义了使用数字签名算法（DSA）的telnet身份验证机制[FIPS186]。它依赖于Telnet身份验证选项[RFC2941]。
AUTHENTICATION 37
认证37
Authentication Commands:
身份验证命令：
IS 0 SEND 1 REPLY 2 NAME 3
是0发送1回复2名称3
Authentication Types:
身份验证类型：
DSS 14
决策支持系统14
Modifiers:
修改器：
AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO CLIENT 1
身份验证用户掩码1身份验证客户端到服务器0身份验证服务器到客户端1
AUTH_HOW_MASK 2 AUTH_HOW_ONE_WAY 0 AUTH_HOW_MUTUAL 2
验证方式掩码2验证方式单向0验证方式双向2
ENCRYPT_MASK 20 ENCRYPT_OFF 0 ENCRYPT_USING_TELOPT 4 ENCRYPT_AFTER_EXCHANGE 16 ENCRYPT_RESERVED 20
加密\u掩码20加密\u关闭0使用\u TELOPT 4加密\u交换后16加密\u保留20
INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0 INI_CRED_FWD_ON 8
这张面具8张，这张面具关闭了0张，这张面具打开了8张
Sub-option Commands:
子选项命令：
DSS_INITIALIZE 1 DSS_TOKENBA 2 DSS_CERTA_TOKENAB 3 DSS_CERTB_TOKENBA2 4
DSS\U初始化1 DSS\U令牌2 DSS\U证书\U令牌3 DSS\U证书\U令牌2 4
TELNET, as a protocol, has no concept of security. Without negotiated options, it merely passes characters back and forth between the NVTs represented by the two TELNET processes. In its most common usage as a protocol for remote terminal access (TCP port 23), TELNET connects to a server that requires user-level authentication through a user name and password in the clear; the server does not authenticate itself to the user.
TELNET作为一种协议，没有安全概念。在没有协商选项的情况下，它只是在两个TELNET进程所代表的NVT之间来回传递字符。作为远程终端访问协议（TCP端口23），TELNET最常见的用途是连接到需要通过明文用户名和密码进行用户级身份验证的服务器；服务器不向用户进行自身身份验证。
The TELNET Authentication Option provides for user authentication and server authentication. User authentication replaces or augments the normal host password mechanism. Server authentication is normally done in conjunction with user authentication.
TELNET身份验证选项提供用户身份验证和服务器身份验证。用户身份验证取代或增强了正常的主机密码机制。服务器身份验证通常与用户身份验证一起完成。
In order to support these security services, the two TELNET entities must first negotiate their willingness to support the TELNET Authentication Option. Upon agreeing to support this option, the parties are then able to perform sub-option negotiations to the authentication protocol to be used, and possibly the remote user name to be used for authorization checking.
为了支持这些安全服务，两个TELNET实体必须首先协商其支持TELNET身份验证选项的意愿。在同意支持该选项后，各方随后能够对要使用的认证协议以及可能用于授权检查的远程用户名执行子选项协商。
Authentication and parameter negotiation occur within an unbounded series of exchanges. The server proposes a preference-ordered list of authentication types (mechanisms) which it supports. In addition to listing the mechanisms it supports, the server qualifies each mechanism with a modifier that specifies whether the authentication
身份验证和参数协商发生在一系列无界的交换中。服务器提出了一个它支持的按优先顺序排列的身份验证类型（机制）列表。除了列出它支持的机制外，服务器还使用一个修饰符来限定每个机制，该修饰符指定身份验证
is to be one-way or mutual, and in which direction the authentication is to be performed. The client selects one mechanism from the list and responds to the server indicating its choice and the first set of authentication data needed for the selected authentication type. The server and the client then proceed through whatever number of iterations are required to arrive at the requested authentication.
是单向的还是双向的，以及在哪个方向执行身份验证。客户端从列表中选择一种机制，并响应服务器，指示其选择以及所选身份验证类型所需的第一组身份验证数据。然后，服务器和客户机继续进行任何次数的迭代，以达到请求的身份验证。
DSA is also known as the Digital Signature Standard (DSS), and the names are used interchangeably. This paper specifies a method in which DSA may be used to achieve certain security services when used in conjunction with the TELNET Authentication Option. SHA-1 [FIPS180-1] is used with DSA [FIPS186].
DSA也称为数字签名标准（DSS），名称可以互换使用。本文指定了一种方法，在与TELNET身份验证选项结合使用时，可以使用DSA来实现某些安全服务。SHA-1[FIPS180-1]与DSA[FIPS186]一起使用。
DSA may provide either unilateral or mutual authentication. Due to TELNET's character-by-character nature, it is not well-suited to the application of integrity-only services, therefore use of the DSA profile provides authentication but it does not provide session integrity. This specification follows the token and exchanges defined in NIST FIPS PUB 196 [FIPS196], Standard for Public Key Cryptographic Entity Authentication Mechanisms including Appendix A on ASN.1 encoding of messages and tokens. All data that is covered by a digital signature must be encoded using the Distinguished Encoding Rules (DER). However, other data may use either the Basic Encoding Rules (BER) or DER [X.208].
DSA可以提供单边或相互身份验证。由于TELNET的逐字符特性，它不太适合仅完整性服务的应用，因此使用DSA配置文件提供身份验证，但不提供会话完整性。本规范遵循NIST FIPS PUB 196[FIPS196]中定义的令牌和交换，即公钥加密实体认证机制标准，包括ASN.1消息和令牌编码附录A。数字签名包含的所有数据必须使用可分辨编码规则（DER）进行编码。然而，其他数据可以使用基本编码规则（BER）或DER[X.208]。
Unilateral authentication must be done client-to-server. What follows are the protocol steps necessary to perform DSA authentication as specified in FIPS PUB 196 under the TELNET Authentication Option framework. Where failure modes are encountered, the return codes follow those specified in the TELNET Authentication Option. They are not enumerated here, as they are invariant among the mechanisms used. FIPS PUB 196 employs a set of exchanges that are transferred to provide authentication. Each exchange employs various fields and tokens, some of which are optional. In addition, each token has several subfields that are optional. A conformant subset of the fields and subfields have been selected. The tokens are ASN.1 encoded as defined in Appendix A of FIPS PUB 196, and each token is named to indicate the direction in which it flows (e.g., TokenBA flows from Party B to Party A). All data that is covered by a digital signature must be encoded using the
单边身份验证必须在客户端到服务器之间进行。以下是在TELNET身份验证选项框架下执行FIPS PUB 196中指定的DSA身份验证所需的协议步骤。在遇到故障模式时，返回代码遵循TELNET身份验证选项中指定的返回代码。这里不列举它们，因为它们在所使用的机制中是不变的。FIPS PUB 196使用一组交换，这些交换被传输以提供身份验证。每个交换使用各种字段和令牌，其中一些是可选的。此外，每个令牌都有几个可选的子字段。已选择字段和子字段的共形子集。令牌按照FIPS PUB 196附录A中的定义进行ASN.1编码，每个令牌的命名表明其流动方向（例如，令牌BA从乙方流向甲方）。数字签名包含的所有数据必须使用
Distinguished Encoding Rules (DER). Data that is not covered by a digital signature may use either the Basic Encoding Rules (BER) or DER [X.208]. Figure 1 illustrates the exchanges for unilateral authentication.
区分编码规则（DER）。数字签名未涵盖的数据可以使用基本编码规则（BER）或DER[X.208]。图1说明了单向身份验证的交换。
During authentication, the client may provide the user name to the server by using the authentication name sub-option. If the name sub-option is not used, the server will generally prompt for a name and password in the clear. The name sub-option must be sent after the server sends the list of authentication types supported and before the client finishes the authentication exchange, this ensures that the server will not prompt for a user name and password. In figure 1, the name sub-option is sent immediately after the server presents the list of authentication types supported.
在身份验证期间，客户端可以通过使用“身份验证名称”子选项向服务器提供用户名。如果未使用name子选项，服务器通常会在clear中提示输入名称和密码。name子选项必须在服务器发送支持的身份验证类型列表之后和客户端完成身份验证交换之前发送，这确保服务器不会提示输入用户名和密码。在图1中，name子选项在服务器显示支持的身份验证类型列表后立即发送。
For one-way DSS authentication, the two-octet authentication type pair is DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF. This indicates that the DSS authentication mechanism will be used to authenticate the client to the server and that no encryption will be performed.
对于单向DSS身份验证，两个八位组身份验证类型对是DSS身份验证客户端到服务器、身份验证方式单向、加密关闭、INI创建关闭。这表示DSS身份验证机制将用于向服务器验证客户端，并且不会执行加密。
CertA is the clients certificate. Both certificates are X.509 certificates that contain DSS public keys[RFC2459]. The client must validate the server's certificate before using the DSA public key it contains.
CertA是客户端证书。这两个证书都是包含DSS公钥[RFC2459]的X.509证书。客户端必须先验证服务器的证书，然后才能使用其包含的DSA公钥。
Within the unbounded authentication exchange, implementation is greatly simplified if each portion of the exchange carries a unique identifier. For this reason, a single octet sub-option identifier is carried immediately after the two-octet authentication type pair.
在无界身份验证交换中，如果交换的每个部分都带有唯一标识符，则实现将大大简化。因此，在两个八位字节认证类型对之后立即携带一个八位字节子选项标识符。
The exchanges detailed in Figure 1 below presume knowledge of FIPS PUB 196 and the TELNET Authentication Option. The client is Party A, while the server is Party B. At the end of the exchanges, the client is authenticated to the server.
下面图1中详述的交换假定了解FIPS PUB 196和TELNET身份验证选项。客户端是甲方，而服务器是乙方。在交换结束时，客户端通过服务器的身份验证。
------------------------------------------------------------------
Client (Party A) Server (Party B)
------------------------------------------------------------------
Client (Party A) Server (Party B)
<-- IAC DO AUTHENTICATION
<--IAC DO身份验证
IAC WILL AUTHENTICATION -->
IAC将进行身份验证-->
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<--IAC SB身份验证发送<身份验证选项列表>IAC SE
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION IS DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_INITIALIZE IAC SE -->
IAC SB身份验证是DSS身份验证客户端到服务器身份验证方式单向加密关闭INI创建关闭DSS初始化IAC SE-->
<-- IAC SB AUTHENTICATION REPLY DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_TOKENBA Sequence( TokenID, TokenBA ) IAC SE
<--IAC SB身份验证回复DSS身份验证客户端到服务器身份验证方式单向加密关闭INI创建密码关闭DSS令牌序列（令牌ID，令牌BA）IAC SE
IAC SB AUTHENTICATION IS
DSS
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_ONE_WAY |
ENCRYPT_OFF |
INI_CRED_FWD_OFF
DSS_CERTA_TOKENAB
Sequence( TokenID, CertA, TokenAB )
IAC SE -->
------------------------------------------------------------------
Figure 1
IAC SB AUTHENTICATION IS
DSS
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_ONE_WAY |
ENCRYPT_OFF |
INI_CRED_FWD_OFF
DSS_CERTA_TOKENAB
Sequence( TokenID, CertA, TokenAB )
IAC SE -->
------------------------------------------------------------------
Figure 1
Mutual authentication is slightly more complex. Figure 2 illustrates the exchanges.
相互认证稍微复杂一些。图2显示了这些交换。
For mutual DSS authentication, the two-octet authentication type pair is DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF. This indicates that the DSS authentication mechanism will be used to mutually authenticate the client and the server and that no encryption will be performed.
对于双向DSS身份验证，两个八位字节身份验证类型对为DSS身份验证客户端到服务器、身份验证方式、相互加密关闭、INI创建关闭。这表示DSS身份验证机制将用于对客户端和服务器进行相互身份验证，并且不会执行加密。
---------------------------------------------------------------------
Client (Party A) Server (Party B)
---------------------------------------------------------------------
Client (Party A) Server (Party B)
IAC WILL AUTHENTICATION -->
IAC将进行身份验证-->
<-- IAC DO AUTHENTICATION
<--IAC DO身份验证
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<--IAC SB身份验证发送<身份验证选项列表>IAC SE
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION IS DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_INITIALIZE IAC SE -->
IAC SB身份验证是DSS身份验证客户端到服务器身份验证如何相互加密关闭DSS初始化IAC SE-->
<-- IAC SB AUTHENTICATION REPLY DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_TOKENBA Sequence( TokenID, TokenBA ) IAC SE
<--IAC SB身份验证回复DSS身份验证客户端到服务器身份验证如何相互加密关闭INI创建关闭DSS令牌序列（令牌ID，令牌BA）IAC SE
Client (Party A) Server (Party B)
客户端（甲方）服务器（乙方）
IAC SB AUTHENTICATION IS DSS AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_CERTA_TOKENAB Sequence( TokenID, CertA, TokenAB ) IAC SE -->
IAC SB身份验证是DSS身份验证客户端到服务器身份验证方式相互加密关闭INI认证关闭DSS证书令牌AB序列（令牌ID、证书、令牌AB）IAC SE-->
<-- IAC SB AUTHENTICATION REPLY
DSS
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_OFF |
INI_CRED_FWD_OFF
DSS_CERTB_TOKENBA2
Sequence( TokenID, CertB,
TokenBA2 )
IAC SE
---------------------------------------------------------------------
Figure 2
<-- IAC SB AUTHENTICATION REPLY
DSS
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_OFF |
INI_CRED_FWD_OFF
DSS_CERTB_TOKENBA2
Sequence( TokenID, CertB,
TokenBA2 )
IAC SE
---------------------------------------------------------------------
Figure 2
As stated earlier, a conformant subset of the defined fields and subfields from FIPS PUB 196 have been selected. This section provides the ASN.1 syntax for that conformant subset.
如前所述，已选择FIPS PUB 196中定义字段和子字段的一致子集。本节提供该一致子集的ASN.1语法。
Figure 1 and Figure 2 include representations of the structures defined in this section. Implementors should refer to the following table to determine the ASN.1 definitions that match the figure references:
图1和图2包括本节中定义的结构表示。实施者应参考下表以确定与图参考相匹配的ASN.1定义：
Figure 1 Sequence( TokenID, TokenBA ) MessageBA Sequence( TokenID, CertA, TokenAB ) MessageAB
图1序列（TokenID，TokenBA）MessageBA序列（TokenID，CertA，TokenAB）MessageAB
Figure 2 Sequence( TokenID, TokenBA ) MessageBA Sequence( TokenID, CertA, TokenAB ) MessageAB Sequence( TokenID, CertB, TokenBA2 ) MessageBA2
图2序列（TokenID，TokenBA）MessageBA序列（TokenID，CertA，TokenAB）MessageAB序列（TokenID，CertB，TokenBA2）MessageBA2
The following ASN.1 definitions specify the conformant subset of FIPS 196. For simplicity, no optional fields or subfields are included. The ASN.1 definition for CertificationPath is imported from CCITT Recommendation X.509 [X.509], and The ASN.1 definition for Name is imported from CCITT Recommendation X.501 [X.501]. These ASN.1
以下ASN.1定义规定了FIPS 196的一致子集。为简单起见，不包括可选字段或子字段。CertificationPath的ASN.1定义从CCITT建议X.509[X.509]导入，Name的ASN.1定义从CCITT建议X.501[X.501]导入。这些ASN.1
definitions are not repeated here. All DSA signature values are encoded as a sequence of two integers, employing the same conventions specified in RFC 2459, section 7.2.2.
这里不再重复定义。所有DSA签名值编码为两个整数的序列，采用RFC 2459第7.2.2节中规定的相同约定。
MessageBA ::= SEQUENCE {
tokenId [0] TokenId,
tokenBA TokenBA }
MessageBA ::= SEQUENCE {
tokenId [0] TokenId,
tokenBA TokenBA }
TokenBA ::= SEQUENCE {
ranB RandomNumber,
timestampB TimeStamp }
TokenBA ::= SEQUENCE {
ranB RandomNumber,
timestampB TimeStamp }
MessageAB ::= SEQUENCE {
tokenId [0] TokenId,
certA [1] CertData,
tokenAB TokenAB }
MessageAB ::= SEQUENCE {
tokenId [0] TokenId,
certA [1] CertData,
tokenAB TokenAB }
TokenAB ::= SEQUENCE {
ranA RandomNumber,
ranB RandomNumber,
entityB EntityName,
timestampB TimeStamp,
absigValue OCTET STRING }
TokenAB ::= SEQUENCE {
ranA RandomNumber,
ranB RandomNumber,
entityB EntityName,
timestampB TimeStamp,
absigValue OCTET STRING }
MessageBA2 ::= SEQUENCE {
tokenId [0] TokenId,
certB [1] CertData,
tokenBA2 TokenBA2 }
MessageBA2 ::= SEQUENCE {
tokenId [0] TokenId,
certB [1] CertData,
tokenBA2 TokenBA2 }
TokenBA2 ::= SEQUENCE {
ranB [0] RandomNumber,
ranA [1] RandomNumber,
entityA EntityName,
timestampB2 TimeStamp,
ba2sigValue OCTET STRING }
TokenBA2 ::= SEQUENCE {
ranB [0] RandomNumber,
ranA [1] RandomNumber,
entityA EntityName,
timestampB2 TimeStamp,
ba2sigValue OCTET STRING }
CertData ::= SEQUENCE {
certPath [0] CertificationPath } -- see X.509
CertData ::= SEQUENCE {
certPath [0] CertificationPath } -- see X.509
EntityName ::= SEQUENCE OF CHOICE { -- only allow one!
directoryName [4] Name } -- see X.501
EntityName ::= SEQUENCE OF CHOICE { -- only allow one!
directoryName [4] Name } -- see X.501
RandomNumber ::= INTEGER -- 20 octets
RandomNumber ::= INTEGER -- 20 octets
TokenId ::= SEQUENCE {
tokenType INTEGER, -- see table below
protoVerNo INTEGER } -- always 0x0001
TokenId ::= SEQUENCE {
tokenType INTEGER, -- see table below
protoVerNo INTEGER } -- always 0x0001
TimeStamp ::= GeneralizedTime
TimeStamp ::= GeneralizedTime
The TokenId.TokenType is used to distinguish the message type and the authentication type (either unilateral or mutual). The following table provides the values needed to implement this specification:
TokenId.TokenType用于区分消息类型和身份验证类型（单边或相互）。下表提供了实施本规范所需的值：
Message Type Authentication Type TokenId.TokenType
消息类型身份验证类型TokenId.TokenType
MessageBA Unilateral 0x0001 Mutual 0x0011
MessageBA单边0x0001相互0x0011
MessageAB Unilateral 0x0002 Mutual 0x0012
MessageAB单边0x0002双向0x0012
MessageBA Mutual 0x0013
MessageBA Mutual 0x0013
This entire memo is about security mechanisms. For DSA to provide the authentication discussed, the implementation must protect the private key from disclosure.
整个备忘录都是关于安全机制的。为了让DSA提供所讨论的身份验证，实现必须保护私钥不被泄露。
Implementations must randomly generate DSS private keys, 'k' values used in DSS signatures, and nonces. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the values, searching the resulting small set of possibilities, rather than using a brute force search. The generation of quality random numbers is difficult. RFC 1750 [RFC1750] offers important guidance in this area, and Appendix 3 of FIPS PUB 186 [FIPS186] provides one quality PRNG technique.
实现必须随机生成DSS私钥、DSS签名中使用的k值和nonce。使用不充分的伪随机数生成器（PRNG）生成加密值可能导致很少或没有安全性。攻击者可能会发现复制生成值的PRNG环境、搜索结果的一小部分可能性比使用蛮力搜索容易得多。生成高质量的随机数是困难的。RFC 1750[RFC1750]在这方面提供了重要的指导，FIPS PUB 186[FIPS186]的附录3提供了一种高质量的PRNG技术。
We would like to thank William Nace for support during implementation of this specification.
我们要感谢William Nace在实施本规范期间提供的支持。
The authentication type DSS and its associated suboption values are registered with IANA. Any suboption values used to extend the protocol as described in this document must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.
身份验证类型DSS及其关联的子选项值在IANA中注册。如本文档所述，用于扩展协议的任何子选项值必须在使用前向IANA注册。IANA被指示在未提交使用文件的情况下不得发布新的子选项值。
FIPS180-1 Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.
<http://csrc.nist.gov/fips/fips180-1.pdf>
FIPS180-1 Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.
<http://csrc.nist.gov/fips/fips180-1.pdf>
FIPS186 Digital Signature Standard (DSS). FIPS Pub 186. May 19,
1994. <http://csrc.nist.gov/fips/fips186.pdf>
FIPS186 Digital Signature Standard (DSS). FIPS Pub 186. May 19,
1994. <http://csrc.nist.gov/fips/fips186.pdf>
FIPS196 Standard for Entity Authentication Using Public Key
Cryptography. FIPS Pub 196. February 18, 1997.
<http://csrc.nist.gov/fips/fips196.pdf>
FIPS196 Standard for Entity Authentication Using Public Key
Cryptography. FIPS Pub 196. February 18, 1997.
<http://csrc.nist.gov/fips/fips196.pdf>
RFC1750 Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
RFC1750 Eastlake，第三，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
RFC2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure: X.509 Certificate and CRL Profile", RFC 2459, January 1999.
RFC2459 Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施：X.509证书和CRL配置文件”，RFC 2459，1999年1月。
RFC2941 T'so, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
RFC2941 T'so，T.和J.Altman，“Telnet认证选项”，RFC 29412000年9月。
X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
X.208 CCITT。建议X.208：抽象语法符号1（ASN.1）的规范。1988
X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.
X.501 CCITT。建议X.501：目录-模型。1988
X.509 CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
X.509 CCITT。建议X.509：目录认证框架。1988
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
拉塞尔·霍斯利·斯皮罗斯美国弗吉尼亚州埃尔登街381号赫恩登1120室，邮编20172
EMail: housley@spyrus.com
EMail: housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
托德·霍廷·斯皮罗斯美国弗吉尼亚州埃尔登街381号赫恩登1120室20172
EMail: thorting@spyrus.com
EMail: thorting@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara，加利福尼亚州95054
EMail: yee@spyrus.com
EMail: yee@spyrus.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编辑功能的资金目前由互联网协会提供。