7. Security Considerations
7. Security Considerations
このセクションは、一般的な脅威モデルと、それらの脅威を軽減する EAP 方式のセキュリティ要求事項（security claims）を定義する。
一般的な脅威モデルと対応するセキュリティ要求事項は、特定の環境で使用される EAP 方式の要件を定義するために使用されることが期待されている。そのような要件分析の例は [IEEE-802.11i-req] に示されている。EAP 方式の仕様にはセキュリティ要求事項のセクションが必須であり、それにより EAP 方式を要件に対して評価できるようになる。
7.1. 脅威モデル
EAP は PPP [RFC1661] と共に使用するために開発され、後に [IEEE-802.1X] において有線 IEEE 802 ネットワーク [IEEE-802] で使用するために適応された。その後、EAP はワイヤレス LAN ネットワークやインターネット上での使用に提案されている。これらすべての状況において、攻撃者が EAP パケットが送信されるリンクへのアクセスを得る可能性がある。[DECEPTION] には電話インフラストラクチャに対する攻撃が記述されている。
リンクへのアクセスを持つ攻撃者は、以下を含む多くの攻撃を実行できる。
[1] 攻撃者は、認証トラフィックを盗聴することでユーザの識別情報を発見しようとする可能性がある。
[2] 攻撃者は、EAP パケットを改変または偽造しようとする可能性がある。
[3] 攻撃者は、下位層の指示や Success/Failure パケットを偽造したり、EAP パケットを再生したり、重複する Identifier を持つパケットを生成することで、サービス拒否攻撃を仕掛ける可能性がある。
[4] 攻撃者は、オフライン辞書攻撃を仕掛けることでパスフレーズを回復しようとする可能性がある。
[5] 攻撃者は、中間者攻撃（man-in-the-middle attack）を仕掛けることで、peer を信頼されていないネットワークに接続させようとする可能性がある。
[6] 攻撃者は、弱い認証方式が選択されるように EAP ネゴシエーションを妨害しようとする可能性がある。
[7] 攻撃者は、EAP 方式内で使用される弱い鍵導出技術を悪用して鍵を回復しようとする可能性がある。
[8] 攻撃者は、EAP セッション完了後にその後使用される弱い暗号スイートを悪用しようとする可能性がある。
[9] 攻撃者は、EAP 認証の後に弱い暗号スイートが使用されることを確実にするために、下位層の暗号スイートネゴシエーションに対してダウングレード攻撃を仕掛けようとする可能性がある。
[10] authenticator として行動する攻撃者は、帯域外のメカニズム（AAA や下位層プロトコルなど）を介して、EAP peer やサーバに対して不正な情報を提供する可能性がある。これには、別の authenticator になりすますことや、peer と EAP サーバに矛盾する情報を提供することが含まれる。
下位層によっては、これらの攻撃は物理的な近接を必要とせずに実行できる。EAP がワイヤレスネットワークで使用される場合、EAP パケットは authenticator（たとえば事前認証）によって転送される可能性があるため、攻撃者はその authenticator やその peer に対して攻撃を行うために authenticator のカバー範囲内にいる必要がない。EAP がインターネット上で使用される場合、より遠隔から攻撃を実行できる。
7.2. セキュリティ要求事項
EAP 方式が提供するセキュリティを明確に示すために、EAP 方式の仕様には、以下の宣言を含むセキュリティ要求事項のセクションが含まれなければならない (MUST)。
[a] メカニズム。これは認証技術の説明である。証明書、事前共有鍵、パスワード、トークンカードなど。
[b] セキュリティ要求事項。これは、セクション 7.2.1 で定義された用語（相互認証、整合性保護、リプレイ保護、機密性、鍵導出、辞書攻撃耐性、高速再接続、暗号的結合）を用いた方式の主張するセキュリティ特性の説明である。EAP 方式の仕様のセキュリティ要求事項セクションは、なされた主張の正当性を提供すべきである (SHOULD)。これは、付録に証明を含めるか、証明への参照を含めることで達成できる。
[c] 鍵強度。方式が鍵を導出する場合、実効鍵強度を推定しなければならない (MUST)。この推定は、方式の潜在的利用者が、生成された鍵が意図したアプリケーションに十分な強度であるかどうかを判断するためのものである。
実効鍵強度はビット数として示されるべきであり (SHOULD)、以下のように定義される。実効鍵強度が N ビットである場合、鍵を回復するために現在知られている最良の方法（無視できない確率で）は、平均して典型的なブロック暗号の 2^(N-1) 回の操作に相当する努力を必要とする。この記述には、この数値がどのように導出されたかを説明する簡単な根拠を添えるべきである (SHOULD)。この説明には、現在のアルゴリズムの知識に基づいて記述された鍵強度を達成するために必要なパラメータを含めるべきである (SHOULD)。
（注：「相当する努力」や「典型的なブロック暗号」が正確に何を意味するかを定義することは困難であるが、ここでは合理的な近似で十分である。詳細については [SILVERMAN] 等を参照されたい。）
鍵強度は、鍵の導出に使用される方式に依存する。たとえば、鍵が共有秘密（パスワードや長期秘密など）と、おそらくナンスなどのいくつかの公開情報から導出される場合、実効鍵強度は長期秘密の強度によって制限される（導出手順が計算上単純であると仮定）。別の例として、公開鍵アルゴリズムを使用する場合、対称鍵の強度は使用される公開鍵の強度に依存する。
[d] 鍵階層の説明。鍵を導出する EAP 方式は、鍵階層の仕様への参照を提供するか、マスターセッション鍵 (MSK) および拡張マスターセッション鍵 (EMSK) の導出方法を記述しなければならない (MUST)。
[e] 脆弱性の表示。なされたセキュリティ要求事項に加えて、仕様はセクション 7.2.1 で詳述されたセキュリティ要求事項のうちどれが主張されていないかを示さなければならない (MUST)。
7.2.1. EAP 方式のセキュリティ要求事項用語
これらの用語は、EAP 方式のセキュリティ特性を説明するために使用される。
保護された暗号スイートネゴシエーション (Protected ciphersuite negotiation)
これは、EAP 方式が EAP セッションを保護するために使用される暗号スイートをネゴシエーションし、そのネゴシエーションを整合性保護する能力を指す。これは、データを保護するために使用される暗号スイートをネゴシエーションする能力を指すものではない。
相互認証 (Mutual authentication)
これは、インターロックされた交換の中で、authenticator が peer を認証し、peer が authenticator を認証する EAP 方式を指す。反対方向に実行される 2 つの独立した一方向方式は、ここで定義される相互認証を提供しない。
整合性保護 (Integrity protection)
これは、EAP パケット（EAP Request および Response を含む）に対するデータ発信元認証および不正な改変に対する保護の提供を指す。この要求事項を主張する場合、方式の仕様は保護される EAP パケットおよび EAP パケット内のフィールドを記述しなければならない (MUST)。
リプレイ保護 (Replay protection)
これは、成功および失敗の結果表示を含む、EAP 方式またはそのメッセージのリプレイに対する保護を指す。
機密性 (Confidentiality)
これは、EAP Request および Response、ならびに成功および失敗の結果表示を含む EAP メッセージの暗号化を指す。この要求事項を主張する方式は、識別情報保護（セクション 7.3 参照）をサポートしなければならない (MUST)。
鍵導出 (Key derivation)
これは、EAP 方式が、マスターセッション鍵 (MSK) や拡張マスターセッション鍵 (EMSK) などのエクスポート可能な鍵素材を導出する能力を指す。MSK は、さらに鍵を導出するためのみに使用され、EAP セッションや後続のデータの保護には直接使用されない。EMSK の使用は予約されている。
鍵強度 (Key strength)
実効鍵強度が N ビットである場合、鍵を回復するために現在知られている最良の方法（無視できない確率で）は、平均して典型的なブロック暗号の 2^(N-1) 回の操作に相当する努力を必要とする。
辞書攻撃耐性 (Dictionary attack resistance)
パスワード認証が使用される場合、パスワードは（N ビット鍵の集合と比較して）小さな集合から選択されることが多く、辞書攻撃に関する懸念が生じる。方式が秘密としてパスワードを使用する場合、攻撃者の辞書内のパスワード数に基づく作業係数を持つオフライン攻撃を許可しないとき、その方式は辞書攻撃に対する保護を提供すると言える。
高速再接続 (Fast reconnect)
以前にセキュリティアソシエーションが確立されている場合に、より効率的に、またはより少ない往復回数で新しいまたは更新されたセキュリティアソシエーションを作成する能力。
暗号的結合 (Cryptographic binding)
トンネル方式内で実行されたすべての方式について、単一の実体が EAP peer として機能したことを、EAP peer が EAP サーバに対して実証すること。結合は、EAP サーバがトンネル方式内で実行されたすべての方式について、単一の実体が EAP サーバとして機能したことを peer に対して実証することを意味してもよい (MAY)。正しく実行されれば、結合は中間者脆弱性を軽減するのに役立つ。
セッション独立性 (Session independence)
受動的攻撃（EAP セッションの捕捉など）や能動的攻撃（MSK や EMSK の漏洩を含む）が、後続または以前の MSK や EMSK の漏洩をもたらさないことを実証すること。
フラグメンテーション (Fragmentation)
これは、EAP 方式がフラグメント化と再構築をサポートするかどうかを指す。セクション 3.1 で述べたように、EAP パケットが最小 MTU である 1020 オクテットを超える可能性がある場合、EAP 方式はフラグメント化と再構築をサポートすべきである (SHOULD)。
チャネルバインディング (Channel binding)
EAP 方式内での、帯域外のメカニズム（AAA や下位層プロトコルなど）を介して通信された値と比較できる整合性保護されたチャネル特性（エンドポイント識別子など）の通信。
注：このセキュリティ要求事項のリストは網羅的ではない。追加の特性（追加のサービス拒否保護など）も関連する可能性がある。
7.3. 識別情報保護
識別情報交換は EAP セッション内でオプションである。したがって、識別情報交換を完全に省略することも、保護されたチャネルが確立された後に方式固有の識別情報交換を使用することも可能である。
しかし、[RFC2607] で説明されているようなローミングがサポートされている場合、認証セッションを進める前に適切なバックエンド認証サーバを見つける必要があるかもしれない。ネットワークアクセス識別子 (NAI) [RFC2486] のレルム部分は、通常、認証交換を適切なバックエンド認証サーバにルーティングできるようにするために、EAP-Response/Identity 内に含まれる。したがって、プロキシやリレーが存在する場合、NAI の peer 名部分は EAP-Response/Identity で省略可能であるが、レルム部分は必要になる場合がある。
識別応答内の識別情報は、EAP 方式によって認証された識別情報と異なる可能性がある。これは、識別情報プライバシーの場合には意図的なものである可能性がある。EAP 方式は、アクセス制御の決定を行う際には、認証された識別情報を使用すべきである (SHOULD)。
7.4. 中間者攻撃
EAP が peer 認証を省略した別のプロトコル内にトンネリングされている場合、中間者攻撃に対する潜在的な脆弱性が存在する。詳細については [BINDING] および [MITM] を参照されたい。
セクション 2.1 で述べたように、EAP はトンネリングされていない認証方式のシーケンスを許可しない。EAP 認証方式のシーケンスが許可された場合、peer は単一の実体がシーケンス内のすべての EAP 方式について authenticator として機能したという証拠を持たないかもしれない。たとえば、authenticator は 1 つの EAP 方式を終了し、その後、peer の知識や同意なしにシーケンス内の次の方式を別の当事者に転送する可能性がある。同様に、authenticator は、シーケンス内のすべての EAP 方式について単一の実体が peer として機能したという証拠を持たないかもしれない。
別のプロトコル内で EAP をトンネリングすると、悪意のある EAP authenticator が EAP を正当なサーバにトンネリングする攻撃が可能になる。トンネリングプロトコルが鍵確立に使用されるが peer 認証を要求しない場合、正当な peer を自分に接続するよう説得した攻撃者は、EAP パケットを正当なサーバにトンネリングし、認証に成功して鍵を取得できる。これにより、攻撃者は自身を中間者として確立し、ネットワークへのアクセス、および正当な peer とサーバ間のデータトラフィックを復号する能力を獲得できる。
この攻撃は、以下の措置によって軽減できる。
[a] EAP トンネリングメカニズム内での相互認証の要求。
[b] EAP トンネリングプロトコルとトンネリングされた EAP 方式間の暗号的結合の要求。暗号的結合がサポートされている場合、それをバイパスするダウングレード攻撃を防ぐメカニズムも必要である。暗号的結合の詳細については [BINDING] を参照されたい。
[c] peer と authenticator のポリシーに基づき、保護なしで使用が許可される EAP 方式の制限。
[d] 単一の強力な方式が利用可能な場合、トンネルの使用を避けること。
7.5. パケット改変攻撃
EAP 方式はパケットごとのデータ発信元認証、整合性、リプレイ保護をサポートする可能性があるが、EAP 層内ではサポートされていない。
Identifier は単一のオクテットであるため、推測が容易であり、攻撃者が EAP パケットを正常に注入または再生することを可能にする。攻撃者はまた、保護されていない EAP ヘッダ（Code、Identifier、Length、Type）を EAP パケット内で改変する可能性がある。これにより、パケットが不適切に廃棄されたり誤って解釈されたりする可能性がある。
EAP パケットを改変、偽造、リプレイから保護するために、保護された暗号スイートネゴシエーション、相互認証、鍵導出、および整合性とリプレイ保護をサポートする方式を使用することが推奨される。これらのセキュリティ要求事項の定義についてはセクション 7.2.1 を参照されたい。
方式固有の MIC を使用して保護を提供できる。EAP 方式内でパケットごとの MIC が採用されている場合、非パススルーモードで動作していない peer、認証サーバ、および authenticator は、その MIC を検証しなければならない (MUST)。MIC 検証の失敗は記録されるべきである (SHOULD)。MIC 検証の失敗が致命的なエラーと見なされるかどうかは、EAP 方式の仕様によって決定される。
EAP パケットの整合性保護を提供する方式は、Code、Identifier、Length、Type、Type-Data フィールドを含むすべての EAP ヘッダフィールドをカバーすることが推奨される。
Identity、Notification、Nak タイプの EAP メッセージには独自の MIC が含まれないため、これらのメッセージ内に含まれる情報および各 EAP メッセージのヘッダを EAP 方式の MIC でカバーすることが望ましい場合がある。
保護を提供するために、EAP は [IKEv2] で行われているように ISAKMP [RFC2408] などのプロトコルによって作成された保護されたチャネル内にカプセル化することもできるし、TLS [RFC2246] 内にカプセル化することもできる。しかし、セクション 7.4 で述べたように、EAP トンネリングは中間者脆弱性をもたらす可能性がある。
既存の EAP 方式は、複数の EAP パケットをカバーする message integrity check (MIC) を定義している。たとえば、EAP-TLS [RFC2716] は、複数のフラグメントに分割される可能性のある TLS レコードに対する MIC を定義している。FINISHED メッセージ内では、MIC は以前のメッセージに対して計算される。MIC が複数の EAP パケットをカバーする場合、MIC 検証の失敗は通常、致命的なエラーと見なされる。
EAP-TLS [RFC2716] では、MIC 検証の失敗は、TLS [RFC2246] で規定されているため、致命的なエラーとして扱われる。しかし、パケットごとの MIC をサポートし、検証失敗に対して違反パケットを静かに廃棄することで応答する EAP 方式を開発することも可能である。
このドキュメントでは、EAP メッセージ処理の説明は、パケットごとの MIC 検証が行われる場合、それがパケットを受信したホストの状態を変更したり応答を送信したりする前に実行されるかのように効果的に行われることを前提としている。
7.6. 辞書攻撃
EAP-MD5、MS-CHAPv1 [RFC2433]、Kerberos V [RFC1510] などのパスワード認証アルゴリズムは、辞書攻撃に対して脆弱であることが知られている。MS-CHAPv1 の脆弱性は [PPTPv1] に、MS-CHAPv2 の脆弱性は [PPTPv2] に記述されており、Kerberos の脆弱性は [KRBATTACK]、[KRBLIM]、[KERB4WEAK] に記述されている。
辞書攻撃を防ぐために、辞書攻撃に抵抗する認証方式（セクション 7.2.1 で定義）を使用することが推奨される。
辞書攻撃に対して脆弱であることが知られている認証アルゴリズムを使用する場合、追加の保護を提供するためにセッションを保護されたチャネル内にトンネリングすることができる。しかし、セクション 7.4 で述べたように、EAP トンネリングは中間者脆弱性をもたらす可能性があるため、辞書攻撃に抵抗する方式が望ましい。
7.7. 信頼されていないネットワークへの接続
EAP-MD5 などの一方向認証をサポートする EAP 方式では、peer は authenticator を認証しないため、peer は悪意のある authenticator による攻撃に対して脆弱である。相互認証をサポートする方式（セクション 7.2.1 で定義）は、この脆弱性に対処する。
EAP では、認証が全二重であることや、両方向で同じプロトコルが使用されることの要件はない。各方向で異なるプロトコルを使用することは完全に許容される。もちろん、これはネゴシエートされた特定のプロトコルに依存する。しかし、一般的には、各方向に 1 つずつ、2 つの一方向認証を行うよりも、単一の統合された相互認証を完了する方が望ましい。これは、同じセッションの一部であることを示すように暗号的に結合されていない別々の認証は、セクション 7.4 で議論したように中間者攻撃の対象になるためである。
7.8. ネゴシエーション攻撃
ネゴシエーション攻撃では、攻撃者は peer と authenticator に、より安全でない EAP 方式をネゴシエートするよう説得しようとする。EAP は Nak Response パケットに対する保護を提供しないが、方式が Nak Response を方式固有の MIC 内にカバーすることは可能である。
各 authenticator 内またはそれに関連して、特定の名前付き peer が方式の選択をサポートすることは予想されていない。これにより、peer は一連の方式の中から最も安全でない方式をネゴシエートする攻撃に対して脆弱になる。代わりに、各名前付き peer について、その peer 名を認証するために使用される正確に 1 つの方式を示す表示があるべきである (SHOULD)。peer が異なる状況下で異なる認証方式を利用する必要がある場合、それぞれが正確に 1 つの認証方式を識別する別個の識別情報を使用すべきである (SHOULD)。
7.9. 実装の特異性
EAP と PPP や IEEE 802 などの下位層との相互作用は、実装に大きく依存する。
たとえば、認証が失敗した場合、一部の PPP 実装はリンクを終了せず、代わりにネットワーク層プロトコルのトラフィックをフィルタリングされたサブセットに制限し、これにより peer は秘密を更新したり、問題を示すメールをネットワーク管理者に送信したりする機会を得る。同様に、[IEEE-802.1X] では認証失敗により制御ポートへのアクセスが拒否されるが、非制御ポートでは限られたトラフィックが許可される場合がある。
EAP には、失敗した認証の再試行に関する規定はない。しかし、PPP では、LCP 状態マシンはいつでも認証プロトコルを再ネゴシエートできるため、新しい試行が可能である。同様に、IEEE 802.1X では、サプリカントまたは authenticator はいつでも再認証できる。認証失敗に使用されるカウンタは、認証に成功するまで、または失敗したリンクのその後の終了までリセットされないことが推奨される。
7.10. 鍵導出
peer と EAP サーバが相互に認証し、鍵を導出することは可能である。その後ネゴシエートされる暗号スイートで使用するための鍵素材を提供するために、鍵導出をサポートする EAP 方式は、少なくとも 64 オクテットのマスターセッション鍵 (MSK) と、少なくとも 64 オクテットの拡張マスターセッション鍵 (EMSK) をエクスポートしなければならない (MUST)。鍵を導出する EAP 方式は、EAP peer と EAP サーバ間の相互認証を提供しなければならなければならない (MUST)。
MSK と EMSK は、データを保護するために直接使用してはならない (MUST NOT)。しかし、それらは、選択された暗号スイートで使用するための一時セッション鍵 (TSK) を導出するためにその後使用される AAA-Key を導出するのに十分なサイズである。各暗号スイートは、AAA-Key から TSK を導出する方法を指定する責任がある。
AAA-Key は、EAP 方式によってエクスポートされた鍵素材（MSK および EMSK）から導出される。この導出は AAA サーバで行われる。EAP を使用する多くの既存のプロトコルでは、AAA-Key と MSK は同等であるが、より複雑なメカニズムも可能である（詳細については [KEYFRAME] を参照）。
EAP 方式は、たとえ一方の当事者が高品質の乱数生成器を持っていない場合でも、MSK と EMSK の鮮度を確保すべきである (SHOULD)。推奨される方法は、各当事者が少なくとも 128 ビットのナンスを提供し、それを MSK と EMSK の導出に使用することである。
EAP 方式は、EAP 方式を暗号スイートやメディアから独立させるために、MSK と EMSK をエクスポートし、一時セッション鍵はエクスポートしない。EAP 方式によってエクスポートされた鍵素材は、データを保護するためにネゴシエートされた暗号スイートから独立していなければならない (MUST)。
下位層によっては、EAP 方式は暗号スイートネゴシエーションの前または後に実行される可能性があるため、選択された暗号スイートが EAP 方式に知られていない場合がある。あらゆる暗号スイートで使用可能な鍵素材を提供することで、EAP 方式は幅広い暗号スイートやメディアと共に使用できる。
アルゴリズムの独立性を維持するために、鍵を導出する EAP 方式は、peer とサーバ間で EAP セッションを保護するために使用される暗号スイートの保護されたネゴシエーションをサポートし（および文書化し）なければならない (SHOULD)。これは、データを保護するために使用される、peer と authenticator 間でネゴシエートされた暗号スイートとは異なる。
データを保護するために使用される一時セッション鍵 (TSK) の強度は、最終的に EAP 方式によって生成された鍵の強度に依存する。EAP 方式が十分な強度の鍵素材を生成できない場合、TSK はブルートフォース攻撃の対象になる可能性がある。強力な鍵を必要とする展開を可能にするために、鍵導出をサポートする EAP 方式は、それぞれが少なくとも 128 ビットの実効鍵強度を持つ MSK と EMSK を生成できることが望ましい (SHOULD)。
鍵導出をサポートする方式は、EAP 鍵階層内の MSK と EMSK の分岐間の暗号的な分離を実証しなければならなければならない (MUST)。基本的な暗号仮定（一方向関数の非可逆性など）に違反することなく、MSK または EMSK を回復した攻撃者は、ブルートフォースよりも低い労力で他方の量を回復できてはならない (MUST NOT)。
セクション 7.2.1 で定義されているように、MSK の重複しない部分文字列は互いに暗号的に分離されていなければならなければならない (MUST)。すなわち、ある部分文字列を知っていることは、いくつかの困難な暗号仮定を破ることなく、他の部分文字列を回復する助けになってはならない (MUST NOT)。これは、一部の既存の暗号スイートが AAA-Key を適切な長さの断片に単純に分割することで TSK を形成するためである。同様に、EMSK の重複しない部分文字列は互いに、および MSK の部分文字列から暗号的に分離されていなければならなければならない (MUST)。
EMSK は将来の使用のために予約されており、それが導出された EAP peer および EAP サーバ上に留まらなければならなければならない (MUST)。それは追加の当事者に転送されたり、共有されたり、または他の鍵を導出するために使用されてはならない (MUST NOT)。（この制限は、EMSK の使用方法を規定する将来のドキュメントで緩和される。）
EAP は明示的な鍵ライフタイムネゴシエーションを提供しないため、EAP peer、authenticator、および認証サーバは、一方の当事者が鍵状態を廃棄し、それが別の当事者上で有効なままである状況に備えなければならなければならない (MUST)。
この仕様は、EAP 方式が MSK と EMSK をどのように導出するか、AAA-Key を MSK および/または EMSK からどのように導出するか、または TSK を AAA-Key からどのように導出するかについての詳細なガイダンスを提供しない。
鍵導出アルゴリズムの開発と検証は困難であるため、EAP 方式は、新しいものを発明するのではなく、確立され分析された鍵導出メカニズム（IKE [RFC2409] や TLS [RFC2246] で指定されたものなど）を再利用すべきである (SHOULD)。EAP 方式はまた、確立され分析された MSK および EMSK 導出メカニズムを利用すべきである (SHOULD)。EAP 鍵導出の詳細については [KEYFRAME] を参照されたい。
7.11. 弱い暗号スイート
初期の EAP 認証の後、データパケットがパケットごとの認証、整合性、リプレイ保護なしで送信される場合、メディアへのアクセス権を持つ攻撃者は、パケットを注入したり、既存のパケット内の「ビットを反転」させたり、パケットを再生したり、セッションを完全にハイジャックしたりできる。パケットごとの機密性がないと、データパケットを盗聴することが可能である。
データの改変、偽造、盗聴を防ぐために、相互認証と鍵導出（セクション 7.2.1 で定義）をサポートする EAP 方式と、パケットごとの機密性、認証、整合性、リプレイ保護を提供する下位層を使用することが推奨される。
さらに、下位層が暗号スイートネゴシエーションを実行する場合、EAP 自身はそのネゴシエーションの整合性保護を提供しないことを理解すべきである。したがって、より弱い暗号スイートの使用につながるダウングレード攻撃を回避するために、下位層の暗号スイートネゴシエーションを実装するクライアントは、ネゴシエーションのダウングレードに対して保護すべきである (SHOULD)。
これは、ユーザがどの暗号スイートがセキュリティポリシーとして許容されるかを設定できるようにすることで実行できる。また、暗号スイートネゴシエーションは、EAP 認証から導出された鍵素材と、下位層の peer 間で事前に合意された MIC アルゴリズムを使用して認証されてもよい (MAY)。
7.12. リンク層
PPP、IEEE 802 LAN、および IEEE 802.11 ワイヤレス LAN におけるリンク層指示には、信頼性とセキュリティの問題がある。
[a] PPP。PPP では、LCP-Terminate（リンク失敗指示）や NCP（リンク成功指示）などのリンク層指示は認証も整合性保護もされていない。したがって、リンクへのアクセス権を持つ攻撃者がこれらを偽造できる。
[b] IEEE 802。IEEE 802.1X の EAPOL-Start および EAPOL-Logoff フレームは認証も整合性保護もされていない。したがって、リンクへのアクセス権を持つ攻撃者がこれらを偽造できる。
[c] IEEE 802.11。IEEE 802.11 では、リンク層指示には Disassociate および Deauthenticate フレーム（リンク失敗指示）と、4 ウェイハンドシェイクの最初のメッセージ（リンク成功指示）が含まれる。これらのメッセージは認証も整合性保護もされておらず、転送可能ではないが、範囲内の攻撃者が偽造できる。
IEEE 802.11 では、IEEE 802.1X データフレームは Class 3 ユニキャストデータフレームとして送信される可能性があり、したがって転送可能である。つまり、EAPOL-Start および EAPOL-Logoff メッセージは認証および整合性保護されていても、「事前認証」が有効になっている場合、対象から遠く離れた認証された攻撃者がこれらを偽造できる。
IEEE 802.11 では、「リンクダウン」指示はリンク失敗の信頼できない指示であり、無線信号強度は変動する可能性があり、攻撃者が生成した無線周波数干渉の影響を受ける可能性がある。不要なリセットを避けるために、これらの指示を減衰させてから EAP に渡すことが推奨される。EAP は再送をサポートしているため、一時的な接続損失に対して堅牢である。
7.13. Authenticator とバックエンド認証サーバの分離
EAP peer と EAP サーバが相互に認証し、後続のデータトラフィックを保護するために使用される暗号スイートのための AAA-Key を導出することは可能である。これは peer 上では問題にならない。なぜなら、peer と EAP クライアントは同じマシン上に存在し、必要なのはクライアントが EAP 方式によってエクスポートされた MSK と EMSK から AAA-Key を導出し、その後一時セッション鍵 (TSK) を暗号スイートモジュールに渡すことだけだからである。
しかし、authenticator と認証サーバが異なるマシン上に存在する場合、セキュリティに対していくつかの影響がある。
[a] 認証は、peer と認証サーバの間で行われ、peer と authenticator の間では行われない。これは、EAP のみを使用して、peer が通信している authenticator の同一性を検証することは不可能であることを意味する。
[b] [RFC3579] で説明されているように、authenticator は認証セッションの結果を知るために AAA プロトコルに依存しており、結果を決定するためにカプセル化された EAP パケット（存在する場合）を参照しない。実際には、authenticator と認証サーバ間で使用される AAA プロトコルは、パケットごとの認証、整合性、リプレイ保護をサポートしなければならない (MUST) ことを意味する。
[c] EAP セッション完了後、パケットごとの機密性、認証、整合性、リプレイ保護などの下位層セキュリティサービスが有効になる場合、peer と authenticator 間でセキュアアソシエーションプロトコルを実行し、peer と authenticator 間の相互認証を提供し、一時セッション鍵の活性を保証し、後続のデータのための保護された暗号スイートおよび能力ネゴシエーションを提供し、鍵の使用を同期させるべきである (SHOULD)。
[d] peer と認証サーバ間でネゴシエートされた MSK および/または EMSK から導出された AAA-Key は、authenticator に送信されてもよい (MAY)。したがって、AAA-Key を必要とする authenticator に認証サーバから伝送するためのメカニズムを提供する必要がある。AAA-Key 導出、伝送、およびラッピングメカニズムの仕様は、このドキュメントの範囲外である。AAA-Key 導出の詳細については [KEYFRAME] を参照されたい。
7.14. 平文パスワード
この仕様は、平文パスワード認証のメカニズムを定義しない。この省略は意図的なものである。平文パスワードを使用すると、EAP パケットが送信されるリンクへのアクセス権を持つ攻撃者がパスワードを捕捉できるようになる。
EAP をカプセル化するプロトコル（RADIUS [RFC3579] など）は機密性を提供しない可能性があるため、EAP パケットはその後インターネット経由で転送用にカプセル化される可能性があり、そこで攻撃者に捕捉される可能性がある。
その結果、平文パスワードは、サーバ認証を伴う保護されたトンネル内にカプセル化されない限り、EAP 内で安全に使用することはできない。セクション 7.2.1 で定義された辞書攻撃耐性のない EAP 方式には、同じリスクの一部が当てはまる。詳細についてはセクション 7.6 を参照されたい。
7.15. チャネルバインディング
侵害された、または不適切に実装された EAP authenticator は、EAP peer やサーバに対して不正な情報を通信する可能性がある。これにより、authenticator が別の authenticator になりすましたり、帯域外のメカニズム（AAA や下位層プロトコルなど）を介して不正な情報を通信したりする可能性がある。
パススルーモードで EAP が使用される場合、EAP peer は通常、パススルー authenticator の同一性を検証せず、パススルー authenticator が EAP サーバによって信頼されていることのみを検証する。これは潜在的なセキュリティ脆弱性を生み出す。
[RFC3579] のセクション 4.3.7 は、別の authenticator になりすますことを試みる（たとえば、AAA プロトコルを介して不正な NAS-Identifier [RFC2865]、NAS-IP-Address [RFC2865]、または NAS-IPv6-Address [RFC3162] 属性を送信することによって）EAP パススルー authenticator が、AAA クライアントとして動作している場合にどのように検出できるかを説明している。しかし、AAA クライアントとして動作するパススルー authenticator は、下位層プロトコルを介して EAP peer に誤解を招く情報を通信しながら、AAA サーバに正しい情報を提供する可能性がある。
たとえば、侵害された authenticator は、下位層プロトコルを介して EAP peer と通信する際に、別の authenticator の Called-Station-Id または NAS-Identifier を利用したり、AAA クライアントとして動作するパススルー authenticator が AAA プロトコルを介して AAA サーバに不正な peer Calling-Station-Id [RFC2865][RFC3580] を提供したりする可能性がある。
この脆弱性に対処するために、EAP 方式は、Called-Station-Id [RFC2865][RFC3580]、Calling-Station-Id [RFC2865][RFC3580]、NAS-Identifier [RFC2865]、NAS-IP-Address [RFC2865]、NAS-IPv6-Address [RFC3162] を含む（ただしこれらに限定されない）エンドポイント識別子などのチャネル特性の保護された交換をサポートしてもよい (MAY)。
このような保護された交換を使用することで、authenticator が帯域外メカニズムを介して提供するチャネル特性を、EAP 方式内で交換されたものと照合することができる。相違が発見された場合、それらは記録されるべきである (SHOULD)。アクセス拒否などの追加のアクションも実行されてよい (MAY)。
7.16. 保護された結果表示
EAP では、Success および Failure パケットは確認も整合性保護もされていない。結果表示は、EAP が再送または認証状態の同期をサポートしない下位層上で実行される場合に、Success および Failure パケットの損失に対する回復力を向上させる。再送を提供し、[IEEE-802.11i] で定義された 4 ウェイハンドシェイクを介した認証状態の同期を提供するメディア（IEEE 802.11 など）では、追加の回復力の利益は通常わずかである。
方法や状況によっては、結果表示は攻撃者によって偽造される可能性がある。方式が結果表示、および「整合性保護」と「リプレイ保護」の要求事項をサポートする場合、その方式は保護された結果表示を提供すると言える。保護された結果表示をサポートする方式は、どの結果表示が保護され、どれが保護されていないかを示さなければならなければならない (MUST)。
保護された結果表示は、悪意のある authenticator に対する防御を要求しない。相互認証方式内では、peer が Success パケットを受け入れる前にサーバが peer に対して認証することを要求することで、攻撃者が悪意のある authenticator として行動することを防ぐことができる。
しかし、サーバが peer に対して認証した後、しかし peer がサーバに対して認証する前に、攻撃者が Success パケットを偽造する可能性がある。peer が偽造された Success パケットを受け入れ、サーバに対してまだ正常に認証されていない時にネットワークへのアクセスを試みた場合、peer に対するサービス拒否攻撃が仕掛けられる可能性がある。このような攻撃の後、下位層が失敗指示をサポートしている場合、authenticator は下位層の失敗指示を提供することで peer と状態を同期できる。詳細についてはセクション 7.12 を参照されたい。
サーバが、peer が authenticator を認証したかどうかを判断する前に peer を認証し、Success パケットを送信した場合、authenticator が peer によって認証されないとアイドルタイムアウトが発生する可能性がある。下位層でサポートされている場合、peer の不在を感知した authenticator はリソースを解放できる。
結果表示をサポートする方式では、サーバを認証した peer は、サーバがそれを正常に認証したという指示を受け取るまで、認証が成功したとはみなさない。同様に、peer を正常に認証したサーバは、peer がサーバを認証したという指示を受け取るまで、認証が成功したとはみなさない。
同期問題を避けるために、成功結果表示を送信する前に、送信側がアクセスを許可するための十分な権限が存在することを確認することが望ましいが、以下で説明するように、これが常に可能とは限らない。
結果表示は peer とサーバ間の認証結果の同期を可能にするかもしれないが、これは peer と authenticator が認可の点で同期することや、タイムアウトが発生しないことを保証するものではない。たとえば、EAP サーバは AAA プロキシによって行われた認可決定を認識できない場合がある。AAA サーバは認証が正常に完了した後にのみ認可をチェックし、認可を付与できないことを発見するか、AAA サーバはアクセスを付与するが、authenticator は一時的なリソース不足のためにそれを提供できない場合がある。これらの状況では、同期は下位層の結果表示を介してのみ達成される可能性がある。
成功表示は明示的または暗黙的である可能性がある。たとえば、方式がエラーメッセージをサポートする場合、暗黙の成功表示は、先行するエラーメッセージなしに特定のメッセージを受信することとして定義される可能性がある。失敗は通常明示的に示される。セクション 4.2 で説明したように、peer は、方式がその送信を明示的に許可していない時点で受信した Failure パケットを静かに廃棄する。たとえば、独自のエラーメッセージを提供する方式は、Failure パケットを受け入れる前に peer がエラーメッセージを受信することを要求する場合がある。
結果表示のパケットごとの認証、整合性、リプレイ保護は、偽造に対する保護を提供する。保護された結果表示は、パケットごとの認証と整合性保護に鍵を使用する必要があるため、保護された結果表示をサポートする方式は、「鍵導出」、「相互認証」、「整合性保護」、「リプレイ保護」の要求事項もサポートしなければならなければならない (MUST)。
保護された結果表示は、Success および Failure パケットの偽造によるいくつかのサービス拒否脆弱性に対処するが、すべてではない。EAP 方式は、通常、特定の状況下でのみ保護された結果表示を提供できる。たとえば、エラーは鍵導出の前に発生する可能性があるため、すべての失敗表示を保護できない可能性がある。また、結果表示が両方向でサポートされない場合や、すべての動作モードで同期が達成されない場合もある。
たとえば、EAP-TLS [RFC2716] では、クライアント認証ハンドシェイクにおいて、サーバは peer を認証するが、peer がそれを認証したという保護された指示を受信しない。対照的に、peer はサーバを認証し、サーバがそれを認証したかどうかを認識している。セッション再開ハンドシェイクでは、peer はサーバを認証するが、サーバがそれを認証したという保護された指示を受信しない。このモードでは、サーバは peer を認証し、peer がそれを認証したかどうかを認識している。