RFC2943 日本語訳
2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT=21694 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 2943 T. Horting
Category: Standards Track P. Yee
SPYRUS
September 2000
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2943年のT.Hortingカテゴリ: 標準化過程P.イーSPYRUS2000年9月
TELNET Authentication Using DSA
DSAを使用するtelnet認証
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA) [FIPS186]. It relies on the Telnet Authentication Option [RFC2941].
このドキュメントは、Digital Signature Algorithm(DSA)[FIPS186]を使用することでtelnet認証機構を定義します。 それはTelnet Authentication Option[RFC2941]を当てにします。
1. Command Names and Codes
1. コマンド名とコード
AUTHENTICATION 37
認証37
Authentication Commands:
認証は命令します:
IS 0
SEND 1
REPLY 2
NAME 3
0が1つの回答2の名前3を送るということです。
Authentication Types:
認証は以下をタイプします。
DSS 14
DSS14
Modifiers:
修飾語:
AUTH_WHO_MASK 1
AUTH_CLIENT_TO_SERVER 0
AUTH_SERVER_TO CLIENT 1
クライアント1への_サーバ0AUTH_サーバ_へのAUTH_WHO_マスク1AUTH_クライアント_
Housley, et al. Standards Track [Page 1] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[1ページ]RFC2943telnet認証
AUTH_HOW_MASK 2
AUTH_HOW_ONE_WAY 0
AUTH_HOW_MUTUAL 2
_が2AUTH_にマスクをかけるAUTH_、どのように、_1_道0のAUTH_、_どれくらい互いの2
ENCRYPT_MASK 20
ENCRYPT_OFF 0
ENCRYPT_USING_TELOPT 4
ENCRYPT_AFTER_EXCHANGE 16
ENCRYPT_RESERVED 20
暗号化、____交換16が_予約された20を暗号化した後にTELOPT4が暗号化する_を使用して、マスク20はオフ0が暗号化する_を暗号化します。
INI_CRED_FWD_MASK 8
INI_CRED_FWD_OFF 0
INI_CRED_FWD_ON 8
_8の0INI_信用_FWD_のINI_信用_FWD_マスク8INI_信用FWD_
Sub-option Commands:
サブオプションは命令します:
DSS_INITIALIZE 1
DSS_TOKENBA 2
DSS_CERTA_TOKENAB 3
DSS_CERTB_TOKENBA2 4
DSS_は_1DSS_TOKENBA2のDSS_CERTA_TOKENAB3DSS CERTB_TOKENBA2 4を初期化します。
2. TELNET Security Extensions
2. telnetセキュリティ拡大
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 Authentication Optionはユーザー認証とサーバ証明に備えます。 ユーザー認証は、正常なホストパスワードメカニズムを取り替えるか、または増大させます。 通常、ユーザー認証に関連してサーバー証明をします。
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 Optionをサポートするそれらの意欲を交渉しなければなりません。 許可検査に使用されるべき認証とのサブオプション交渉が使用されるために議定書を作るのに次にこのオプション、パーティーが実行できるサポートに同意して、ことによるとリモート・ユーザー名で。
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
認証とパラメタ交渉は限りないシリーズの交換の中に起こります。 サーバはそれがサポートする認証タイプ(メカニズム)の好みで規則正しいリストを提案します。 それがサポートするメカニズムを記載することに加えてサーバが指定する修飾語で各メカニズムに資格を与える、認証
Housley, et al. Standards Track [Page 2] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[2ページ]RFC2943telnet認証
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つのメカニズムを選択して、選択と選択された認証に必要である認証データの第一セットがタイプされるのを示すサーバに応じます。 そして、数の何でも繰り返しが要求された認証に到達するのに必要であるかを通してサーバとクライアントは続きます。
3. Use of Digital Signature Algorithm (DSA)
3. デジタル署名アルゴリズムの使用(DSA)
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 Authentication Optionに関連して使用されると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 PUB196[FIPS196](メッセージとトークンのASN.1コード化でのAppendix Aを含むPublic Key Cryptographic Entity Authentication MechanismsのためのStandard)で定義されたトークンと交換に続きます。 Distinguished Encoding Rules(DER)を使用することでデジタル署名でカバーされているすべてのデータをコード化しなければなりません。 しかしながら、他のデータはBasic Encoding Rules(BER)かDER[X.208]のどちらかを使用するかもしれません。
3.1. Unilateral Authentication with DSA
3.1. DSAとの一方的な認証
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 Authentication Optionフレームワークの下でFIPS PUB196の指定されるとしてDSA認証を実行するのに必要なプロトコルステップです。 故障モードが遭遇するところに、復帰コードはTELNET Authentication Optionで指定されたものに続きます。 それらは、使用されるメカニズムの中で不変であるので、ここに数え上げられません。 FIPS PUB196は認証を提供するために移される1セットの交換を使います。 各交換は多岐とトークンを使います。その或るものは任意です。 さらに、各トークンには、いくつかの任意の部分体があります。 分野と部分体のconformant部分集合は選択されました。 トークンはFIPS PUB196のAppendix Aで定義されるようにコード化されたASN.1です、そして、各トークンは、それが流れる方向を示すために命名されます(例えば、TokenBAはパーティBからパーティAまで流れます)。 デジタル署名でカバーされているすべてのデータはコード化された使用であるに違いありません。
Housley, et al. Standards Track [Page 3] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[3ページ]RFC2943telnet認証
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)を統治します。 デジタル署名でカバーされていないデータはBasic Encoding Rules(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、_どのように、_1_道| _を下に暗号化してください。| _INI_信用FWD_、オフです。 これは、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 PUB196とTELNET Authentication Optionに関する知識を推定します。 クライアントはパーティAです、交換の終わりにサーバがパーティB.Atですが、クライアントはサーバに認証されます。
Housley, et al. Standards Track [Page 4] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[4ページ]RFC2943telnet認証
------------------------------------------------------------------ Client (Party A) Server (Party B)
------------------------------------------------------------------ クライアント、(パーティa)サーバ(パーティB)
<-- IAC DO AUTHENTICATION
<--IACは認証します。
IAC WILL AUTHENTICATION -->
IACウィルAUTHENTICATION-->。
<-- IAC SB AUTHENTICATION SEND
<list of authentication options>
IAC SE
<--認証オプション>IAC SEのIAC SB AUTHENTICATION SEND<リスト
IAC SB AUTHENTICATION NAME <user name> -->
IAC SB AUTHENTICATION 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 AUTH_クライアント_です。| AUTH、_どのように、_1_道| _を下に暗号化してください。| INI_信用_FWD_は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 AUTH_クライアント_| AUTH、_どのように、_1_道| _を下に暗号化してください。| _DSS_TOKENBA系列(TokenID、TokenBA)IAC SEのINI_信用FWD_
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認証は_サーバへのDSS AUTH_クライアント_です。| AUTH、_どのように、_1_道| _を下に暗号化してください。| _DSS_CERTA_TOKENAB系列(TokenID、CertA、TokenAB)IAC SEのINI_信用FWD_--、>。------------------------------------------------------------------ 図1
Housley, et al. Standards Track [Page 5] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[5ページ]RFC2943telnet認証
3.2. Mutual Authentication with DSA
3.2. DSAとの互いの認証
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_、_どれくらい互い| _を下に暗号化してください。| _INI_信用FWD_、オフです。 これは、DSS認証機構が互いにクライアントとサーバを認証するのに使用されて、暗号化が全く実行されないのを示します。
--------------------------------------------------------------------- Client (Party A) Server (Party B)
--------------------------------------------------------------------- クライアント、(パーティa)サーバ(パーティB)
IAC WILL AUTHENTICATION -->
IACウィルAUTHENTICATION-->。
<-- IAC DO AUTHENTICATION
<--IACは認証します。
<-- IAC SB AUTHENTICATION SEND
<list of authentication options>
IAC SE
<--認証オプション>IAC SEのIAC SB AUTHENTICATION SEND<リスト
IAC SB AUTHENTICATION NAME <user name> -->
IAC SB AUTHENTICATION 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 AUTH_クライアント_です。| AUTH_、_どれくらい互い| _を下に暗号化してください。| INI_信用_FWD_は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 AUTH_クライアント_| AUTH_、_どれくらい互い| _を下に暗号化してください。| _DSS_TOKENBA系列(TokenID、TokenBA)IAC SEのINI_信用FWD_
Housley, et al. Standards Track [Page 6] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[6ページ]RFC2943telnet認証
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認証は_サーバへのDSS AUTH_クライアント_です。| AUTH_、_どれくらい互い| _を下に暗号化してください。| _DSS_CERTA_TOKENAB系列(TokenID、CertA、TokenAB)IAC SEのINI_信用FWD_--、>。
<-- 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認証回答DSS AUTH_クライアント_| AUTH_、_どれくらい互い| _を下に暗号化してください。| _DSS_CERTB_TOKENBA2系列(TokenID、CertB、TokenBA2)IAC SEのINI_信用FWD_--------------------------------------------------------------------- 図2
4. ASN.1 Syntax
4. ASN.1構文
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 PUB196からの定義された分野と部分体のconformant部分集合は選択されました。 このセクションはASN.1構文をそのconformant部分集合に提供します。
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定義はFIPS196のconformant部分集合を指定します。 簡単さにおいて、任意の分野かどんな部分体も含まれていません。 CertificationPathのためのASN.1定義はCCITT Recommendation X.509[X.509]からインポートされます、そして、NameのためのASN.1定義はCCITT Recommendation X.501[X.501]からインポートされます。 これらのASN.1
Housley, et al. Standards Track [Page 7] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[7ページ]RFC2943telnet認証
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署名値が2つの整数の系列としてコード化されます、RFC2459、セクション7.2.2で指定された同じコンベンションを使って。
MessageBA ::= SEQUENCE {
tokenId [0] TokenId,
tokenBA TokenBA }
MessageBA:、:= 系列tokenId[0]TokenId、tokenBA TokenBA
TokenBA ::= SEQUENCE {
ranB RandomNumber,
timestampB TimeStamp }
TokenBA:、:= 系列ranB RandomNumber、timestampBタイムスタンプ
MessageAB ::= SEQUENCE {
tokenId [0] TokenId,
certA [1] CertData,
tokenAB TokenAB }
MessageAB:、:= 系列tokenId[0]TokenId、certA[1]CertData、tokenAB TokenAB
TokenAB ::= SEQUENCE {
ranA RandomNumber,
ranB RandomNumber,
entityB EntityName,
timestampB TimeStamp,
absigValue OCTET STRING }
TokenAB:、:= 系列ranA RandomNumber、ranB RandomNumber、entityB EntityName、timestampBタイムスタンプ、absigValue八重奏ストリング
MessageBA2 ::= SEQUENCE {
tokenId [0] TokenId,
certB [1] CertData,
tokenBA2 TokenBA2 }
MessageBA2:、:= 系列tokenId[0]TokenId、certB[1]CertData、tokenBA2 TokenBA2
TokenBA2 ::= SEQUENCE {
ranB [0] RandomNumber,
ranA [1] RandomNumber,
entityA EntityName,
timestampB2 TimeStamp,
ba2sigValue OCTET STRING }
TokenBA2:、:= 系列ranB[0]RandomNumber、ranA[1]RandomNumber、entityA EntityName、timestampB2タイムスタンプ、ba2sigValue八重奏ストリング
CertData ::= SEQUENCE {
certPath [0] CertificationPath } -- see X.509
CertData:、:= SEQUENCE certPath[0]CertificationPath--X.509を見てください。
EntityName ::= SEQUENCE OF CHOICE { -- only allow one!
directoryName [4] Name } -- see X.501
EntityName:、:= SEQUENCE OF CHOICE、--、単に1つ!directoryName[4]名前を許容してください--X.501を見てください
RandomNumber ::= INTEGER -- 20 octets
RandomNumber:、:= INTEGER--20の八重奏
Housley, et al. Standards Track [Page 8] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[8ページ]RFC2943telnet認証
TokenId ::= SEQUENCE {
tokenType INTEGER, -- see table below
protoVerNo INTEGER } -- always 0x0001
TokenId:、:= SEQUENCE、tokenType INTEGER--protoVerNo INTEGERの下のテーブルを見てください--、いつも0×0001
TimeStamp ::= GeneralizedTime
タイムスタンプ:、:= 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の互いの0×0011
MessageAB Unilateral 0x0002
Mutual 0x0012
MessageAB一方的な0x0002の互いの0×0012
MessageBA Mutual 0x0013
MessageBAの互いの0×0013
5. Security Considerations
5. セキュリティ問題
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'値、および一回だけを生成しなければなりません。 暗号の値を生成する不十分な疑似乱数発生器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、値を生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、力任せの検索を使用するよりむしろ結果として起こる小さい可能性を捜して。 上質の乱数の世代は難しいです。 RFC1750[RFC1750]はこの領域で重要な指導を提供します、そして、FIPS PUB186[FIPS186]のAppendix3は1つの上質のPRNGのテクニックを提供します。
6. Acknowledgements
6. 承認
We would like to thank William Nace for support during implementation of this specification.
この仕様の実装の間、サポートについてウィリアムNaceに感謝申し上げます。
Housley, et al. Standards Track [Page 9] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[9ページ]RFC2943telnet認証
7. IANA Considerations
7. IANA問題
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が彼らの使用のドキュメンテーションの提出なしで新しい「副-オプション」値を発行しないよう命令されます。
8. References
8. 参照
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。 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)。 FIPSパブ186。 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パブ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イーストレークと3番目とD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、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プロフィール」、RFC2459、1月1999日
RFC2941 T'so, T. and J. Altman, "Telnet Authentication Option", RFC
2941, September 2000.
RFC2941 T'soとT.とJ.アルトマン、「telnet認証オプション」、RFC2941、2000年9月。
X.208 CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
X.208CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.
X.501 CCITT. Recommendation X.501: The Directory - Models. 1988.
X.501CCITT。 推薦X.501: ディレクトリ--モデル。 1988.
X.509 CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988.
X.509CCITT。 推薦X.509: ディレクトリ--認証フレームワーク。 1988.
Housley, et al. Standards Track [Page 10] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[10ページ]RFC2943telnet認証
9. Authors' Addresses
9. 作者のアドレス
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
ラッセルHousley SPYRUS381エルデンスイート1120ハーンドン、ヴァージニア20172通り(米国)
EMail: housley@spyrus.com
メール: housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20172 USA
トッドHorting SPYRUS381エルデンスイート1120ハーンドン、ヴァージニア20172通り(米国)
EMail: thorting@spyrus.com
メール: thorting@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
ピーターイーSPYRUS5303ベッツィ・ロス・Driveカリフォルニア95054サンタクララ(米国)
EMail: yee@spyrus.com
メール: yee@spyrus.com
Housley, et al. Standards Track [Page 11] RFC 2943 TELNET Authentication Using DSA September 2000
Housley、他 2000年9月にDSAを使用する標準化過程[11ページ]RFC2943telnet認証
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Housley, et al. Standards Track [Page 12]
Housley、他 標準化過程[12ページ]
一覧
スポンサーリンク
