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