[要約] RFC 2284は、PPPの拡張認証プロトコル（EAP）に関する仕様であり、ネットワーク接続の認証を拡張するためのフレームワークを提供します。目的は、異なる認証方法をサポートし、セキュリティと柔軟性を向上させることです。
Network Working Group L. Blunk
Request for Comments: 2284 J. Vollbrecht
Category: Standards Track Merit Network, Inc.
March 1998
PPP Extensible Authentication Protocol (EAP)
PPP拡張認証プロトコル（EAP）
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（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は拡張可能なリンク制御プロトコルも定義します。これにより、ネットワーク層プロトコルがリンクを介して送信する前に、ピアを認証するための認証プロトコルのネゴシエーションが可能になります。
This document defines the PPP Extensible Authentication Protocol.
このドキュメントでは、PPP拡張認証プロトコルを定義しています。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. PPP Extensible Authentication Protocol (EAP) .......... 3
2.1 Configuration Option Format ..................... 4
2.2 Packet Format ................................... 6
2.2.1 Request and Response ............................ 6
2.2.2 Success and Failure ............................. 7
3. Initial EAP Request/Response Types .................... 8
3.1 Identity ........................................ 9
3.2 Notification .................................... 10
3.3 Nak ............................................. 10
3.4 MD5-Challenge ................................... 11
3.5 One-Time Password (OTP) ......................... 11
3.6 Generic Token Card .............................. 12
REFERENCES ................................................... 13
ACKNOWLEDGEMENTS ............................................. 14
CHAIR'S ADDRESS .............................................. 14
AUTHORS' ADDRESSES ........................................... 14
Full Copyright Statement ..................................... 15
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リンクの両端が最初にLCPパケットを送信して、リンク確立フェーズ中にデータリンクを構成する必要があります。リンクが確立された後、PPPはオプションの認証フェーズを提供してから、ネットワーク層プロトコルフェーズに進みます。
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.
デフォルトでは、認証は必須ではありません。リンクの認証が必要な場合、実装はリンク確立フェーズ中に認証プロトコル構成オプションを指定する必要があります。
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ネットワークサーバーに接続するホストおよびルーターでの使用を目的としていますが、専用リンクにも適用される場合があります。サーバーは、ネットワークレイヤーネゴシエーションのオプションの選択で、接続しているホストまたはルーターのIDを使用できます。
This document defines the PPP Extensible Authentication Protocol (EAP). The Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1].
このドキュメントでは、PPP拡張認証プロトコル（EAP）を定義しています。リンクの確立と認証のフェーズ、および認証プロトコル構成オプションは、ポイントツーポイントプロトコル（PPP）[1]で定義されています。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6].
このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。これらの単語は、多くの場合大文字です。このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [6]で説明されているように解釈されます。
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.
このドキュメントでは、次の用語を頻繁に使用しています。オーセンティケーター認証を必要とするリンクの終わり。オーセンティケーターは、リンク確立フェーズ中に構成要求で使用される認証プロトコルを指定します。
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.
サイレントに破棄これは、実装がそれ以上処理せずにパケットを破棄することを意味します。実装は、暗黙的に破棄されたパケットの内容を含むエラーをログに記録する機能を提供する必要があり（SHOULD）、統計カウンターにイベントを記録する必要があります（SHOULD）。
displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [5].
表示可能なメッセージこれは人間が読める文字列と解釈され、プロトコルの動作に影響を与えてはなりません。メッセージのエンコードは、UTF-8変換フォーマット[5]に従う必要があります。
The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange.
PPP拡張認証プロトコル（EAP）は、複数の認証メカニズムをサポートするPPP認証の一般的なプロトコルです。 EAPは、リンク制御フェーズで特定の認証メカニズムを選択するのではなく、認証フェーズまでこれを延期します。これにより、オーセンティケータは特定の認証メカニズムを決定する前に詳細情報を要求できます。これにより、PPPオーセンティケーターが認証交換を通過するだけで、実際にさまざまなメカニズムを実装する「バックエンド」サーバーを使用できるようになります。
1. After the Link Establishment phase is complete, the authenticator sends one or more Requests to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, One-Time Passwords, Generic Token Card, etc. The MD5-challenge type corresponds closely to the CHAP authentication protocol. Typically, the authenticator will send an initial Identity Request followed by one or more Requests for authentication information. However, an initial Identity Request is not required, and MAY be bypassed in cases where the identity is presumed (leased lines, dedicated dial-ups, etc.).
1. リンク確立フェーズが完了すると、オーセンティケーターは1つ以上の要求を送信してピアを認証します。リクエストには、何がリクエストされているかを示すタイプフィールドがあります。リクエストタイプの例には、ID、MD5チャレンジ、ワンタイムパスワード、ジェネリックトークンカードなどがあります。MD5チャレンジタイプは、CHAP認証プロトコルに密接に対応しています。通常、オーセンティケータは最初のID要求を送信し、その後に認証情報の1つ以上の要求を送信します。ただし、最初のID要求は必須ではなく、IDが推定される場合（専用回線、専用ダイヤルアップなど）はバイパスされる場合があります。
2. The peer sends a Response packet in reply to each Request. As with the Request packet, the Response packet contains a type field which corresponds to the type field of the Request.
2. ピアは、各要求に応答して応答パケットを送信します。要求パケットと同様に、応答パケットには、要求のタイプフィールドに対応するタイプフィールドが含まれています。
3. The authenticator ends the authentication phase with a Success or Failure packet.
3. オーセンティケーターは、成功または失敗のパケットで認証フェーズを終了します。
Advantages
メリット
The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one during LCP Phase.
EAPプロトコルは、LCPフェーズ中に特定の認証メカニズムを事前にネゴシエートする必要なく、複数の認証メカニズムをサポートできます。
Certain devices (e.g. a NAS) do not necessarily have to understand each request type and may be able to simply act as a passthrough agent for a "back-end" server on a host. The device only need look for the success/failure code to terminate the authentication phase.
特定のデバイス（NASなど）は、必ずしも各要求タイプを理解する必要はなく、ホスト上の「バックエンド」サーバーのパススルーエージェントとして単に機能することができる場合があります。デバイスは、認証フェーズを終了するために成功/失敗コードを探すだけです。
Disadvantages
短所
EAP does require the addition of a new authentication type to LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP.
EAPでは、LCPに新しい認証タイプを追加する必要があるため、それを使用するようにPPP実装を変更する必要があります。また、LCP中に特定の認証メカニズムをネゴシエートする以前のPPP認証モデルから逸脱しています。
A summary of the Authentication-Protocol Configuration Option format to negotiate the EAP Authentication Protocol is shown below. The fields are transmitted from left to right.
EAP認証プロトコルをネゴシエートするための認証プロトコル構成オプションの形式の概要を以下に示します。フィールドは左から右に送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3
３
Length
長さ
4
４
Authentication-Protocol
認証プロトコル
C227 (Hex) for PPP Extensible Authentication Protocol (EAP)
PPP拡張認証プロトコル（EAP）のC227（16進数）
Exactly one PPP EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP). A summary of the EAP packet format is shown below. The fields are transmitted from left to right.
ちょうど1つのPPP EAPパケットがPPPデータリンク層フレームの情報フィールドにカプセル化され、プロトコルフィールドはタイプhex C227（PPP EAP）を示します。 EAPパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
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 ...
+-+-+-+-+
Code
コード
The Code field is one octet and identifies the type of EAP packet. EAP Codes are assigned as follows:
Codeフィールドは1オクテットで、EAPパケットのタイプを識別します。 EAPコードは次のように割り当てられます。
1 Request 2 Response 3 Success 4 Failure
1要求2応答3成功4失敗
Identifier
識別する
The Identifier field is one octet and aids in matching responses with requests.
Identifierフィールドは1オクテットであり、応答と要求の照合に役立ちます。
Length
長さ
The Length field is two octets and indicates the length of the EAP 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.
長さフィールドは2オクテットで、コード、識別子、長さ、データフィールドを含むEAPパケットの長さを示します。長さフィールドの範囲外のオクテットは、データリンク層のパディングとして扱われ、受信時には無視されます。
Data
データ
The Data field is zero or more octets. The format of the Data field is determined by the Code field.
データフィールドは0オクテット以上です。データフィールドの形式は、コードフィールドによって決まります。
Description
説明
The Request packet is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAP packet with the Code field set to 1 (Request). Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response packet in reply to a Request packet. Responses MUST only be sent in reply to a received Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request.
要求パケットは、オーセンティケーターによってピアに送信されます。各リクエストにはタイプフィールドがあり、リクエストされているものを示します。オーセンティケーターは、コードフィールドを1（要求）に設定してEAPパケットを送信する必要があります。有効な応答パケットが受信されるか、オプションの再試行カウンターが期限切れになるまで、追加の要求パケットを送信する必要があります。再送信されたリクエストは、新しいリクエストと区別するために、同じ識別子の値で送信する必要があります。データフィールドの内容は、リクエストタイプによって異なります。ピアは、要求パケットに応答して応答パケットを送信する必要があります。応答は、受信した要求への応答としてのみ送信されなければならず、タイマーで再送信されてはなりません。応答のIDフィールドは、要求のIDフィールドと一致する必要があります。
Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. It is suggested a retransmission timer of 6 seconds with a maximum of 10 retransmissions be used as default. One may wish to make these timeouts longer in certain cases (e.g. where Token Cards are involved). Additionally, the peer must be prepared to silently discard received retransmissions while waiting for user input.
実装上の注意：認証プロセスにはユーザー入力が含まれることが多いため、再送信戦略と認証タイムアウトを決定する際には注意が必要です。デフォルトとして、最大10回の再送信を伴う6秒の再送信タイマーを使用することをお勧めします。特定のケース（たとえば、トークンカードが関係する場合）で、これらのタイムアウトを長くしたい場合があります。さらに、ピアは、ユーザー入力を待つ間、受信した再送信をサイレントに破棄する準備をする必要があります。
A summary of the Request and Response packet format is shown below. The fields are transmitted from left to right.
リクエストとレスポンスのパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
1 for Request;
リクエストの場合は1。
2 for Response.
応答の場合は2。
Identifier
識別する
The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend it's Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request.
識別子フィールドは1オクテットです。応答を待っている間にタイムアウトが発生したために要求パケットが再送信される場合、識別子フィールドは同じでなければなりません。新しい（再送信ではない）要求はすべて、識別子フィールドを変更する必要があります。ピアがすでに応答を送信した重複した要求を受信した場合、ピアはその応答を再送信する必要があります。ピアが最初のリクエストへの応答を送信する前に重複するリクエストを受信した場合（つまり、ピアがユーザー入力を待機している場合）、重複するリクエストを静かに破棄する必要があります。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
長さフィールドは2オクテットで、コード、識別子、長さ、タイプ、およびタイプデータフィールドを含むEAPパケットの長さを示します。長さフィールドの範囲外のオクテットは、データリンク層のパディングとして扱われ、受信時には無視されます。
Type
タイプ
The Type field is one octet. This field indicates the Type of Request or Response. Only one Type MUST be specified per EAP Request or Response. Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. An initial specification of Types follows in a later section of this document.
Typeフィールドは1オクテットです。このフィールドは、要求または応答のタイプを示します。 EAP要求または応答ごとに1つのタイプのみを指定する必要があります。通常、応答のタイプフィールドは要求のタイプと同じです。ただし、要求タイプがピアに受け入れられないことを示すためのNak応答タイプもあります。リクエストに応答してNakを送信するとき、ピアは、サポートする代替の望ましい認証タイプを示すことができます（MAY）。タイプの初期仕様は、このドキュメントの後のセクションで説明します。
Type-Data
タイプデータ
The Type-Data field varies with the Type of Request and the associated Response.
Type-Dataフィールドは、要求のタイプと関連する応答によって異なります。
Description
説明
The Success packet is sent by the authenticator to the peer to acknowledge successful authentication. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success).
成功パケットは、成功した認証を確認するために、オーセンティケータによってピアに送信されます。オーセンティケーターは、コードフィールドを3（成功）に設定してEAPパケットを送信する必要があります。
If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes.
オーセンティケーターがピアを認証できない場合（1つ以上の要求に対する許容できない応答）、実装はコードフィールドを4（失敗）に設定してEAPパケットを送信する必要があります。オーセンティケーターは、人間のタイプミスを許容するために、失敗応答を送信する前に複数の要求を発行したい場合があります。
Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure.
実装上の注意：成功パケットと失敗パケットは確認されないため、失われる可能性があります。ピアはこの状況を許可する必要があります。ピアは、成功の代替指標としてネットワークプロトコルパケットを使用できます。同様に、LCP Terminate-Requestの受信は失敗と見なすことができます。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
成功と失敗のパケット形式の概要を以下に示します。フィールドは左から右に送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
3 for Success;
成功の場合は3。
4 for Failure.
失敗の場合は4。
Identifier
識別する
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Indentifier field of the Response packet that it is sent in response to.
Identifierフィールドは1オクテットであり、応答と応答の照合に役立ちます。 Identifierフィールドは、応答として送信されるResponseパケットのIndentifierフィールドと一致する必要があります。
Length
長さ
4
４
This section defines the initial set of EAP Types used in Request/Response exchanges. More Types may be defined in follow-on documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types. The remaining Types define authentication exchanges. The Nak Type is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be sent in repsonse to a Request which uses an authentication Type code. All EAP implementatins MUST support Types 1-4. These Types, as well as types 5 and 6, are defined in this document. Follow-on RFCs will define additional EAP Types.
このセクションでは、要求/応答交換で使用されるEAPタイプの初期セットを定義します。さらに多くのタイプが後続のドキュメントで定義される場合があります。 Typeフィールドは1オクテットで、EAP要求または応答パケットの構造を識別します。最初の3つのタイプは、特殊なケースタイプと見なされます。残りのタイプは、認証交換を定義します。 Nakタイプは、応答パケットに対してのみ有効であり、リクエストで送信してはなりません。 Nakタイプは、認証タイプコードを使用するリクエストに応答してのみ送信する必要があります。すべてのEAP実装はタイプ1〜4をサポートする必要があります。これらのタイプ、およびタイプ5および6は、このドキュメントで定義されています。後続のRFCは、追加のEAPタイプを定義します。
1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One-Time Password (OTP) (RFC 1938) 6 Generic Token Card
1 ID 2通知3 Nak（応答のみ）4 MD5-Challenge 5ワンタイムパスワード（OTP）（RFC 1938）6汎用トークンカード
Description
説明
The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity).
IDタイプは、ピアのIDを照会するために使用されます。通常、オーセンティケータはこれを最初のリクエストとして発行します。オプションの表示可能なメッセージを含めて、ユーザーとのやり取りが予想される場合にピアを促すことができます。 Type 1（Identity）でこのリクエストに応答を送信する必要があります。
Implementation Note: The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Indentity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication phase with a Failure reply. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself).
実装上の注意：ピアは、ユーザー入力を介してIDを取得できます（MAY）。無効なIDまたは認証の失敗が発生した場合は、オーセンティケータがIndentityリクエストを再試行して、ユーザーのタイプミスの可能性を考慮に入れることをお勧めします。 Identityリクエストは、失敗の応答で認証フェーズを終了する前に、最低3回再試行することをお勧めします。通知要求を使用して、新しいID要求を送信する前に無効な認証試行を示すことができます（オプションで、失敗は新しいID要求自体のメッセージ内に示される場合があります）。
Type
タイプ
1
１
Type-Data
タイプデータ
This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required.
このフィールドには、リクエストに表示可能なメッセージが含まれる場合があります。応答はこのフィールドを使用してIDを返します。 IDが不明の場合、このフィールドの長さは0バイトにする必要があります。フィールドはnullで終了してはいけません。このフィールドの長さは、要求/応答パケットの長さフィールドから導出されるため、ヌルは必要ありません。
Description
説明
The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. The peer SHOULD display this message to the user or log it if it cannot be displayed. It is intended to provide an acknowledged notification of some imperative nature. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, notification should not be required.
通知タイプは、オプションで、表示可能なメッセージをオーセンティケータからピアに伝達するために使用されます。ピアは、このメッセージをユーザーに表示するか、表示できない場合はログに記録する必要があります（SHOULD）。これは、いくつかの必須の性質の確認済み通知を提供することを目的としています。例としては、有効期限が間もなく切れるパスワード、0に近いOTPシーケンス整数、認証失敗の警告などがあります。ほとんどの場合、通知は必要ありません。
Type
タイプ
2
２
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged).
リクエストのType-Dataフィールドには、長さが0オクテットを超える表示可能なメッセージが含まれています。メッセージの長さは、要求パケットの長さフィールドによって決まります。メッセージはnullで終了してはいけません。 Typeフィールドが2（通知）の要求に応答して、応答を送信する必要があります。 ResponseのType-Dataフィールドの長さが0オクテットです。応答はすぐに送信する必要があります（メッセージの表示方法やログ方法とは関係ありません）。
Description
説明
The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer.
Nakタイプは、応答メッセージでのみ有効です。これは、必要な認証タイプが受け入れられない要求への応答として送信されます。認証タイプには4以上の番号が付けられています。応答には、ピアが必要とする認証タイプが含まれています。
Type
タイプ
3
３
Type-Data
タイプデータ
This field MUST contain a single octet indicating the desired authentication type.
このフィールドには、必要な認証タイプを示す単一のオクテットが含まれている必要があります。
Description
説明
The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] (with MD5 as the specified algorithm). The PPP Challenge Handshake Authentication Protocol RFC [3] should be referred to for further implementation specifics. The Request contains a "challenge" message to the peer. A Repsonse MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5- Challenge) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type. All EAP implementations MUST support the MD5-Challenge mechanism.
MD5-Challenge Typeは、PPP CHAPプロトコル[3]に類似しています（指定されたアルゴリズムとしてMD5を使用）。実装の詳細については、PPPチャレンジハンドシェイク認証プロトコルRFC [3]を参照してください。リクエストには、ピアへの「チャレンジ」メッセージが含まれています。リクエストへの返信として、Repsonseを送信する必要があります。応答は、タイプ4（MD5-チャレンジ）またはタイプ3（Nak）のいずれかになります。 Nak応答は、ピアの必要な認証メカニズムタイプを示します。すべてのEAP実装は、MD5-Challengeメカニズムをサポートする必要があります。
Type
タイプ
4
４
Type-Data
タイプデータ
The contents of the Type-Data field is summarized below. For reference on the use of this fields see the PPP Challenge Handshake Authentication Protocol [3].
Type-Dataフィールドの内容を以下にまとめます。このフィールドの使用に関するリファレンスについては、PPPチャレンジハンドシェイク認証プロトコル[3]を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description
説明
The One-Time Password system is defined in "A One-Time Password System" [4]. The Request contains a displayable message containing an OTP challenge. A Repsonse MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type.
ワンタイムパスワードシステムは、「ワンタイムパスワードシステム」[4]で定義されています。リクエストには、OTPチャレンジを含む表示可能なメッセージが含まれています。リクエストへの返信として、Repsonseを送信する必要があります。応答はタイプ5（OTP）またはタイプ3（Nak）でなければなりません。 Nak応答は、ピアの必要な認証メカニズムタイプを示します。
Type
タイプ
5
５
Type-Data
タイプデータ
The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [4]. The messages MUST not be null terminated. The length of the field is derived from the Length field of the Request/Reply packet.
Type-Dataフィールドには、リクエストの表示可能なメッセージとしてOTPの「チャレンジ」が含まれています。応答では、このフィールドはOTP辞書[4]の6語に使用されます。メッセージはnullで終了してはいけません。フィールドの長さは、要求/応答パケットの長さフィールドから導出されます。
Description
説明
The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains an ASCII text message and the Reply contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text.
Generic Token Card Typeは、ユーザー入力を必要とするさまざまなトークンカードの実装で使用するために定義されています。リクエストにはASCIIテキストメッセージが含まれ、返信には認証に必要なトークンカード情報が含まれます。通常、これはトークンカードデバイスからユーザーが読み取ってASCIIテキストとして入力した情報です。
Type
タイプ
6
６
Type-Data
タイプデータ
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet.
リクエストのType-Dataフィールドには、長さが0オクテットを超える表示可能なメッセージが含まれています。メッセージの長さは、要求パケットの長さフィールドによって決まります。メッセージはnullで終了してはいけません。 Typeフィールドが6（Generic Token Card）のリクエストに対して、応答を送信する必要があります。応答には、認証に必要なトークンカードからのデータが含まれています。データの長さは、応答パケットの長さフィールドによって決定されます。
Security Considerations
セキュリティに関する考慮事項
Security issues are the primary topic of this RFC.
セキュリティの問題は、このRFCの主要なトピックです。
The interaction of the authentication protocols within PPP are highly implementation dependent.
PPP内の認証プロトコルの相互作用は、実装に大きく依存します。
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.
たとえば、認証が失敗すると、一部の実装ではリンクが終了しません。代わりに、実装により、ネットワーク層プロトコルのトラフィックの種類がフィルタリングされたサブセットに制限されます。これにより、ユーザーはシークレットを更新したり、ネットワーク管理者に問題を示すメールを送信したりできます。
There is no provision for retries 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.
認証が全二重である、または同じプロトコルが両方向で使用されるという要件はありません。各方向で異なるプロトコルを使用することは完全に許容されます。もちろん、これは交渉された特定のプロトコルに依存します。
In practice, within or associated with each PPP server, 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 EAP). 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 methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
実際には、各PPPサーバー内または各PPPサーバーに関連付けられている場合、特定の名前付きユーザーが複数の方法で認証されることは想定されていません。これにより、セットの中から最も安全性の低い方法（EAPではなくPAPなど）をネゴシエートする攻撃に対して、ユーザーが脆弱になります。代わりに、指定されたユーザーごとに、そのユーザー名を認証するために使用された方法が1つだけ示されます。ユーザーがさまざまな状況でさまざまな認証方法を使用する必要がある場合は、それぞれが正確に1つの認証方法を識別する個別のIDを使用する必要があります（SHOULD）。
References
参考文献
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[2] Reynolds、J.およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[3] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[3] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 1996.
[4] Haller、N。およびC. Metz、「Aワンタイムパスワードシステム」、RFC 1938、1996年5月。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[5] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換フォーマット」、RFC 2044、1996年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
Acknowledgments
謝辞
This protocol derives much of its inspiration from Dave Carrel's AHA draft as well as the PPP CHAP protocol [3]. Bill Simpson provided much of the boilerplate used throughout this document. Al Rubens (Merit) also provided valuable feedback.
このプロトコルは、Dave CarrelのAHAドラフトとPPP CHAPプロトコル[3]から着想を得ています。 Bill Simpsonは、このドキュメント全体で使用される定型文の多くを提供しました。 Al Rubens（Merit）も貴重なフィードバックを提供しました。
Chair's Address
議長の住所
The working group can be contacted via the current chair:
ワーキンググループは、現在の議長を通じて連絡を取ることができます。
Karl F. Fox Ascend Communications, Inc. 655 Metro Place South, Suite 370 Dublin, Ohio 43017
Karl F. Fox Ascend Communications、Inc. 655 Metro Place South、Suite 370 Dublin、Ohio 43017
EMail: karl@ascend.com
Phone: +1 614 760 4041
Fax: +1 614 760 4050
Authors' Addresses
著者のアドレス
Larry J. Blunk Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
Larry J.Blunk Merit Network、Inc. 4251 Plymouth Rd。、Suite C Ann Arbor、MI 48105
EMail: ljb@merit.edu
Phone: 734-763-6056
FAX: 734-647-3185
John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105
John R. Vollbrecht Merit Network、Inc. 4251 Plymouth Rd。、Suite C Ann Arbor、MI 48105
EMail: jrv@merit.edu
Phone: +1-313-763-1206
FAX: +1-734-647-3185
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。