RFC1334 日本語訳
1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. (Format: TXT=33248 bytes) (Obsoleted by RFC1994) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Lloyd
Request for Comments: 1334 L&A
W. Simpson
Daydreamer
October 1992
コメントを求めるワーキンググループB.ロイドの要求をネットワークでつないでください: 1334年のLとW.シンプソン空想家1992年10月
PPP Authentication Protocols
ppp認証プロトコル
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. 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.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でNetwork Layerがプロトコル情報であるとカプセル化する標準方法を提供します。 また、PPPは広げることができるLink Controlプロトコルを定義します。(それは、Network Layerプロトコルがリンクの上に伝わるのを許容する前に同輩を認証するためのAuthenticationプロトコルの交渉を許します)。
This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このドキュメントはAuthenticationのために2つのプロトコルを定義します: パスワード認証プロトコルと挑戦握手認証は議定書を作ります。 このメモはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 このメモのコメントを ietf-ppp@ucdavis.edu メーリングリストに提出するべきです。
Table of Contents
目次
1. Introduction ............................................... 2 1.1 Specification Requirements ................................. 2 1.2 Terminology ................................................ 3 2. Password Authentication Protocol ............................ 3 2.1 Configuration Option Format ................................ 4 2.2 Packet Format .............................................. 5 2.2.1 Authenticate-Request ..................................... 5 2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7 3. Challenge-Handshake Authentication Protocol.................. 8 3.1 Configuration Option Format ................................ 9 3.2 Packet Format .............................................. 10 3.2.1 Challenge and Response ................................... 11 3.2.2 Success and Failure ...................................... 13
1. 序論… 2 1.1 仕様要件… 2 1.2用語… 3 2. パスワード認証プロトコル… 3 2.1 設定オプション形式… 4 2.2 パケット形式… 5 2.2 .1 要求を認証します… 5 2.2 .2 Ackを認証してNakを認証します… 7 3. 挑戦握手認証プロトコル… 8 3.1 設定オプション形式… 9 3.2 パケット形式… 10 3.2 .1の挑戦と応答… 11 3.2 .2の成功と失敗… 13
Lloyd & Simpson [Page 1] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[1ページ]RFC1334ppp認証1992年10月
SECURITY CONSIDERATIONS ........................................ 14 REFERENCES ..................................................... 15 ACKNOWLEDGEMENTS ............................................... 16 CHAIR'S ADDRESS ................................................ 16 AUTHOR'S ADDRESS ............................................... 16
セキュリティ問題… 14の参照箇所… 15の承認… 16 議長のアドレス… 16作者のアドレス… 16
1. Introduction
1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating datagrams over serial links.
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
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 the PPP authentication protocols. 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 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単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
Lloyd & Simpson [Page 2] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[2ページ]RFC1334ppp認証1992年10月
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 should 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つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
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. Password Authentication Protocol
2. パスワード認証プロトコル
The Password Authentication Protocol (PAP) provides a simple method for the peer to establish its identity using a 2-way handshake. This is done only upon initial link establishment.
パスワード認証プロトコル(PAP)は同輩が2ウェイ握手を使用することでアイデンティティを確立する簡単なメソッドを提供します。 単に初期のリンク設立のときにこれをします。
After the Link Establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated.
Link特権階級フェーズが完全になった後に、認証が承認されているか、または接続が終えられるまで、Id/パスワード組は同輩によって繰り返して固有識別文字に送られます。
PAP is not a strong authentication method. Passwords are sent over the circuit "in the clear", and there is no protection from playback
PAPは強い認証方法ではありません。 「明確」の回路の上にパスワードを送ります、そして、再生からのノー・プロテクションがあります。
Lloyd & Simpson [Page 3] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[3ページ]RFC1334ppp認証1992年10月
or repeated trial and error attacks. The peer is in control of the frequency and timing of the attempts.
または、繰り返された試行錯誤は攻撃されます。 頻度のコントロールと試みのタイミングには同輩がいます。
Any implementations which include a stronger authentication method (such as CHAP, described below) MUST offer to negotiate that method prior to PAP.
より強い認証方法(以下で説明されたCHAPなどの)を含んでいるどんな実装も、PAPの前でそのメソッドを交渉すると申し出なければなりません。
This authentication method is most appropriately used where a plaintext password must be available to simulate a login at a remote host. In such use, this method provides a similar level of security to the usual user login at the remote host.
この認証方法は平文パスワードがリモートホストでログインをシミュレートするために入手できなければならないところで最も適切に使用されます。 そのような使用で、このメソッドはリモートホストで普通のユーザログインに同じ水準のセキュリティを提供します。
Implementation Note: It is possible to limit the exposure of the
plaintext password to transmission over the PPP link, and avoid
sending the plaintext password over the entire network. When the
remote host password is kept as a one-way transformed value, and
the algorithm for the transform function is implemented in the
local server, the plaintext password SHOULD be locally transformed
before comparison with the transformed password from the remote
host.
実装注意: PPPリンクの上に平文パスワードの暴露をトランスミッションに制限して、全体のネットワークの上で平文パスワードを送るのを避けるのは可能です。 リモートホストパスワードが保たれたら、一方向変成している値、および機能がローカルサーバ、平文パスワードSHOULDで実装される変換のためのアルゴリズムとして、リモートホストからの変成しているパスワードとの比較の前に局所的に変えられてください。
2.1. Configuration Option Format
2.1. 設定オプション形式
A summary of the Authentication-Protocol Configuration Option format to negotiate the Password Authentication Protocol is shown below. The fields are transmitted from left to right.
Configuration Optionがパスワード認証プロトコルを交渉するためにフォーマットするAuthentication-プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
3
Length
長さ
4
4
Authentication-Protocol
認証プロトコル
c023 (hex) for Password Authentication Protocol.
パスワード認証プロトコルのためのc023(十六進法)。
Data
データ
There is no Data field.
Data分野が全くありません。
Lloyd & Simpson [Page 4] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[4ページ]RFC1334ppp認証1992年10月
2.2. Packet Format
2.2. パケット・フォーマット
Exactly one Password Authentication Protocol packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex c023 (Password Authentication Protocol). A summary of the PAP packet format is shown below. The fields are transmitted from left to right.
ちょうど1つのパスワード認証プロトコルパケットがプロトコル分野がタイプ十六進法c023(パスワード認証プロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。 PAPパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Code
コード
The Code field is one octet and identifies the type of PAP packet.
PAP Codes are assigned as follows:
Code分野は、1つの八重奏であり、PAPパケットのタイプを特定します。 PAP Codesは以下の通り割り当てられます:
1 Authenticate-Request
2 Authenticate-Ack
3 Authenticate-Nak
1、要求を認証している2、Ackを認証している3、Nakを認証します。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。
Length
長さ
The Length field is two octets and indicates the length of the PAP
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分野を含むPAPパケットの長さを示します。 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分野のそばで決定しています。
2.2.1. Authenticate-Request
2.2.1. 要求を認証します。
Description
記述
The Authenticate-Request packet is used to begin the Password
Authentication Protocol. The link peer MUST transmit a PAP packet
Authenticate-リクエスト・パケットは、パスワード認証プロトコルを始めるのに使用されます。 リンク同輩はPAPパケットを伝えなければなりません。
Lloyd & Simpson [Page 5] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[5ページ]RFC1334ppp認証1992年10月
with the Code field set to 1 (Authenticate-Request) during the
Authentication phase. The Authenticate-Request packet MUST be
repeated until a valid reply packet is received, or an optional
retry counter expires.
Codeと共に、分野は1つのAuthenticationの間の(要求を認証します)のフェーズにセットしました。 有効な回答パケットが受け取られているか、または任意の再試行カウンタが期限が切れるまで、Authenticate-リクエスト・パケットを繰り返さなければなりません。
The authenticator SHOULD expect the peer to send an Authenticate-
Request packet. Upon reception of an Authenticate-Request packet,
some type of Authenticate reply (described below) MUST be
returned.
固有識別文字SHOULDは、同輩がAuthenticateリクエスト・パケットを送ると予想します。 Authenticate-リクエスト・パケットのレセプションでは、タイプのAuthenticate回答(以下で、説明される)を返さなければなりません。
Implementation Note: Because the Authenticate-Ack might be
lost, the authenticator MUST allow repeated Authenticate-
Request packets after completing the Authentication phase.
Protocol phase MUST return the same reply Code returned when
the Authentication phase completed (the message portion MAY be
different). Any Authenticate-Request packets received during
any other phase MUST be silently discarded.
実装注意: Authenticate-Ackがなくされるかもしれないので、Authenticationフェーズを完成した後に、固有識別文字は繰り返されたAuthenticateリクエスト・パケットを許容しなければなりません。 プロトコルフェーズはAuthenticationフェーズが(部分が異なるかもしれないというメッセージ)を完成したとき返された同じ回答Codeを返さなければなりません。 静かにいかなる他の段階の間にも受け取られたどんなAuthenticate-リクエスト・パケットも捨てなければなりません。
When the Authenticate-Nak is lost, and the authenticator
terminates the link, the LCP Terminate-Request and Terminate-
Ack provide an alternative indication that authentication
failed.
Authenticate-Nakが無くなって、固有識別文字がリンクを終えると、LCP Terminate-要求とTerminate- Ackは認証が失敗したという代替の指示を提供します。
A summary of the Authenticate-Request packet format is shown below. The fields are transmitted from left to right.
Authenticate-リクエスト・パケット形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩IDの長さ| 同輩イド… +-+-+-+-+-+-+-+-+-+-+-+-+ | Passwd-長さ| パスワード… +-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
1 for Authenticate-Request.
1、要求を認証します。
Identifier
識別子
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be changed each time an
Authenticate-Request packet is issued.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 Authenticate-リクエスト・パケットが発行されるたびにIdentifier分野を変えなければなりません。
Lloyd & Simpson [Page 6] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[6ページ]RFC1334ppp認証1992年10月
Peer-ID-Length
同輩IDの長さ
The Peer-ID-Length field is one octet and indicates the length of
the Peer-ID field.
Peer IDの長さの分野は、1つの八重奏であり、Peer-ID分野の長さを示します。
Peer-ID
同輩ID
The Peer-ID field is zero or more octets and indicates the name of
the peer to be authenticated.
Peer-ID分野は、ゼロか、より多くの八重奏であり、認証されるために同輩の名前を示します。
Passwd-Length
Passwd-長さ
The Passwd-Length field is one octet and indicates the length of
the Password field.
Passwd-長さの分野は、1つの八重奏であり、Password分野の長さを示します。
Password
パスワード
The Password field is zero or more octets and indicates the
password to be used for authentication.
Password分野は、ゼロか、より多くの八重奏であり、認証に使用されるためにパスワードを示します。
2.2.2. Authenticate-Ack and Authenticate-Nak
2.2.2. Ackを認証してNakを認証します。
Description
記述
If the Peer-ID/Password pair received in an Authenticate-Request
is both recognizable and acceptable, then the authenticator MUST
transmit a PAP packet with the Code field set to 2 (Authenticate-
Ack).
Authenticate-要求に受け取られたPeer-ID/パスワード組が認識可能であって、かつ許容できるなら、固有識別文字はCode分野セットでPAPパケットを2に伝えなければなりません(Ackを認証してください)。
If the Peer-ID/Password pair received in a Authenticate-Request is
not recognizable or acceptable, then the authenticator MUST
transmit a PAP packet with the Code field set to 3 (Authenticate-
Nak), and SHOULD take action to terminate the link.
Authenticate-要求に受け取られたPeer-ID/パスワード組が認識可能でなく、また許容できないなら、固有識別文字はCode分野セットでPAPパケットを3に伝えなければなりません、そして、(Nakを認証してください)SHOULDはリンクを終えるために行動を取ります。
A summary of the Authenticate-Ack and Authenticate-Nak packet format is shown below. The fields are transmitted from left to right.
Authenticate-AckとAuthenticate-Nakパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エムエスジー長さ| メッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
2 for Authenticate-Ack;
2、Ackを認証します。
Lloyd & Simpson [Page 7] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[7ページ]RFC1334ppp認証1992年10月
3 for Authenticate-Nak.
3、Nakを認証します。
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 Authenticate-Request which caused this
reply.
Identifier分野は、合っている要求と回答で1つの八重奏と援助です。 この回答を引き起こしたAuthenticate-要求のIdentifier分野からIdentifier分野をコピーしなければなりません。
Msg-Length
エムエスジー長さ
The Msg-Length field is one octet and indicates the length of the
Message field.
エムエスジー長さの分野は、1つの八重奏であり、Message分野の長さを示します。
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.
Message分野は、ゼロか、より多くの八重奏です、そして、内容は実装に依存しています。 それは、人間読み込み可能であることを意図して、プロトコルの操作に影響してはいけません。 メッセージが「ディスプレイ-可能」ASCII文字32〜126小数を含むのは、お勧めです。 他の文字集合への拡大のためのメカニズムは今後の研究の話題です。
3. Challenge-Handshake Authentication Protocol
3. チャレンジ・ハンドシェイク認証プロトコル
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ウェイ握手を使用することで同輩のアイデンティティについて定期的に確かめるのに使用されます。 これを初期のリンク設立のときにして、リンクを設立した後にいつでも繰り返すかもしれません。
After the Link Establishment phase is complete, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated using a "one-way hash" function. 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.
Link特権階級フェーズが完全になった後に、固有識別文字は「挑戦」メッセージを同輩に送ります。 値が計算されている状態で、同輩は、「一方向ハッシュ」機能を使用することで応じます。 固有識別文字はそれ自身の予想されたハッシュ値の計算に対して応答をチェックします。 値が合っているなら、認証は承諾されます。 そうでなければ、接続SHOULD、終えられてください。
CHAP provides protection against playback attack 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. This method is most likely used where the same secret is easily accessed from both ends of the link.
この認証方法は固有識別文字とその同輩だけにおいて知られている「秘密」によります。 秘密はリンクの上に送られません。 このメソッドはたぶん同じ秘密がリンクの両端から容易にアクセスされるところで使用されます。
Lloyd & Simpson [Page 8] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[8ページ]RFC1334ppp認証1992年10月
Implementation Note: CHAP requires that the secret be available in
plaintext form. 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.
実装注意: CHAPは、秘密が平文フォームで利用可能であることを必要とします。 ネットワークで他のリンクの上に秘密を送るのを避けるために、挑戦と応答値がそれぞれアクセス・サーバーそうでなければ秘密のSHOULDをネットワークでつなぐよりセントラルサーバーでむしろ調べられるのは、お勧めです。reversablyの暗号化されたフォームでそのようなサーバに送ってください。
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.
一方向ハッシュアルゴリズムが選ばれているので、知られている挑戦と応答値からの秘密を決定するのは計算上実行不可能です。
The challenge value SHOULD satisfy two criteria: uniqueness and unpredictability. 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. 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. 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.
挑戦価値のSHOULDは2つの評価基準を満たします: ユニークさと予測不可能性。 各挑戦はSHOULDを評価します。ユニークであってください、同じ秘密に関連した挑戦価値の反復は、攻撃者が以前に妨害された応答で返答することを許可するでしょう、したがって。 同じ秘密がサーバが異種の地理的な領域にある状態で認証するのにおいて使用されているかもしれないと予想されて、挑戦SHOULDはグローバルで時のユニークさを示します。 SHOULDがふりをするのにまた、予測できません、最も最少に、攻撃者が同輩が予測された今後の挑戦に応じるようにだますということであり、次に応答を使用する固有識別文字としてじっと見るそれぞれの挑戦値。 CHAPなどのプロトコルはリアルタイムでの活発な盗聴攻撃から守ることができませんが、ユニークな予測できない挑戦の世代はさまざまな活発な攻撃から守ることができます。
A discussion of sources of uniqueness and probability of divergence is included in the Magic-Number Configuration Option [1].
ユニークさの源と分岐の確率の議論はマジック数のConfiguration Option[1]に含まれています。
3.1. Configuration Option Format
3.1. 設定オプション形式
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-プロトコルの概要は以下に示されます。 野原は左から右まで伝えられます。
Lloyd & Simpson [Page 9] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[9ページ]RFC1334ppp認証1992年10月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 認証プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム| +-+-+-+-+-+-+-+-+
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 one-way hash
method to be used. The most up-to-date values of the CHAP
Algorithm field are specified in the most recent "Assigned
Numbers" RFC [2]. Current values are assigned as follows:
Algorithm分野は、1つの八重奏であり、使用されるべき一方向ハッシュメソッドを示します。 CHAP Algorithm分野の最も最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
0-4 unused (reserved)
5 MD5 [3]
0-4 未使用(予約される)の5MD5[3]
3.2. Packet Format
3.2. パケット・フォーマット
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パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Lloyd & Simpson [Page 10] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[10ページ]RFC1334ppp認証1992年10月
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分野のそばで決定しています。
3.2.1. Challenge and Response
3.2.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
Responseパケットが受け取られているときはいつも、固有識別文字は比較されます。
Lloyd & Simpson [Page 11] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[11ページ]RFC1334ppp認証1992年10月
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 Value。 この比較に基づいて、固有識別文字はパケット(以下で、説明される)をSuccessかFailureに送らなければなりません。
Implementation Note: Because the Success might be lost, the
authenticator MUST allow repeated Response packets 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 returned when the Authentication phase completed
(the message portion MAY be different). Any Response packets
received during any other phase MUST be silently discarded.
実装注意: Successがなくされるかもしれないので、Authenticationフェーズを完成した後に、固有識別文字は繰り返されたResponseパケットを許容しなければなりません。 代替のNamesとシークレットの発見を防ぐために、現在のChallenge Identifierを持ちながら受け取られたどんなResponseパケットもAuthenticationフェーズが(部分が異なるかもしれないというメッセージ)を完成したとき返された同じ回答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は認証が失敗したという代替の指示を提供します。
A summary of the Challenge and Response packet format is shown below. The fields are transmitted from left to right.
ChallengeとResponseパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値サイズ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 命名します。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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分野の長さを示します。
Lloyd & Simpson [Page 12] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[12ページ]RFC1334ppp認証1992年10月
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の八重奏)に依存します。
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分野から決定しています。
Since CHAP may be used to authenticate many different systems, the
content of the name field(s) may be used as a key to locate the
proper secret in a database of secrets. This also makes it
possible to support more than one name/secret pair per system.
CHAPが多くの異系統を認証するのに使用されるかもしれないので、名前欄の内容は秘密に関するデータベースの適切な秘密の場所を見つけるのにキーとして使用されるかもしれません。 また、これで、1システムあたり名前/秘密の1組以上をサポートするのは可能になります。
3.2.2. Success and Failure
3.2.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パケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
Lloyd & Simpson [Page 13] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[13ページ]RFC1334ppp認証1992年10月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-
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分野をコピーしなければなりません。
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
失敗した認証の再試行への支給が全くありません。 しかしながら、LCP州のマシンはいつでも、認証プロトコルを再交渉して、その結果、新しい試みを許すことができます。 それはそうです。
Lloyd & Simpson [Page 14] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[14ページ]RFC1334ppp認証1992年10月
recommended that any counters used for authentication failure not
be reset until after successful authentication, or subsequent
termination of the failed link.
認証失敗に使用されるどんなカウンタもうまくいっている認証の後のリセット、または失敗したリンクのその後の終了でないことを勧めました。
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.
認証が全二重であるか同じプロトコルが両方の方向に使用されるという要件が全くありません。 異なったプロトコルが各方向に使用されるのは、完全に許容できます。 これはもちろん交渉された特定のプロトコルによるでしょう。
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).
Instead, for each named user 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 method under
different circumstances, then distinct user names SHOULD be
employed, each of which identifies exactly one authentication
method.
中では、中で練習してください。さもないと、それぞれのPPPサーバに関連していて、認証情報(「秘密」)の「ユーザ」名を関連づけるデータベースがあります。 特定の命名されたユーザが複数のメソッドで認証されると予期されません。 これで、ユーザはセット(CHAPよりむしろPAPなどの)から最も安全でないメソッドを交渉する攻撃に被害を受け易くなるでしょう。 代わりに、それぞれの命名されたユーザのために、まさにそのユーザ名を認証するのに使用される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. It is possible to achieve this with
SNMP Security Protocols [4], but such a mechanism is outside the
scope of this specification.
そして、秘密がそれが扱う実体の数を制限するメカニズムで分配されるべきである、(その結果、知識を得る、)、秘密。 理想的に、どんな権限のない人も秘密に関する知識を獲得するべきではありません。 SNMP Securityプロトコル[4]でこれを達成するのが可能ですが、この仕様の範囲の外にそのようなメカニズムはあります。
Other distribution methods are currently undergoing research and
experimentation. The SNMP Security document also has an excellent
overview of threats to network protocols.
他の分配メソッドは現在、研究と実験を受けることです。 また、SNMP Securityドキュメントには、ネットワーク・プロトコルへの脅威の素晴らしい概要があります。
References
参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
Daydreamer, May 1992.
w.[1] シンプソン、「二地点間プロトコル(ppp)」(RFC1331、空想家)は1992がそうするかもしれません。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1340。
Lloyd & Simpson [Page 15] RFC 1334 PPP Authentication October 1992
ロイドとシンプソン[15ページ]RFC1334ppp認証1992年10月
[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(4月1992)
[4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
Protocols", Trusted Information Systems, Inc., Hughes LAN
Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,
July 1992.
[4] J.とMcCloghrie、K.とJ.デーヴィン、「SNMPセキュリティプロトコル」というガルビンは、情報システムInc.を信じました、ヒューズLANシステムInc.、MITコンピュータサイエンス研究所、RFC1352、1992年7月。
Acknowledgments
承認
Some of the text in this document is taken from RFC 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis.
テキストのいくつかがRFC1172、カーネギーメロン大学のドリュー・パーキンス、およびカリフォルニア大学デイビス校のラスHobbyによって本書では取られます。
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、スティーブ・クロッカー、ジェームス・ガルビン、およびスティーブ・ケントへの特別な感謝。 現在、私たちが彼らを互いに同意させることさえできれば、よいでしょうに。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
ブライアン・ロイド・ロイドと3420年のサドベリー道路キャメロン公園、仲間カリフォルニア 95682
Phone: (916) 676-1147
以下に電話をしてください。 (916) 676-1147
EMail: brian@lloyd.com
メール: brian@lloyd.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6205
P O Box6205イーストランシング、Services MI48826-6205に相談するウィリアムアレンシンプソン空想家コンピュータシステムズ
EMail: Bill.Simpson@um.cc.umich.edu
メール: Bill.Simpson@um.cc.umich.edu
Lloyd & Simpson [Page 16]
ロイドとシンプソン[16ページ]
一覧
スポンサーリンク
