RFC1994 日本語訳
1994 PPP Challenge Handshake Authentication Protocol (CHAP). W.Simpson. August 1996. (Format: TXT=24094 bytes) (Obsoletes RFC1334) (Updated by RFC2484) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson Request for Comments: 1994 DayDreamer Obsoletes: 1334 August 1996 Category: Standards Track
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1994年の空想家は以下を時代遅れにします。 1334 1996年8月のカテゴリ: 標準化過程
PPP Challenge Handshake Authentication Protocol (CHAP)
pppチャレンジハンドシェイク式認証プロトコル(やつ)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
また、PPPは広げることができるLink Controlプロトコルを定義します。(それは、Network Layerプロトコルがリンクの上に伝わるのを許容する前に同輩を認証するためのAuthenticationプロトコルの交渉を許します)。
This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key.
このドキュメントはAuthenticationのために無作為のChallengeを使用するPPPを使用することでメソッドを定義します、Challengeと秘密鍵による暗号で論じ尽くされたResponseと共に。
Table of Contents
目次
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 1
1.2 Terminology ..................................... 2
2. Challenge-Handshake Authentication Protocol ........... 2
2.1 Advantages ...................................... 3
2.2 Disadvantages ................................... 3
2.3 Design Requirements ............................. 4
3. Configuration Option Format ........................... 5
4. Packet Format ......................................... 6
4.1 Challenge and Response .......................... 7
4.2 Success and Failure ............................. 9
SECURITY CONSIDERATIONS ...................................... 10
ACKNOWLEDGEMENTS ............................................. 11
REFERENCES ................................................... 12
CONTACTS ..................................................... 12
1. 序論… 1 1.1 要件の仕様… 1 1.2用語… 2 2. 挑戦握手認証プロトコル… 2 2.1の利点… 3 2.2 不都合です。 3 2.3 要件を設計してください… 4 3. 設定オプション形式… 5 4. パケット形式… 6 4.1の挑戦と応答… 7 4.2の成功と失敗… 9 セキュリティ問題… 10の承認… 11の参照箇所… 12 連絡します。 12
Simpson [Page i] RFC 1994 PPP CHAP August 1996
シンプソン[ページi]RFC1994PPP CHAP1996年8月
1. Introduction
1. 序論
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.
ポイントツーポイント接続の上でコミュニケーションを確立して、PPPリンクの各端は、最初に、Link特権階級段階の間、データ・リンクを構成するためにパケットをLCPに送らなければなりません。 リンクが設立された後に、PPPはNetwork-層のプロトコルフェーズに続く前に、任意のAuthenticationフェーズに備えます。
By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase.
デフォルトで、認証は義務的ではありません。 リンクの認証が望まれているなら、実装はLink特権階級段階の間、Authentication-プロトコルConfiguration Optionを指定しなければなりません。
These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server via switched circuits or dial-up lines, but might be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations.
これらの認証プロトコルは、使用のために主として交換回線網かダイヤルアップ系列でPPPネットワークサーバに接続するホストとルータで意図しますが、また、専用リンクに付けられるかもしれません。 サーバはネットワーク層交渉にオプションの品揃えにおける、接続ホストかルータの識別を使用できます。
This document defines a PPP authentication protocol. The Link Establishment and Authentication phases, and the Authentication- Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1].
このドキュメントはPPP認証プロトコルを定義します。 Link特権階級、Authenticationフェーズ、およびAuthenticationプロトコルConfiguration OptionはPointからポイントへのプロトコル(PPP)[1]で定義されます。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
「推薦される」というSHOULD This単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
5月のThis単語、または「任意である」という形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
Simpson [Page 1] RFC 1994 PPP CHAP August 1996
シンプソン[1ページ]RFC1994pppは1996年8月にひびが切れます。
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
authenticator
The end of the link requiring the authentication. The
authenticator specifies the authentication protocol to be
used in the Configure-Request during Link Establishment
phase.
固有識別文字、認証を必要とするリンクの端。 固有識別文字は、Link特権階級段階の間、Configure-要求で使用されるために認証プロトコルを指定します。
peer The other end of the point-to-point link; the end which is
being authenticated by the authenticator.
他が終わらせるポイントツーポイント接続の同輩。 固有識別文字によって認証されている終わり。
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Challenge-Handshake Authentication Protocol
2. チャレンジ・ハンドシェイク認証プロトコル
The Challenge-Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment, and MAY be repeated anytime after the link has been established.
チャレンジ・ハンドシェイク認証プロトコル(CHAP)は、3ウェイ握手を使用することで同輩のアイデンティティについて定期的に確かめるのに使用されます。 これを初期のリンク設立のときにして、リンクを設立した後にいつでも繰り返すかもしれません。
1. After the Link Establishment phase is complete, the
authenticator sends a "challenge" message to the peer.
1. Link特権階級フェーズが完全になった後に、固有識別文字は「挑戦」メッセージを同輩に送ります。
2. The peer responds with a value calculated using a "one-way
hash" function.
2. 値が計算されている状態で、同輩は、「一方向ハッシュ」機能を使用することで応じます。
3. The authenticator checks the response against its own
calculation of the expected hash value. If the values match,
the authentication is acknowledged; otherwise the connection
SHOULD be terminated.
3. 固有識別文字はそれ自身の予想されたハッシュ値の計算に対して応答をチェックします。 値が合っているなら、認証は承諾されます。 そうでなければ、接続SHOULD、終えられてください。
4. At random intervals, the authenticator sends a new challenge to
the peer, and repeats steps 1 to 3.
4. 間隔であり、固有識別文字は、無作為に、新しい挑戦を同輩に送って、ステップ1〜3を繰り返します。
Simpson [Page 2] RFC 1994 PPP CHAP August 1996
シンプソン[2ページ]RFC1994pppは1996年8月にひびが切れます。
2.1. Advantages
2.1. 利点
CHAP provides protection against playback attack by the peer through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges.
CHAPは増加して変化している識別子と可変挑戦価値の使用で同輩による再生攻撃に対する保護を提供します。 繰り返された挑戦の使用が暴露の時間をどんなただ一つの攻撃にも制限することを意図します。 頻度のコントロールと挑戦のタイミングには固有識別文字があります。
This authentication method depends upon a "secret" known only to the authenticator and that peer. The secret is not sent over the link.
この認証方法は固有識別文字とその同輩だけにおいて知られている「秘密」によります。 秘密はリンクの上に送られません。
Although the authentication is only one-way, by negotiating CHAP in both directions the same secret set may easily be used for mutual authentication.
認証は一方向であるだけですが、両方の方向とCHAPを交渉することによって、同じ秘密のセットは互いの認証に容易に使用されるかもしれません。
Since CHAP may be used to authenticate many different systems, name fields may be used as an index to locate the proper secret in a large table of secrets. This also makes it possible to support more than one name/secret pair per system, and to change the secret in use at any time during the session.
CHAPが多くの異系統を認証するのに使用されるかもしれないので、名前欄は秘密の大きいテーブルで適切な秘密の場所を見つけるのにインデックスとして使用されるかもしれません。 また、これで、1システムあたり名前/秘密の1組以上をサポートして、いつでもセッションの間、使用中の秘密を変更させるのは可能になります。
2.2. Disadvantages
2.2. 不都合
CHAP requires that the secret be available in plaintext form. Irreversably encrypted password databases commonly available cannot be used.
CHAPは、秘密が平文フォームで利用可能であることを必要とします。 一般的に利用可能なIrreversably暗号化されたパスワードデータベースを使用できません。
It is not as useful for large installations, since every possible secret is maintained at both ends of the link.
あらゆる可能な秘密がリンクの両端で維持されるので、それは大きいインストールの役に立ちません。
Implementation Note: To avoid sending the secret over other links
in the network, it is recommended that the challenge and response
values be examined at a central server, rather than each network
access server. Otherwise, the secret SHOULD be sent to such
servers in a reversably encrypted form. Either case requires a
trusted relationship, which is outside the scope of this
specification.
実装注意: ネットワークで他のリンクの上に秘密を送るのを避けるために、挑戦と応答値がそれぞれアクセス・サーバーそうでなければ秘密のSHOULDをネットワークでつなぐよりセントラルサーバーでむしろ調べられるのは、お勧めです。reversablyの暗号化されたフォームでそのようなサーバに送ってください。 どちらのケースも信じられた関係を必要とします。(この仕様の範囲の外にそれは、あります)。
Simpson [Page 3] RFC 1994 PPP CHAP August 1996
シンプソン[3ページ]RFC1994pppは1996年8月にひびが切れます。
2.3. Design Requirements
2.3. 設計の品質
The CHAP algorithm requires that the length of the secret MUST be at least 1 octet. The secret SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least the length of the hash value for the hashing algorithm chosen (16 octets for MD5). This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks.
CHAPアルゴリズムは、秘密の長さが少なくとも1つの八重奏であるに違いないことを必要とします。 秘密のSHOULDは少なくとも同じくらい大きく、適切なパスワードとして「蹄-可能」します。 秘密が(MD5のための16の八重奏)が選ばれた論じ尽くすアルゴリズムのためのハッシュ値の長さであることが好ましいです。 これは、秘密が徹底的な検索攻撃に対する保護を提供するように十分大きい範囲を確実にするためのものです。
The one-way hash algorithm is chosen such that it is computationally infeasible to determine the secret from the known challenge and response values.
一方向ハッシュアルゴリズムが選ばれているので、知られている挑戦と応答値からの秘密を決定するのは計算上実行不可能です。
Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness.
各挑戦はSHOULDを評価します。ユニークであってください、同じ秘密に関連した挑戦価値の反復は、攻撃者が以前に妨害された応答で返答することを許可するでしょう、したがって。 同じ秘密がサーバが異種の地理的な領域にある状態で認証するのにおいて使用されているかもしれないと予想されて、挑戦SHOULDはグローバルで時のユニークさを示します。
Each challenge value SHOULD also be unpredictable, least an attacker trick a peer into responding to a predicted future challenge, and then use the response to masquerade as that peer to an authenticator.
SHOULDがふりをするのにまた、予測できません、最も最少に、攻撃者が同輩が予測された今後の挑戦に応じるようにだますということであり、次に応答を使用する固有識別文字としてじっと見るそれぞれの挑戦値。
Although protocols such as CHAP are incapable of protecting against realtime active wiretapping attacks, generation of unique unpredictable challenges can protect against a wide range of active attacks.
CHAPなどのプロトコルはリアルタイムでの活発な盗聴攻撃から守ることができませんが、ユニークな予測できない挑戦の世代はさまざまな活発な攻撃から守ることができます。
A discussion of sources of uniqueness and probability of divergence is included in the Magic-Number Configuration Option [1].
ユニークさの源と分岐の確率の議論はマジック数のConfiguration Option[1]に含まれています。
Simpson [Page 4] RFC 1994 PPP CHAP August 1996
シンプソン[4ページ]RFC1994pppは1996年8月にひびが切れます。
3. Configuration Option Format
3. 設定オプション形式
A summary of the Authentication-Protocol Configuration Option format to negotiate the Challenge-Handshake Authentication Protocol is shown below. The fields are transmitted from left to right.
Configuration Optionがチャレンジ・ハンドシェイク認証プロトコルを交渉するためにフォーマットするAuthentication-プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム| +-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
5
5
Authentication-Protocol
認証プロトコル
c223 (hex) for Challenge-Handshake Authentication Protocol.
チャレンジ・ハンドシェイク認証プロトコルのためのc223(十六進法)。
Algorithm
アルゴリズム
The Algorithm field is one octet and indicates the authentication
method to be used. Up-to-date values are specified in the most
recent "Assigned Numbers" [2]. One value is required to be
implemented:
Algorithm分野は、1つの八重奏であり、使用されるべき認証方法を示します。 最新の値は最新の「規定番号」[2]で指定されます。 1つの値が実装されるのに必要です:
5 CHAP with MD5 [3]
MD5をもっている5やつ[3]
Simpson [Page 5] RFC 1994 PPP CHAP August 1996
シンプソン[5ページ]RFC1994pppは1996年8月にひびが切れます。
4. Packet Format
4. パケット・フォーマット
Exactly one Challenge-Handshake Authentication Protocol packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex c223 (Challenge-Handshake Authentication Protocol). A summary of the CHAP packet format is shown below. The fields are transmitted from left to right.
ちょうど1つのチャレンジ・ハンドシェイク認証プロトコルパケットがプロトコル分野がタイプ十六進法c223(チャレンジ・ハンドシェイク認証プロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。 CHAPパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
The Code field is one octet and identifies the type of CHAP
packet. CHAP Codes are assigned as follows:
Code分野は、1つの八重奏であり、CHAPパケットのタイプを特定します。 CHAP Codesは以下の通り割り当てられます:
1 Challenge
2 Response
3 Success
4 Failure
1 挑戦2応答3成功4失敗
Identifier
識別子
The Identifier field is one octet and aids in matching challenges,
responses and replies.
Identifier分野は、合っている挑戦、応答、および回答で1つの八重奏と援助です。
Length
長さ
The Length field is two octets and indicates the length of the
CHAP packet including the Code, Identifier, Length and Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and should be ignored on
reception.
Length分野は、2つの八重奏であり、Code、Identifier、Length、およびData分野を含むCHAPパケットの長さを示します。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Data
データ
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Data分野はゼロであるか以上が八重奏です。 Data分野の形式はCode分野のそばで決定しています。
Simpson [Page 6] RFC 1994 PPP CHAP August 1996
シンプソン[6ページ]RFC1994pppは1996年8月にひびが切れます。
4.1. Challenge and Response
4.1. 挑戦と応答
Description
記述
The Challenge packet is used to begin the Challenge-Handshake
Authentication Protocol. The authenticator MUST transmit a CHAP
packet with the Code field set to 1 (Challenge). Additional
Challenge packets MUST be sent until a valid Response packet is
received, or an optional retry counter expires.
Challengeパケットは、チャレンジ・ハンドシェイク認証プロトコルを始めるのに使用されます。 固有識別文字はCode分野セットで1(挑戦)にCHAPパケットを伝えなければなりません。 有効なResponseパケットが受け取られているまで追加Challengeパケットを送らなければならない、さもなければ、任意の再試行カウンタは期限が切れます。
A Challenge packet MAY also be transmitted at any time during the
Network-Layer Protocol phase to ensure that the connection has not
been altered.
また、Challengeパケットは、いつでも、接続が変更されていないのを保証するためにNetwork-層のプロトコル段階の間、伝えられるかもしれません。
The peer SHOULD expect Challenge packets during the Authentication
phase and the Network-Layer Protocol phase. Whenever a Challenge
packet is received, the peer MUST transmit a CHAP packet with the
Code field set to 2 (Response).
同輩SHOULDはAuthentication段階とNetwork-層のプロトコル段階の間、Challengeパケットを予想します。 Challengeパケットが受け取られているときはいつも、同輩はCode分野セットで2(応答)にCHAPパケットを伝えなければなりません。
Whenever a Response packet is received, the authenticator compares
the Response Value with its own calculation of the expected value.
Based on this comparison, the authenticator MUST send a Success or
Failure packet (described below).
Responseパケットが受け取られているときはいつも、固有識別文字はそれ自身の期待値の計算とResponse Valueを比べます。 この比較に基づいて、固有識別文字はパケット(以下で、説明される)をSuccessかFailureに送らなければなりません。
Implementation Notes: Because the Success might be lost, the
authenticator MUST allow repeated Response packets during the
Network-Layer Protocol phase after completing the
Authentication phase. To prevent discovery of alternative
Names and Secrets, any Response packets received having the
current Challenge Identifier MUST return the same reply Code
previously returned for that specific Challenge (the message
portion MAY be different). Any Response packets received
during any other phase MUST be silently discarded.
実装注意: Successがなくされるかもしれないので、Authenticationフェーズを完成した後に、固有識別文字はNetwork-層のプロトコル段階の間、繰り返されたResponseパケットを許容しなければなりません。 代替のNamesとシークレットの発見を防ぐために、現在のChallenge Identifierを持ちながら受け取られたどんなResponseパケットも以前にその特定のChallengeのために返された同じ回答Codeを返さなければなりません(メッセージ部分は異なっているかもしれません)。 静かにいかなる他の段階の間にも受け取られたどんなResponseパケットも捨てなければなりません。
When the Failure is lost, and the authenticator terminates the
link, the LCP Terminate-Request and Terminate-Ack provide an
alternative indication that authentication failed.
Failureが無くなって、固有識別文字がリンクを終えると、LCP Terminate-要求とTerminate-Ackは認証が失敗したという代替の指示を提供します。
Simpson [Page 7] RFC 1994 PPP CHAP August 1996
シンプソン[7ページ]RFC1994pppは1996年8月にひびが切れます。
A summary of the Challenge and Response packet format is shown below. The fields are transmitted from left to right.
ChallengeとResponseパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値サイズ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 命名します。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 for Challenge;
1 挑戦のために。
2 for Response.
2 応答のために。
Identifier
識別子
The Identifier field is one octet. The Identifier field MUST be
changed each time a Challenge is sent.
Identifier分野は1つの八重奏です。 Challengeを送るたびにIdentifier分野を変えなければなりません。
The Response Identifier MUST be copied from the Identifier field
of the Challenge which caused the Response.
Responseを引き起こしたChallengeのIdentifier分野からResponse Identifierをコピーしなければなりません。
Value-Size
値サイズ
This field is one octet and indicates the length of the Value
field.
この分野は、1つの八重奏であり、Value分野の長さを示します。
Value
値
The Value field is one or more octets. The most significant octet
is transmitted first.
Value分野は1つ以上の八重奏です。 最も重要な八重奏は最初に、伝えられます。
The Challenge Value is a variable stream of octets. The
importance of the uniqueness of the Challenge Value and its
relationship to the secret is described above. The Challenge
Value MUST be changed each time a Challenge is sent. The length
of the Challenge Value depends upon the method used to generate
the octets, and is independent of the hash algorithm used.
Challenge Valueは八重奏の可変ストリームです。 Challenge Valueのユニークさと秘密とのその関係の重要性は上で説明されます。 Challengeを送るたびにChallenge Valueを変えなければなりません。 Challenge Valueの長さは、八重奏を生成するのに使用されるメソッドによって、ハッシュアルゴリズムの如何にかかわらず使用されます。
The Response Value is the one-way hash calculated over a stream of
octets consisting of the Identifier, followed by (concatenated
with) the "secret", followed by (concatenated with) the Challenge
Value. The length of the Response Value depends upon the hash
algorithm used (16 octets for MD5).
Response ValueはIdentifierから成る八重奏のストリームに関して計算された、一方向ハッシュです、続かれて(連結される、)、続かれる「秘密」、(連結される、)、Challenge Value。 Response Valueの長さは使用されるハッシュアルゴリズム(MD5のための16の八重奏)に依存します。
Simpson [Page 8] RFC 1994 PPP CHAP August 1996
シンプソン[8ページ]RFC1994pppは1996年8月にひびが切れます。
Name
名前
The Name field is one or more octets representing the
identification of the system transmitting the packet. There are
no limitations on the content of this field. For example, it MAY
contain ASCII character strings or globally unique identifiers in
ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
The size is determined from the Length field.
Name分野はパケットを伝えるシステムの識別を表す1つ以上の八重奏です。 制限が全くこの分野の内容にありません。 例えば、それはASN.1構文によるASCII文字列かグローバルにユニークな識別子を含むかもしれません。 NameはNULであるべきではありませんかCR/LFが終わりました。 サイズはLength分野から決定しています。
4.2. Success and Failure
4.2. 成功と失敗
Description
記述
If the Value received in a Response is equal to the expected
value, then the implementation MUST transmit a CHAP packet with
the Code field set to 3 (Success).
Responseに受け取られたValueが期待値と等しいなら、実装はCode分野セットで3(成功)にCHAPパケットを伝えなければなりません。
If the Value received in a Response is not equal to the expected
value, then the implementation MUST transmit a CHAP packet with
the Code field set to 4 (Failure), and SHOULD take action to
terminate the link.
Responseに受け取られたValueが期待値と等しくないなら、実装はCode分野セットで4(失敗)にCHAPパケットを伝えなければなりません、そして、SHOULDはリンクを終えるために行動を取ります。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
SuccessとFailureパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
3 for Success;
3 成功のために。
4 for Failure.
4 失敗のために。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Response which caused this reply.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 この回答を引き起こしたResponseのIdentifier分野からIdentifier分野をコピーしなければなりません。
Simpson [Page 9] RFC 1994 PPP CHAP August 1996
シンプソン[9ページ]RFC1994pppは1996年8月にひびが切れます。
Message
メッセージ
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
Message分野は、ゼロか、より多くの八重奏です、そして、内容は実装に依存しています。 それは、人間読み込み可能であることを意図して、プロトコルの操作に影響してはいけません。 メッセージが「ディスプレイ-可能」ASCII文字32〜126小数を含むのは、お勧めです。 他の文字集合への拡大のためのメカニズムは今後の研究の話題です。 サイズはLength分野から決定しています。
Security Considerations
セキュリティ問題
Security issues are the primary topic of this RFC.
安全保障問題はこのRFCのプライマリ話題です。
The interaction of the authentication protocols within PPP are highly implementation dependent. This is indicated by the use of SHOULD throughout the document.
PPPの中の認証プロトコルの相互作用は実装に非常に依存しています。 これはドキュメント中にSHOULDの使用で示されます。
For example, upon failure of authentication, some implementations do not terminate the link. Instead, the implementation limits the kind of traffic in the Network-Layer Protocols to a filtered subset, which in turn allows the user opportunity to update secrets or send mail to the network administrator indicating a problem.
例えば、認証の失敗では、いくつかの実装はリンクを終えません。 代わりに、実装はNetwork-層のプロトコルのトラフィックの種類をフィルターにかけることの部分集合に制限します。(順番に、それは、問題を示すネットワーク管理者に秘密をアップデートするか、またはメールを送るユーザの機会を許容します)。
There is no provision for re-tries of failed authentication. However, the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. It is recommended that any counters used for authentication failure not be reset until after successful authentication, or subsequent termination of the failed link.
失敗した認証の再試行への支給が全くありません。 しかしながら、LCP州のマシンはいつでも、認証プロトコルを再交渉して、その結果、新しい試みを許すことができます。 認証失敗に使用されるどんなカウンタもうまくいっている認証の後のリセット、または失敗したリンクのその後の終了でないことがお勧めです。
There is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated.
認証が全二重であるか同じプロトコルが両方の方向に使用されるという要件が全くありません。 異なったプロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定のプロトコルによるでしょう。
The secret SHOULD NOT be the same in both directions. This allows an attacker to replay the peer's challenge, accept the computed response, and use that response to authenticate.
秘密のSHOULD NOT、両方の方向と同じにしてください。 これで、攻撃者は、同輩の挑戦を再演して、計算された応答を受け入れて、認証するその応答を使用します。
In practice, within or associated with each PPP server, there is a
database which associates "user" names with authentication
information ("secrets"). It is not anticipated that a particular
named user would be authenticated by multiple methods. This would
make the user vulnerable to attacks which negotiate the least secure
method from among a set (such as PAP rather than CHAP). If the same
中では、中で練習してください。さもないと、それぞれのPPPサーバに関連していて、認証情報(「秘密」)の「ユーザ」名を関連づけるデータベースがあります。 特定の命名されたユーザが複数のメソッドで認証されると予期されません。 これで、ユーザはセット(CHAPよりむしろPAPなどの)から最も安全でないメソッドを交渉する攻撃に被害を受け易くなるでしょう。 同じ
Simpson [Page 10] RFC 1994 PPP CHAP August 1996
シンプソン[10ページ]RFC1994pppは1996年8月にひびが切れます。
secret was used, PAP would reveal the secret to be used later with CHAP.
秘密は使用されて、PAPは、後でCHAPと共に使用されるために秘密を明らかにするでしょう。
Instead, for each user name there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct user names SHOULD be employed, each of which identifies exactly one authentication method.
代わりに、それぞれのユーザ名のために、まさにそのユーザ名を認証するのに使用される1つのメソッドのしるしがあるべきです。 ユーザが、異なった事情、当時の異なったユーザ名の下における異なった認証方法の使用をSHOULDにする必要があるなら、どれがまさに1つの認証方法を特定するかについてそれぞれ使われてください。
Passwords and other secrets should be stored at the respective ends such that access to them is as limited as possible. Ideally, the secrets should only be accessible to the process requiring access in order to perform the authentication.
パスワードと他の秘密がそれぞれの終わりに保存されるべきであるので、それらへのアクセスはできるだけ限られています。 理想的に、秘密は単に認証を実行するためにアクセスを必要とするプロセスにアクセス可能であるべきです。
The secrets should be distributed with a mechanism that limits the number of entities that handle (and thus gain knowledge of) the secret. Ideally, no unauthorized person should ever gain knowledge of the secrets. Such a mechanism is outside the scope of this specification.
そして、秘密がそれが扱う実体の数を制限するメカニズムで分配されるべきである、(その結果、知識を得る、)、秘密。 理想的に、どんな権限のない人も秘密に関する知識を獲得するべきではありません。 この仕様の範囲の外にそのようなメカニズムはあります。
Acknowledgements
承認
David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
handshake at SDC when designing one of the protocols for a "secure"
network in the mid-1970s. Tom Bearson built a prototype Sytek
product ("Poloneous"?) on the challenge-response notion in the 1982-
83 timeframe. Another variant is documented in the various IBM SNA
manuals. Yet another variant was implemented by Karl Auerbach in the
Telebit NetBlazer circa 1991.
1970年代の半ば「安全な」ネットワークのためにプロトコルの1つを設計するとき、デヴィッド・コーフマン、フランク・ハインリヒ、およびカール・アウアーバックはSDCで挑戦握手を使用しました。 トムBearsonはプロトタイプSytek製品を造りました。(「1982- 83時間枠のチャレンジレスポンス概念のPoloneous"?)。」 別の異形は様々なIBM SNAマニュアルに記録されます。 さらに別の異形は1991年頃にテレビットNetBlazerのカール・アウアーバックによって実装されました。
Kim Toms and Barney Wolff provided useful critiques of earlier versions of this document.
キム・トムズとバーニー・ヴォルフはこのドキュメントの以前のバージョンの役に立つ批評を提供しました。
Special thanks to Dave Balenson, Steve Crocker, James Galvin, and Steve Kent, for their extensive explanations and suggestions. Now, if only we could get them to agree with each other.
彼らの大規模な説明と提案のためのデーヴBalenson、スティーブ・クロッカー、ジェームス・ガルビン、およびスティーブ・ケントへの特別な感謝。 現在、私たちが彼らを互いに同意させることさえできれば、よいでしょうに。
Simpson [Page 11] RFC 1994 PPP CHAP August 1996
シンプソン[11ページ]RFC1994pppは1996年8月にひびが切れます。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DayDreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[2] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
MIT Laboratory for Computer Science and RSA Data Security,
Inc., RFC 1321, April 1992.
[3]、Rivestである、R.とS.Dusseと「MD5メッセージダイジェストアルゴリズム」とMITコンピュータサイエンス研究所とRSA Data Security Inc.、RFC1321、1992年4月
Contacts
接触
Comments should be submitted to the ietf-ppp@merit.edu mailing list.
ietf-ppp@merit.edu メーリングリストにコメントを提出するべきです。
This document was reviewed by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chair:
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって再検討されました。 現在のいすを通してワーキンググループに連絡できます:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
karl@MorningStar.com
karl@Ascend.com
karl@MorningStar.com karl@Ascend.com
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
wsimpson@UMich.edu wsimpson@GreenDragon.com(都合のよい)です。
Simpson [Page 12]
シンプソン[12ページ]
一覧
スポンサーリンク
