3. 下位層の動作

3.1. 下位層の要件 (Lower Layer Requirements)

EAP は下位層について次の仮定を行います:

[1] 信頼性のないトランスポート。EAP では、認証器はまだ応答を受信していないリクエストを再送信するため、EAP は下位層が信頼性があるとは仮定しません。EAP は独自の再送信動作を定義しているため、EAP が信頼性のある下位層上で実行される場合、下位層と EAP 層の両方で再送信が発生する可能性があります（望ましくありませんが）。

EAP Success および Failure パケットは再送信されないことに注意してください。信頼性のある下位層がなく、エラー率が無視できない場合、これらのパケットは失われる可能性があり、タイムアウトが発生します。したがって、セクション 4.2 で説明されているように、実装は EAP Success または Failure パケットの損失に対する回復力を向上させることが望ましいです。

[2] 下位層のエラー検出。EAP は下位層が信頼性があるとは仮定しませんが、下位層のエラー検出（CRC、チェックサム、MIC など）には依存しています。EAP メソッドには MIC が含まれていない場合があり、含まれている場合でも、Code、Identifier、Length、Type フィールドなど、EAP パケットのすべてのフィールドで計算されない場合があります。その結果、下位層のエラー検出がないと、検出されないエラーが EAP 層または EAP メソッド層のヘッダーフィールドに忍び込み、認証の失敗を引き起こす可能性があります。

例えば、Type-Data フィールドのみで MIC を計算する EAP TLS [RFC2716] は、MIC 検証の失敗を致命的なエラーとみなします。下位層のエラー検出がないと、このメソッドおよび類似のメソッドは信頼性を持って動作しません。

[3] 下位層のセキュリティ。EAP は、下位層がパケットごとの機密性、認証、完全性、リプレイ保護などのセキュリティサービスを提供することを要求しません。ただし、これらのセキュリティサービスが利用可能な場合、鍵導出をサポートする EAP メソッド（セクション 7.2.1 を参照）を使用して、動的な鍵マテリアルを提供できます。これにより、EAP 認証を後続のデータにバインドし、データの変更、なりすまし、またはリプレイから保護することが可能になります。詳細については、セクション 7.1 を参照してください。

[4] 最小 MTU。EAP は、1020 オクテット以上の EAP MTU サイズを提供する下位層で機能できます。

EAP はパス MTU ディスカバリをサポートせず、フラグメンテーションと再構築は EAP でもこの仕様で定義されているメソッドでもサポートされていません：Identity (1)、Notification (2)、Nak Response (3)、MD5-Challenge (4)、One Time Password (5)、Generic Token Card (6)、および expanded Nak Response (254) タイプ。

通常、EAP ピアは下位層から EAP MTU に関する情報を取得し、EAP フレームサイズを適切な値に設定します。認証器がパススルーモードで動作する場合、認証サーバーは EAP MTU を直接決定する方法がないため、[RFC3579] のセクション 2.4 で説明されているように、Framed-MTU 属性などを介して認証器がこの情報を提供することに依存します。

EAP-TLS [RFC2716] などのメソッドはフラグメンテーションと再構築をサポートしていますが、制御フレームに対して 1500 オクテットの MTU が保証されている PPP 内での使用のために元々設計された EAP メソッド（[RFC1661]、セクション 6.1 を参照）には、フラグメンテーションと再構築の機能がない場合があります。

EAP メソッドは、他の情報がない場合、最小 EAP MTU を 1020 オクテットと仮定できます。EAP メソッドは、ペイロードがこの最小 EAP MTU よりも大きくなる可能性がある場合、フラグメンテーションと再構築のサポートを含めるべきです (SHOULD)。

EAP はロックステッププロトコルであり、フラグメンテーションと再構築を処理する際に一定の非効率性を意味します。したがって、下位層がフラグメンテーションと再構築をサポートしている場合（EAP が IP 経由で転送される場合など）、フラグメンテーションと再構築が EAP ではなく下位層で発生する方が望ましい場合があります。これは、EAP に人為的に大きな EAP MTU を提供することで実現でき、下位層内でフラグメンテーションと再構築が処理されます。

[5] 重複の可能性。下位層が信頼性がある場合、EAP 層に重複のないパケットストリームを提供します。ただし、下位層が非重複を提供することが望ましいですが、これは要件ではありません。Identifier フィールドは、ピアと認証器の両方に重複を検出する能力を提供します。

[6] 順序の保証。EAP は Identifier が単調増加することを要求しないため、正しい動作のために下位層の順序保証に依存しています。EAP は元々 PPP 上で実行されるように定義されており、[RFC1661] セクション 1 には順序要件があります：

「ポイントツーポイントプロトコルは、2 つのピア間でパケットを転送する単純なリンク用に設計されています。これらのリンクは、全二重同時双方向動作を提供し、パケットを順序どおりに配信すると想定されています。」

EAP の下位層トランスポートは、特定の優先度レベルでソースと宛先の間の順序を保持する必要があります (MUST)（[IEEE-802] によって提供される順序保証）。

並べ替えが発生すると、通常、EAP 認証の失敗が発生し、EAP 認証が再実行されます。並べ替えが発生する可能性のある環境では、EAP 認証の失敗が一般的であることが予想されます。EAP は順序保証を提供する下位層上でのみ実行することが推奨されます (RECOMMENDED)。生の IP または UDP トランスポート上で EAP を実行することは推奨されません (NOT RECOMMENDED)。RADIUS [RFC3579] 内の EAP のカプセル化は順序要件を満たします。なぜなら、RADIUS は順序どおりにパケットを配信する「ロックステップ」プロトコルだからです。

3.2. PPP 内での EAP の使用 (EAP Usage Within PPP)

ポイントツーポイントリンク経由で通信を確立するために、PPP リンクの各端は、リンク確立フェーズ中にデータリンクを構成するために最初に LCP パケットを送信します。リンクが確立された後、PPP はネットワーク層プロトコルフェーズに進む前にオプションの認証フェーズを提供します。

デフォルトでは、認証は必須ではありません。リンクの認証が必要な場合、実装はリンク確立フェーズ中に認証プロトコル構成オプションを指定する必要があります (MUST)。

認証フェーズでピアの ID が確立されている場合、サーバーは後続のネットワーク層ネゴシエーションでオプションを選択する際にその ID を使用できます。

PPP 内で実装される場合、EAP は PPP リンク制御フェーズで特定の認証メカニズムを選択せず、認証フェーズまでこれを延期します。これにより、認証器は特定の認証メカニズムを決定する前により多くの情報を要求できます。これにより、実際にさまざまなメカニズムを実装する「バックエンド」サーバーの使用も可能になりますが、PPP 認証器は認証交換を単に通過させるだけです。PPP リンク確立および認証フェーズ、および認証プロトコル構成オプションは、ポイントツーポイントプロトコル (PPP) [RFC1661] で定義されています。

3.2.1. PPP 構成オプション形式 (PPP Configuration Option Format)

EAP をネゴシエートするための PPP 認証プロトコル構成オプション形式の概要を以下に示します。フィールドは左から右に送信されます。

正確に 1 つの EAP パケットが、プロトコルフィールドがタイプ 16 進数 C227 (PPP EAP) を示す PPP データリンク層フレームの情報フィールドにカプセル化されます。

    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 (認証プロトコル)

C227 (16 進数) Extensible Authentication Protocol (EAP) 用

3.3. IEEE 802 内での EAP の使用 (EAP Usage Within IEEE 802)

IEEE 802 上の EAP のカプセル化は [IEEE-802.1X] で定義されています。EAP の IEEE 802 カプセル化には PPP は含まれず、IEEE 802.1X にはリンク層またはネットワーク層のネゴシエーションのサポートが含まれていません。その結果、IEEE 802.1X 内では、PAP や CHAP [RFC1994] などの非 EAP 認証メカニズムをネゴシエートすることはできません。

3.4. 下位層の指示 (Lower Layer Indications)

下位層の指示の信頼性とセキュリティは、下位層に依存します。EAP はメディアに依存しないため、EAP メッセージの処理では下位層のセキュリティの存在または不在は考慮されません。

信頼性を向上させるために、ピアがセクション 7.2 で定義されている下位層の成功指示を受信した場合、Success パケットが失われたと結論付け、実際に Success パケットを受信したかのように動作できます (MAY)。これには、セクション 4.2 で説明されているように、特定の状況で Success を無視することが含まれます。

PPP、IEEE 802 有線ネットワーク、および IEEE 802.11 ワイヤレス LAN での下位層指示に関するいくつかの信頼性とセキュリティの問題についての議論は、セキュリティに関する考慮事項、セクション 7.12 にあります。

EAP 認証が完了した後、ピアは通常、認証器を介してデータを送受信します。データを送信するエンティティが EAP 認証を正常に完了したエンティティと同じであることを保証することが望ましいです。これを達成するには、下位層がパケットごとの完全性、認証、およびリプレイ保護を提供し、これらのパケットごとのサービスを EAP 認証中に導出された鍵にバインドする必要があります。そうでなければ、後続のデータトラフィックが変更、なりすまし、またはリプレイされる可能性があります。

下位層暗号スイートの鍵マテリアル自体が EAP によって提供される場合、暗号スイートのネゴシエーションと鍵のアクティベーションは下位層によって制御されます。PPP では、暗号スイートは ECP 内でネゴシエートされるため、ECP が完了するまで EAP 認証から導出された鍵を使用することはできません。したがって、初期の EAP 交換は PPP 暗号スイートによって保護できませんが、EAP 再認証は保護できます。

IEEE 802 メディアでは、初期の鍵アクティベーションも通常 EAP 認証の完了後に発生します。したがって、初期の EAP 交換は通常下位層暗号スイートによって保護できませんが、EAP 再認証または事前認証交換は保護できます。