[要約] RFC 2943は、TELNET認証にDSA（Digital Signature Algorithm）を使用する方法を提案しています。このRFCの目的は、TELNETセッションのセキュリティを向上させるために、DSAを使用した認証メカニズムを定義することです。
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.
Copyright（c）The Internet Society（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
Authentication Types:
認証タイプ：
DSS 14
DSS 14
Modifiers:
修飾子：
AUTH_WHO_MASK 1
AUTH_CLIENT_TO_SERVER 0
AUTH_SERVER_TO CLIENT 1
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
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
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プロセスで表される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.
これらのセキュリティサービスをサポートするために、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）とも呼ばれ、名前は同じ意味で使用されます。このペーパーでは、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のキャラクターごとの性質により、Integrityのみのサービスの適用には適していないため、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 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.
一方的な認証は、クライアントからサーバーに行う必要があります。以下は、Telnet認証オプションフレームワークの下でFIPS Pub 196で指定されているDSA認証を実行するために必要なプロトコル手順です。障害モードが発生した場合、返信コードはTelnet認証オプションで指定されているコードに従います。これらは、使用されているメカニズムの中で不変であるため、ここでは列挙されていません。Fips Pub 196は、認証を提供するために転送される一連の交換を採用しています。各交換にはさまざまなフィールドとトークンが採用されており、その一部はオプションです。さらに、各トークンにはオプションのいくつかのサブフィールドがあります。フィールドとサブフィールドの適合サブセットが選択されています。トークンは、FIPS Pub 196の付録Aで定義されているようにエンコードされています。各トークンは、それが流れる方向を示すために名前が付けられています（たとえば、トークンバはパーティBからパーティーAに流れます）。デジタル署名でカバーされているすべてのデータは、著名なエンコードルール（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認証オプションの知識を推定しています。クライアントはパーティーAです。サーバーはパーティBです。取引所の終わりに、クライアントはサーバーに認証されます。
------------------------------------------------------------------
Client (Party A) Server (Party B)
<-- IAC DO AUTHENTICATION
<-IACは認証を行います
IAC WILL AUTHENTICATION -->
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<-IACSB認証送信<認証オプションのリスト> IAC SE
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 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 auth_client_to_server |auth_how_one_way |encrypt_off |ini_cred_fwd_off dss_tokenbaシーケンス（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 DO AUTHENTICATION
<-IACは認証を行います
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<-IACSB認証送信<認証オプションのリスト> IAC SE
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 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 auth_client_to_server |auth_how_mutual |encrypt_off |ini_cred_fwd_off dss_tokenbaシーケンス（tokenid、tokenba）iac se
Client (Party A) Server (Party B)
クライアント（パーティーA）サーバー（パーティー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 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 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のコンフォーマントサブセットを指定します。簡単にするために、オプションのフィールドまたはサブフィールドは含まれていません。認証パスのASN.1定義はCCITT推奨X.509 [X.509]からインポートされ、名前のASN.1定義はCCITT推奨X.501 [X.501]からインポートされます。これらのASN.1の定義はここで繰り返されません。すべてのDSA署名値は、RFC 2459、セクション7.2.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
MessageAB Unilateral 0x0002
Mutual 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」値、およびNoncesをランダムに生成する必要があります。不十分な擬似ランダム数ジェネレーター（PRNG）を使用して暗号化値を生成すると、セキュリティがほとんどまたはまったくなくなります。攻撃者は、ブルートフォース検索を使用するのではなく、値を生成するPRNG環境を再現し、結果として生じる小さな可能性のセットを検索する方がはるかに簡単だと感じるかもしれません。品質の乱数の生成は困難です。RFC 1750 [RFC1750]はこの分野で重要なガイダンスを提供し、FIPS Pub 186 [FIPS186]の付録3は1つの高品質の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セキュアハッシュ標準。FIPS Pub 180-1。1995年4月17日。<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）。FIPSPub186。1994年5月19日。<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 Pub 196. 1997年2月18日。<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、3rd、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。and 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 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
Russell Housley Spyrus 381 Elden Street、Suite 1120 Herndon、VA 20172 USA
EMail: housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
トッド・ホーストスピルス381エルデンストリート、スイート1120ハーンドン、バージニア州20172 USA
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、CA 95054 USA
EMail: yee@spyrus.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。