Network Working Group R. Housley
Request for Comments: 2943 T. Horting
Category: Standards Track P. Yee
SPYRUS
September 2000
TELNET Authentication Using DSA
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）[FIPS186]を使用してTelnet認証メカニズムを定義します。それは、Telnet認証オプション[RFC2941]に依存しています。
AUTHENTICATION 37
認証37
Authentication Commands:
認証コマンド：
IS 0 SEND 1 REPLY 2 NAME 3
0 SEND 1 REPLY 2 NAME 3
Authentication Types:
認証タイプ：
DSS 14
14 DSS
Modifiers:
修飾子：
AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO CLIENT 1
AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TOクライアント1
AUTH_HOW_MASK 2 AUTH_HOW_ONE_WAY 0 AUTH_HOW_MUTUAL 2
AUTH_HOW_MASK 2 AUTH_HOW_ONE_WAY 0 AUTH_HOW_MUTUAL 2
ENCRYPT_MASK 20 ENCRYPT_OFF 0 ENCRYPT_USING_TELOPT 4 ENCRYPT_AFTER_EXCHANGE 16 ENCRYPT_RESERVED 20
ENCRYPT_MASK 20 ENCRYPT_OFF 0 ENCRYPT_USING_TELOPT 4 ENCRYPT_AFTER_EXCHANGE 16 ENCRYPT_RESERVED 20
INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0 INI_CRED_FWD_ON 8
INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0 INI_CRED_FWD_ON 8
Sub-option Commands:
サブオプションのコマンド：
DSS_INITIALIZE 1 DSS_TOKENBA 2 DSS_CERTA_TOKENAB 3 DSS_CERTB_TOKENBA2 4
DSS_INITIALIZE 1 DSS_TOKENBA 2 DSS_CERTA_TOKENAB 3 DSS_CERTB_TOKENBA2 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は、プロトコルとして、セキュリティの概念がありません。交渉されたオプションがなければ、それは単に2つのTELNETプロセスによって表されるNVTsの間で前後に文字を渡します。遠隔端末アクセス（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.
これらのセキュリティサービスをサポートするために、2つの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.
認証とパラメータのネゴシエーションは、取引所の無限のシリーズ内で発生します。サーバはそれがサポートする認証タイプ（メカニズム）の優先度順のリストを提案しています。それがサポートするメカニズムをリストに加えて、サーバは、認証は一方向又は相互ことがあり、そしてどの方向に認証が実行されるかどうかを指定する修飾子で各機構を修飾します。クライアントはリストから1つのメカニズムを選択し、その選択と選択した認証タイプのために必要な認証データの最初のセットを示すサーバーに応答します。サーバとクライアントは、要求された認証に到着するために必要とされる反復のどんな数を進めます。
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）として知られており、名前は互換的に使用されます。本論文では、DSAは、TELNET認証オプションと組み合わせて使用すると、特定のセキュリティサービスを実現するために使用することのできる方法を指定します。 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プロファイルを使用して認証を提供しますが、セッションの整合性を提供していません。この仕様は、メッセージおよびトークンのASN.1符号化には、付録Aを含む公開鍵暗号エンティティ認証メカニズムのための標準、NIST FIPS PUB 196 [FIPS196]で定義されたトークンと交換に続きます。デジタル署名によって覆われているすべてのデータは、識別符号化規則（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パブ196は、認証を提供するために転送される交流のセットを使用します。各交換はオプションでいくつかの様々なフィールドおよびトークンを使用します。また、各トークンはオプションで、いくつかのサブフィールドがあります。フィールドとサブフィールドの準拠サブセットが選択されています。トークンは、FIPSパブ196の付録Aで定義されるように符号化されたASN.1であり、各トークンは、それが（例えば、TokenBAは甲にパーティBから流れる）が流れる方向を示すために命名されています。デジタル署名によって覆われている全てのデータは使用して符号化されなければなりません
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.
認証時に、クライアントは認証名のサブオプションを使用して、サーバーにユーザー名を提供することができます。名前のサブオプションを使用しない場合、サーバーは、一般的に明確に名前とパスワードの入力を求めるプロンプトが表示されます。サーバがサポートされている認証タイプのリストを送信し、クライアントが認証交換を終える前に、これは、サーバーがユーザー名とパスワードの入力を要求しないことを保証した後、名前のサブオプションは、送信する必要があります。図1では、名前のサブオプションは、サーバーがサポートしている認証タイプのリストを提示した直後に送信されます。
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認証では、2オクテットの認証タイプのペアは、DSS AUTH_CLIENT_TO_SERVERですAUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF。これは、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.
交換の各部分が固有の識別子を運ぶ場合無限認証交換内で、実装が大幅に簡素化されます。この理由のため、単一のオクテットのサブオプション識別子は、2オクテットの認証タイプのペアの直後に実施されます。
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認証オプションの知識を推定します。サーバはパーティーB.は交換の終わりにある間、クライアントは、クライアントがサーバーに認証され、パーティAです。
------------------------------------------------------------------
Client (Party A) Server (Party B)
<-- IAC DO AUTHENTICATION
< - IAC DO認証
IAC WILL AUTHENTICATION -->
IAC WILL認証 - >
<-- IAC SB AUTHENTICATION SEND
<list of authentication options>
IAC SE
IAC SB AUTHENTICATION NAME <user name> -->
IAC SB認証名<ユーザー名> - >
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のAUTH_CLIENT_TO_SERVER IS | AUTH_HOW_ONE_WAY | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_INITIALIZE 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 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認証の場合、2オクテットの認証タイプのペアは、DSSのAUTH_CLIENT_TO_SERVERあり| AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF。これは、DSS認証メカニズムは、クライアントとサーバの相互認証に使用されることと何の暗号化は行われないことを示します。
---------------------------------------------------------------------
Client (Party A) Server (Party B)
IAC WILL AUTHENTICATION -->
IAC WILL認証 - >
<-- IAC DO AUTHENTICATION
< - IAC DO認証
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
< - IAC SB AUTHENTICATION> <認証オプションのリストを送ってIAC SE
IAC SB AUTHENTICATION NAME <user name> -->
IAC SB認証名<ユーザー名> - >
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のAUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_INITIALIZE 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
Client (Party A) Server (Party B)
クライアント（当事者A）サーバー（乙）
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のAUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_OFF | INI_CRED_FWD_OFF DSS_CERTA_TOKENABシーケンス（TokenIdが、CERTA、TokenAB）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
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パブ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 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.
以下のASN.1定義は簡略化のためにFIPS 196の適合サブセットを指定しない任意のフィールド、またはサブフィールドが含まれていません。 CertificationPathのASN.1定義は、CCITT勧告X.509 [X.509]からインポートされ、そして名前ASN.1定義はCCITT勧告X.501 [X.501]からインポートされています。これらのASN.1定義はここでは繰り返しません。すべてのDSA署名値は、RFC 2459、セクション7.2.2で指定された同じ規則を用い、二つの整数のシーケンスとして符号化されます。
MessageBA ::= SEQUENCE {
tokenId [0] TokenId,
tokenBA TokenBA }
TokenBA ::= SEQUENCE {
ranB RandomNumber,
timestampB TimeStamp }
MessageAB ::= SEQUENCE {
tokenId [0] TokenId,
certA [1] CertData,
tokenAB TokenAB }
TokenAB ::= SEQUENCE {
ranA RandomNumber,
ranB RandomNumber,
entityB EntityName,
timestampB TimeStamp,
absigValue OCTET STRING }
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 }
CertData ::= SEQUENCE {
certPath [0] CertificationPath } -- see X.509
EntityName ::= SEQUENCE OF CHOICE { -- only allow one!
directoryName [4] Name } -- see X.501
RandomNumber ::= INTEGER -- 20 octets
TokenId ::= SEQUENCE {
tokenType INTEGER, -- see table below
protoVerNo INTEGER } -- always 0x0001
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片側0×0002の相互0x0012
MessageBA Mutual 0x0013
MessageBA相互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」の値、およびノンスを生成しなければなりません。暗号値を生成するために不十分な疑似乱数発生器（の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.
我々は、この仕様の実装時のサポートのためにウィリアム・ネイスに感謝したいと思います。
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。 FIPS 180-1をパブ。 4月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デジタル署名標準（DSS）。 FIPSパブ186 5月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標準。 FIPSパブ196 2月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イーストレイク、第三、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネット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.アルトマン、 "Telnetの認証オプション"、RFC 2941、2000年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
ラッセルHousleyのSPYRUS 381 Eldenストリート、スイート1120ハーンドン、VA 20172 USA
EMail: housley@spyrus.com
メールアドレス：housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
トッドHorting SPYRUS 381 Eldenストリート、スイート1120ハーンドン、VA 20172 USA
EMail: thorting@spyrus.com
メールアドレス：thorting@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
ピーター・イーSPYRUS 5303ベッツィー・ロスドライブサンタクララ、CA 95054 USA
EMail: yee@spyrus.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。