3. Lower Layer Behavior

3.1. 下位層の要件

EAP は下位層に対して以下の仮定を行う。

[1] 信頼できない転送。EAP では、オーセンティケータは応答を受信していない Request を再送するため、EAP は下位層が信頼できることを仮定しない。EAP は独自の再送動作を定義しているため、信頼できる下位層上で EAP が動作する場合、下位層と EAP 層の両方で再送が発生する可能性がある（ただし望ましくない）。

EAP Success および Failure パケットは再送されないことに注意。信頼できない下位層があり、無視できないエラー率が存在する場合、これらのパケットは失われ、タイムアウトを引き起こす可能性がある。したがって、第 4.2 節で説明されているように、EAP Success または Failure パケットの損失に対する耐性を高める実装が望ましい。

[2] 下位層エラー検出。EAP は下位層が信頼できることを仮定しないが、下位層エラー検出（CRC、Checksum、MIC など）に依存する。EAP 方式には MIC が含まれない場合があり、含まれていても、EAP パケット内のすべてのフィールド（Code、Identifier、Length、Type フィールドなど）に対して計算されない場合がある。したがって、下位層エラー検出がない場合、検出されないエラーが EAP 層または EAP 方式層ヘッダーフィールドに侵入し、認証失敗を引き起こす可能性がある。

たとえば、EAP TLS [RFC2716] は Type-Data フィールドに対してのみ MIC を計算し、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] などの方式はフラグメント化と再構成をサポートするが、PPP 内で最初に設計された EAP 方式（制御フレームは 1500 オクテットの MTU が保証される。[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 節には順序要件がある。

"The Point-to-Point Protocol is designed for simple links between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order."

EAP の下位層転送は、所与の優先度レベルでの送信元と宛先間の順序を維持しなければならない (MUST)（[IEEE-802] が提供する順序保証）。

順序の入れ替えが発生した場合、通常、EAP 認証の失敗につながり、EAP 認証の再実行を引き起こす。したがって、順序の入れ替えが発生する可能性のある環境では、EAP 認証の失敗は一般的になると予想される。EAP は順序保証を提供する下位層上でのみ動作させることを推奨する。生の IP または UDP 転送上での EAP の動作は推奨されない (NOT RECOMMENDED)。EAP を RADIUS [RFC3579] 内にカプセル化することは、RADIUS がパケットを順序通りに配信する「ロックステップ」プロトコルであるため、順序要件を満たす。

3.2. PPP 内での EAP の使用

通信を確立するために、PPP リンクの各端は最初に LCP パケットを送信してリンク確立フェーズでデータリンクを構成する。リンク確立後、PPP はネットワーク層プロトコルフェーズに入る前に、オプションの認証フェーズを提供する。

デフォルトでは、認証は必須ではない。リンクの認証が必要な場合、実装はリンク確立フェーズで認証プロトコル構成オプションを指定しなければならない (MUST)。

認証フェーズでピアのアイデンティティが決定された場合、サーバーは後続のネットワーク層ネゴシエーションのオプション選択でそのアイデンティティを使用できる。

PPP 内で実装される場合、EAP はリンク制御フェーズで特定の認証メカニズムを選択せず、それを認証フェーズまで延期する。これにより、オーセンティケータは特定の認証メカニズムを決定する前に詳細情報を要求できる。また、実際に各種メカニズムを実装する「バックエンド」サーバーを使用でき、PPP オーセンティケータは単に認証交換をパススルーする。PPP リンク確立および認証フェーズ、および認証プロトコル構成オプションは、Point-to-Point Protocol (PPP) [RFC1661] で定義されている。

3.2.1. PPP 構成オプション形式

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

PPP データリンク層フレームの Information フィールド内には、正確に 1 つの EAP パケットがカプセル化され、プロトコルフィールドはタイプ hex C227（PPP 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

Extensible Authentication Protocol (EAP) 用の C227（16 進数）

3.3. IEEE 802 内での EAP の使用

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

3.4. 下位層指示

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

信頼性を向上させるため、ピアが第 7.2 節で定義された lower layer success 指示を受信した場合、Success パケットが失われたと結論付け、実際に Success パケットを受信したかのように動作してもよい (MAY)。これには、場合によってはその Success を無視することが含まれる（第 4.2 節参照）。

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 再認証または事前認証交換は保護できる。