Network Working Group R. Housley
Request for Comments: 2951 T. Horting
Category: Informational P. Yee
SPYRUS
September 2000
TELNET Authentication Using KEA and SKIPJACK
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
抽象
This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNET Authentication Option.
この文書では、鍵交換アルゴリズム（KEA）、およびSKIPJACKを使用してTELNETストリームの暗号化を使用してTELNETを認証する方法を定義します。 2つの暗号化モードが指定されています。 1は、データの整合性を提供し、他にはありません。この方法は、TELNET認証オプションに依存しています。
AUTHENTICATION 37
認証37
Authentication Commands:
認証コマンド：
IS 0 SEND 1 REPLY 2 NAME 3
0 SEND 1 REPLY 2 NAME 3
Authentication Types:
認証タイプ：
KEA_SJ 12 KEA_SJ_INTEG 13
KEA_SJ 12 KEA_SJ_INTEG 13
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:
サブオプションのコマンド：
KEA_CERTA_RA 1 KEA_CERTB_RB_IVB_NONCEB 2 KEA_IVA_RESPONSEB_NONCEA 3 KEA_RESPONSEA 4
KEA_CERTA_RA 1 KEA_CERTB_RB_IVB_NONCEB KEA_IVA_RESPONSEB_NONCEA 2 3 4 KEA_RESPONSEA
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 normally 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:
TELNET認証オプションを提供します：
* User authentication -- replacing or augmenting the normal host
password mechanism;
* Server authentication -- normally done in conjunction with user
authentication;
* Session parameter negotiation -- in particular, encryption key
and attributes;
* Session protection -- primarily encryption of the data and
embedded command stream, but the encryption algorithm may also
provide data integrity.
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 determine the authentication protocol to be used, and possibly the remote user name to be used for authorization checking. Encryption is negotiated along with the type of the authentication.
これらのセキュリティサービスをサポートするために、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) that it supports. In addition to listing the mechanisms it supports, the server qualifies each mechanism with a modifier that specifies whether encryption of data is desired. 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 client may ignore a request to encrypt data and so indicate, but the server may also terminate the connection if the client refuses encryption. The server and the client then proceed through whatever number of iterations is required to arrive at the requested authentication.
認証とパラメータのネゴシエーションは、取引所の無限のシリーズ内で発生します。サーバはそれがサポートする認証タイプ（メカニズム）の優先度順のリストを提案しています。それがサポートするメカニズムをリストに加えて、サーバは、データの暗号化が必要であるかどうかを指定する修飾子を持つ各機構を修飾します。クライアントはリストから1つのメカニズムを選択し、その選択と選択した認証タイプのために必要な認証データの最初のセットを示すサーバーに応答します。クライアントは、データを暗号化し、その旨の要求を無視するかもしれませんが、クライアントが暗号化を拒否した場合、サーバーは、接続を終了させることができます。サーバとクライアントは、反復回数が要求された認証に到着するために必要なものは何でもを進めます。
Encryption is started immediately after the Authentication Option is completed.
認証オプションが完了した後に暗号化がすぐに開始されます。
This paper specifies the method in which KEA is used to achieve TELNET Authentication. KEA (in conjunction with SKIPJACK) [4] provides authentication and confidentiality. Integrity may also be provided.
本論文では、KEAはTELNET認証を達成するために使用される方法を指定します。 （SKIPJACKと共に）KEA [4]認証および機密性を提供します。整合性を提供することもできます。
TELNET entities may use KEA to provide mutual authentication and support for the setup of data encryption keys. A simple token format and set of exchanges delivers these services.
TELNETエンティティは、データ暗号化キーの設定のための相互認証とサポートを提供するためにKEAを使用することができます。交換の簡単なトークン形式とのセットは、これらのサービスを提供しています。
NonceA and NonceB used in this exchange are 64-bit bit strings. The client generates NonceA, and the server generates NonceB. The nonce value is selected randomly. The nonce is sent in a big endian form. The encryption of the nonce will be done with the same mechanism that the session will use, detailed in the next section.
この交換で使用NonceAとNonceBは、64ビットのビット列です。クライアントはNonceAを生成し、サーバがNonceBを生成します。ノンス値がランダムに選択されます。ナンスは、ビッグエンディアン形式で送信されます。ナンスの暗号化は、次のセクションで詳述したセッションが使用するのと同じメカニズムで行われます。
Ra and Rb used in this exchange are 1024 bit strings and are defined by the KEA Algorithm [4].
この交換で使用さRaおよびRbは、1024ビット列であり、KEAアルゴリズム[4]によって定義されます。
The IVa and IVb are 24 byte Initialization Vectors. They are composed of "THIS IS NOT LEAF" followed by 8 random bytes.
IVaおよびIVbは、24バイトの初期化ベクトルです。これらは、ランダムな8バイトに続いて「これはLEAFされていません」で構成されています。
CertA is the client's certificate. CertB is the server's certificate. Both certificates are X.509 certificates [6] that contain KEA public keys [7]. The client must validate the server's certificate before using the KEA public key it contains. Likewise, the server must validate the client's certificate before using the KEA public key it contains.
CERTAは、クライアントの証明書です。 CertBは、サーバーの証明書です。両方の証明書はKEA公開鍵[7]を含むX.509証明書[6]です。クライアントは、それが含まれているKEA公開鍵を使用する前に、サーバーの証明書を検証しなければなりません。同様に、サーバはそれが含まれているKEA公開鍵を使用する前に、クライアントの証明書を検証する必要があります。
On completing these exchanges, the parties have a common SKIPJACK key. Mutual authentication is provided by verification of the certificates used to establish the SKIPJACK encryption key and successful use of the derived SKIPJACK session key. To protect against active attacks, encryption will take place after successful authentication. There will be no way to turn off encryption and safely turn it back on; repeating the entire authentication is the only safe way to restart it. If the user does not want to use encryption, he may disable encryption after the session is established.
これらの交換を完了した上で、当事者が共通SKIPJACKキーを持っています。相互認証は、カツオの暗号化キーと派生SKIPJACKセッションキーの使用の成功を確立するために使用される証明書の検証により提供されます。アクティブな攻撃から保護するために、暗号化は、認証が成功した後に行われます。暗号化をオフにして、無事に戻ってそれをオンにする方法はありません。全体の認証を繰り返すことは、それを再起動する唯一の安全な方法です。ユーザーが暗号化を使用したくない場合は、セッションが確立された後、彼は、暗号化を無効にすることがあります。
There are two distinct modes for encrypting TELNET streams; one provides integrity and the other does not. Because TELNET is normally operated in a character-by-character mode, the SKIPJACK with stream integrity mechanism requires the transmission of 4 bytes for every TELNET data byte. However, a simplified mode SKIPJACK without integrity mechanism will only require the transmission of one byte for every TELNET data byte.
TELNETストリームを暗号化するための2つの異なるモードがあります。 1は、整合性を提供し、他にはありません。 TELNETは、通常、文字単位モードで動作しているため、ストリームの整合性のメカニズムとSKIPJACKは、すべてのTELNETデータバイトのための4バイトの伝送を必要とします。しかし、整合性のメカニズムのない簡易モードのSKIPJACKはすべてのTELNETデータバイト1バイトの送信が必要になります。
The cryptographic mode for SKIPJACK with stream integrity is Cipher Feedback on 32 bits of data (CFB-32) and the mode of SKIPJACK is Cipher Feedback on 8 bits of data (CFB-8).
ストリームの整合性SKIPJACKのための暗号化モードは、32ビットのデータ（CFB-32）およびSKIPJACKのモードで暗号フィードバックデータの8ビット（CFB-8）で暗号フィードバックされます。
The first and least complicated mode uses SKIPJACK CFB-8. This mode provides no stream integrity.
最初と最も複雑なモードがSKIPJACK CFB-8を使用しています。このモードには、ストリームの整合性を提供していません。
For SKIPJACK without stream integrity, the two-octet authentication type pair is KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the SKIPJACK without integrity mechanism will be used for mutual authentication and TELNET stream encryption. Figure 1 illustrates the authentication mechanism of KEA followed by SKIPJACK without stream integrity.
ストリームの整合性のないSKIPJACKについては、2オクテットの認証タイプのペアはKEA_SJのAUTH_CLIENT_TO_SERVERあり| AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF。これは、整合性のメカニズムのないSKIPJACKは、相互認証とTELNETストリームの暗号化に使用されることを示します。図1は、KEAの認証機構は、ストリームの完全性なしSKIPJACK続い示します。
---------------------------------------------------------------------
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 KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_CERTA_RA CertA||Ra IAC SE -->
IAC SB認証はKEA_SJ AUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_CERTA_RA CERTA || RaはIAC SE - >
<-- IAC SB AUTHENTICATION REPLY
KEA_SJ
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
IVA_RESPONSEB_NONCEA
KEA_CERTB_RB_IVB_NONCEB
CertB||Rb||IVb||
Encrypt( NonceB )
IAC SE
IAC SB AUTHENTICATION IS KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_IVA_RESPONSEB_NONCEA IVa||Encrypt( (NonceB XOR 0x0C12)||NonceA ) IAC SE -->
IAC SB認証はKEA_SJ AUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_IVA_RESPONSEB_NONCEAのIVa ||暗号化（（NonceB XOR 0x0C12）|| NonceA）IAC SE - >
Client (Party A) Server (Party B)
クライアント（当事者A）サーバー（乙）
<client begins encryption> <-- IAC SB AUTHENTICATION REPLY KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA Encrypt( NonceA XOR 0x0C12 ) IAC SE
| IAC SB認証REPLY KEA_SJ AUTH_CLIENT_TO_SERVER - <<クライアントは、暗号化始まり>をAUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA暗号化（NonceA XOR 0x0C12）IAC SE
<server begins encryption>
---------------------------------------------------------------------
Figure 1.
SKIPJACK with stream integrity is more complicated. It uses the SHA-1 [3] one-way hash function to provide integrity of the encryption stream as follows:
ストリームの整合性を持つSKIPJACKはより複雑です。それは次のように暗号化ストリームの整合性を提供するために、SHA-1 [3]一方向ハッシュ関数を使用しています。
Set H0 to be the SHA-1 hash of a zero-length string.
Cn is the nth character in the TELNET stream.
Hn = SHA-1( Hn-1||Cn ), where Hn is the hash value
associated with the nth character in the stream.
ICVn is set to the three most significant bytes of Hn.
Transmit Encrypt( Cn||ICVn ).
The ciphertext that is transmitted is the SKIPJACK CFB-32 encryption of ( Cn||ICVn ). The receiving end of the TELNET link reverses the process, first decrypting the ciphertext, separating Cn and ICVn, recalculating Hn, recalculating ICVn, and then comparing the received ICVn with the recalculated ICVn. Integrity is indicated if the comparison succeeds, and Cn can then be processed normally as part of the TELNET stream. Failure of the comparison indicates some loss of integrity, whether due to active manipulation or loss of cryptographic synchronization. In either case, the only recourse is to drop the TELNET connection and start over.
送信された暗号文は、（CN || ICVn）のSKIPJACK CFB-32暗号化です。 TELNETリンクの受信端はまず、Hnの再計算、CNおよびICVnを分離し、暗号文を復号ICVnを再計算し、再計算ICVnで受信ICVnを比較し、プロセスを反転させます。比較が成功した場合に整合性が示され、Cnが次にTELNETストリームの一部として正常に処理することができます。比較の失敗は、アクティブな操作や暗号同期の損失に起因するかどうか、整合性のある損失を示しています。いずれの場合においても、唯一の頼みの綱は、telnet接続を削除して最初からやり直すことです。
For SKIPJACK with stream integrity, the two-octet authentication type pair is KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the KEA SKIPJACK with integrity mechanism will be used for mutual authentication and TELNET stream encryption. Figure 2 illustrates the authentication mechanism of KEA SKIPJACK with stream integrity.
ストリームの整合性とSKIPJACKのために、2オクテットの認証タイプのペアがKEA_SJ_INTEG AUTH_CLIENT_TO_SERVERあり| AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF。これは、整合性のメカニズムとKEA SKIPJACKは、相互認証とTELNETストリームの暗号化に使用されることを示します。図2は、ストリームの完全性とKEA SKIPJACKの認証メカニズムを示します。
---------------------------------------------------------------------
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 KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_CERTA_RA CertA||Ra IAC SE -->
IAC SB認証はKEA_SJ_INTEG AUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_CERTA_RA CERTA || RaはIAC SE - >
<-- IAC SB AUTHENTICATION REPLY
KEA_SJ_INTEG
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
IVA_RESPONSEB_NONCEA
KEA_CERTB_RB_IVB_NONCEB
CertB||Rb||IVb||
Encrypt( NonceB )
IAC SE
IAC SB AUTHENTICATION IS KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_IVA_RESPONSEB_NONCEA IVa||Encrypt( (NonceB XOR 0x0D12)||NonceA ) IAC SE -->
IAC SB認証はKEA_SJ_INTEG AUTH_CLIENT_TO_SERVER IS | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_IVA_RESPONSEB_NONCEAのIVa ||暗号化（（NonceB XOR 0x0D12）|| NonceA）IAC SE - >
Client (Party A) Server (Party B)
クライアント（当事者A）サーバー（乙）
<client begins encryption> <-- IAC SB AUTHENTICATION REPLY KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA Encrypt( NonceA XOR 0x0D12 ) IAC SE
<クライアントは、暗号化を開始します> < - IAC SB認証REPLY KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA暗号化（NonceA XOR 0x0D12）IAC SE
<server begins encryption>
---------------------------------------------------------------------
Figure 2
This entire memo is about security mechanisms. For KEA to provide the authentication discussed, the implementation must protect the private key from disclosure. Likewise, the SKIPJACK keys must be protected from disclosure.
この全体のメモは、セキュリティ・メカニズムについてです。 KEAが議論認証を提供するために、実装は、開示から秘密鍵を保護しなければなりません。同様に、SKIPJACKキーは開示から保護されなければなりません。
Implementations must randomly generate KEA private keys, initialization vectors (IVs), and nonces. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 1750 [8] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [9] provides one quality PRNG technique.
実装はランダムにKEA秘密鍵、初期化ベクトル（IV）、およびナンスを生成する必要があります。暗号鍵を生成するために不十分な疑似乱数発生器（のPRNG）の使用は、ほとんどまたは全くセキュリティをもたらすことができます。攻撃者はそれをはるかに簡単に全体のキースペースを検索結果として起こる小さい可能性はなく、ブルートフォースを探し、キーを生成PRNG環境を再現するかもしれません。品質の乱数の生成が困難です。 RFC 1750 [8]この領域で重要な指導を提供し、FIPSパブ186の付録3 [9] 1つの品質PRNGの技術を提供します。
By linking the enabling of encryption as a side effect of successful authentication, protection is provided against an active attacker. If encryption were enabled as a separate negotiation, it would provide a window of vulnerability from when the authentication completes, up to and including the negotiation to turn on encryption. The only safe way to restart encryption, if it is turned off, is to repeat the entire authentication process.
成功した認証の副作用として暗号化の有効化をリンクすることで、保護がアクティブな攻撃者に対して提供されます。暗号化が別々の交渉として有効になっていた場合、それは最高の暗号化をオンにする交渉を含めへと、認証が完了したときから、脆弱性の窓を提供します。それがオフになっている場合は、暗号化を再起動する唯一の安全な方法は、全体の認証プロセスを繰り返すことです。
The authentication types KEA_SJ and KEA_SJ_INTEG and their 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.
認証タイプKEA_SJとKEA_SJ_INTEGとそれに関連するサブオプションの値は、IANAに登録されています。この文書に記載されているようにプロトコルを拡張するために使用される任意のサブオプションの値は、使用前にIANAに登録されなければなりません。 IANAは、それらの使用の文書の提出せずに新しいサブオプション値を発行しないように指示されます。
We would like to thank William Nace for support during implementation of this specification.
我々は、この仕様の実装時のサポートのためにウィリアム・ネイスに感謝したいと思います。
[1] Postel, J. and J. Reynolds, "TELNET Protocol Specification", ASTD 8, RFC 854, May 1983.
[1]ポステル、J.、およびJ.レイノルズ、 "TELNETプロトコル仕様"、ASTD 8、RFC 854、1983月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'oさん、T.及びJ.アルトマン、 "Telnetの認証オプション"、RFC 2941、2000年9月。
[3] Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.
[3]セキュアハッシュ標準。 FIPS 180-1をパブ。 1995年4月17日。
[4] "SKIPJACK and KEA Algorithm Specification", Version 2.0, May 29, 1998. Available from http://csrc.nist.gov/encryption/skipjack-kea.htm
[4] "SKIPJACKとKEAアルゴリズム仕様" http://csrc.nist.gov/encryption/skipjack-kea.htmから、バージョン2.0、5月29日、1998年には、利用可能な
[5] Postel, J. and J. Reynolds, "TELNET Option Specifications", STD 8, RFC 855, May 1983.
[5]ポステル、J.、およびJ.レイノルズ、 "TELNETオプション仕様"、STD 8、RFC 855、1983月。
[6] 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.
[6] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵インフラストラクチャ：X.509証明書とCRLプロファイル"、RFC 2459、1999年1月。
[7] Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure - Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", RFC 2528, March 1999.
[7] Housley氏、R.とW.ポーク、 "インターネットX.509公開鍵基盤 - インターネットX.509公開鍵基盤証明書で鍵交換アルゴリズム（KEA）キーの表現"、RFC 2528、1999年3月を。
[8] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[8]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[9) National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[9）アメリカ国立標準技術研究所。 FIPSパブ186：デジタル署名標準。 1994年5月19日。
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
ラッセルHousleyのSPYRUS 381 Eldenストリート、スイート1120ハーンドン、VA 20170 USA
EMail: housley@spyrus.com
メールアドレス：housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
トッドHorting SPYRUS 381 Eldenストリート、スイート1120ハーンドン、VA 20170 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機能のための基金は現在、インターネット協会によって提供されます。