2. 拡張可能認証プロトコル (EAP)

EAP認証交換は次のように進行します:

[1] 認証器 (authenticator) はピア (peer) を認証するためにリクエスト (Request) を送信します。

リクエストには、要求されている内容を示す Type フィールドがあります。リクエストタイプの例には、Identity (アイデンティティ)、MD5-challenge などが含まれます。MD5-challenge タイプは、CHAP認証プロトコル [RFC1994] と密接に対応しています。通常、認証器は初期の Identity Request を送信します。ただし、初期の Identity Request は必須ではなく、バイパスされる可能性があります (MAY)。例えば、アイデンティティがピアが接続したポートによって決定される場合（専用回線、専用スイッチまたはダイヤルアップポート）、またはアイデンティティが別の方法で取得される場合（呼び出しステーションアイデンティティまたはMACアドレス、MD5-Challenge Response の Name フィールドなど）、アイデンティティは不要な場合があります。

[2] ピアは、有効なリクエストに応答して Response パケットを送信します。

Request パケットと同様に、Response パケットには Type フィールドが含まれており、これはリクエストの Type フィールドに対応します。

[3] 認証器は追加の Request パケットを送信し、ピアは Response で応答します。

リクエストとレスポンスのシーケンスは必要に応じて継続されます。EAP は「ロックステップ」プロトコルであるため、初期リクエストを除いて、有効な Response を受信する前に新しいリクエストを送信することはできません。認証器は、セクション 4.1 で説明されているようにリクエストを再送信する責任があります。適切な回数の再送信の後、認証器は EAP 会話を終了すべきです (SHOULD)。認証器は、再送信時またはピアから応答を取得できない場合、Success または Failure パケットを送信してはなりません (MUST NOT)。

[4] 会話は、認証器がピアを認証できなくなるまで継続されます（1つ以上のリクエストに対する受け入れられない応答）。その場合、認証器の実装は EAP Failure (Code 4) を送信する必要があります (MUST)。あるいは、認証会話は、認証器が認証が成功したと判断するまで継続される場合があり、その場合、認証器は EAP Success (Code 3) を送信する必要があります (MUST)。

利点:

o EAPプロトコルは、特定のメカニズムを事前に交渉することなく、複数の認証メカニズムをサポートできます。

o ネットワークアクセスサーバー (NAS) デバイス（スイッチやアクセスポイントなど）は、各認証方法を理解する必要がなく、バックエンド認証サーバーのパススルーエージェントとして機能できます (MAY)。パススルーのサポートはオプションです。認証器は、ローカルピアを認証すると同時に、ローカルで実装していない非ローカルピアおよび認証方法のパススルーとして機能できます (MAY)。

o 認証器をバックエンド認証サーバーから分離することで、資格情報管理とポリシー決定が簡素化されます。

欠点:

o PPPで使用するには、EAPはPPP LCPに新しい認証タイプを追加する必要があるため、PPP実装を使用するには変更が必要です。また、LCP中に特定の認証メカニズムを交渉する以前のPPP認証モデルから逸脱しています。同様に、スイッチまたはアクセスポイントの実装は、EAPを使用するために [IEEE-802.1X] をサポートする必要があります。

o 認証器がバックエンド認証サーバーから分離されている場合、これによりセキュリティ分析が複雑になり、必要に応じてキー配布が複雑になります。

2.1. シーケンスのサポート (Support for Sequences)

EAP会話は、メソッドのシーケンスを利用する可能性があります (MAY)。これの一般的な例は、Identity リクエストに続いて MD5-Challenge などの単一の EAP 認証方法が続くことです。ただし、ピアと認証器は、EAP会話内で1つの認証方法（タイプ4以上）のみを使用する必要があり (MUST)、その後、認証器は Success または Failure パケットを送信する必要があります (MUST)。

ピアが初期リクエストと同じタイプの Response を送信すると、認証器は、特定のメソッドの最終ラウンドが完了する前に（Notification-Request を除く）異なるタイプのリクエストを送信してはならず (MUST NOT)、初期認証方法の完了後に任意のタイプの追加メソッドのリクエストを送信してはなりません (MUST NOT)。このようなリクエストを受信したピアは、それらを無効として扱い、静かに破棄する必要があります (MUST)。その結果、Identity Requery はサポートされていません。

ピアは、初期の非Nak Responseを送信した後、Requestに応答してNak（レガシーまたは拡張）を送信してはなりません (MUST NOT)。攻撃者によって偽造されたEAP Requestパケットが送信される可能性があるため、予期しないNakを受信した認証器は、それを破棄してイベントをログに記録すべきです (SHOULD)。

EAP会話内の複数の認証方法は、中間者攻撃に対する脆弱性（セクション7.4を参照）および既存の実装との非互換性により、サポートされていません。

単一のEAP認証方法が使用されているが、その中で他の方法が実行されている場合（「トンネル化」メソッド）、複数の認証方法に対する禁止は適用されません。このような「トンネル化」メソッドは、EAPには単一の認証方法として表示されます。後方互換性を提供できます。なぜなら、「トンネル化」メソッドをサポートしていないピアは、初期EAP-RequestにNak（レガシーまたは拡張）で応答できるからです。セキュリティ脆弱性に対処するために、「トンネル化」メソッドは中間者攻撃に対する保護をサポートする必要があります (MUST)。

2.2. EAP多重化モデル (EAP Multiplexing Model)

概念的には、EAP実装は次のコンポーネントで構成されます:

[a] 下位層 (Lower layer)。下位層は、ピアと認証器の間でEAPフレームを送受信する責任があります。EAPは、PPP、有線IEEE 802 LAN [IEEE-802.1X]、IEEE 802.11ワイヤレスLAN [IEEE-802.11]、UDP（L2TP [RFC2661]およびIKEv2 [IKEv2]）、TCP [PIC]など、さまざまな下位層で実行されています。下位層の動作については、セクション3で説明します。

[b] EAP層 (EAP layer)。EAP層は、下位層を介してEAPパケットを送受信し、重複検出と再送信を実装し、EAPピア層と認証器層との間でEAPメッセージを配信および受信します。

[c] EAPピアおよび認証器層 (EAP peer and authenticator layers)。Codeフィールドに基づいて、EAP層は着信EAPパケットをEAPピア層および認証器層に逆多重化します。通常、特定のホスト上のEAP実装は、ピア機能または認証器機能のいずれかをサポートしますが、ホストがEAPピアと認証器の両方として機能することも可能です。このような実装では、EAPピア層と認証器層の両方が存在します。

[d] EAPメソッド層 (EAP method layers)。EAPメソッドは認証アルゴリズムを実装し、EAPピア層および認証器層を介してEAPメッセージを送受信します。EAP自体によってフラグメンテーションサポートが提供されないため、これはEAPメソッドの責任であり、セクション5で説明されています。

EAP多重化モデルを図1に示します。実装がこのモデルに準拠する必要はなく、ワイヤ上の動作がそれと一致している限り問題ありません。

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 +------------>-------------+

図1: EAP多重化モデル

EAP内では、CodeフィールドはIPのプロトコル番号と同様に機能します。EAP層は、Codeフィールドに従って着信EAPパケットを逆多重化すると想定されています。Code=1 (Request)、3 (Success)、および4 (Failure)で受信されたEAPパケットは、実装されている場合、EAP層によってEAPピア層に配信されます。Code=2 (Response)のEAPパケットは、実装されている場合、EAP認証器層に配信されます。

EAP内では、TypeフィールドはUDPまたはTCPのポート番号と同様に機能します。EAPピア層および認証器層は、着信EAPパケットをそのTypeに従って逆多重化し、そのTypeに対応するEAPメソッドにのみ配信すると想定されています。ホスト上のEAPメソッド実装は、サポートする役割に応じて、ピア層または認証器層、あるいはその両方からパケットを受信するように登録できます。

EAP認証方法はアイデンティティにアクセスしたい場合があるため、実装は、Identityメソッドに加えて、認証方法（タイプ4以上）がIdentity RequestおよびResponseにアクセスできるようにすべきです (SHOULD)。Identity Typeについては、セクション5.1で説明します。

Notification Responseは、ピアがNotification Requestを受信したことの確認としてのみ使用され、それを処理したことやユーザーにメッセージを表示したことの確認ではありません。Notification RequestまたはResponseの内容が別のメソッドで利用可能であると仮定することはできません。Notification Typeについては、セクション5.2で説明します。

Nak (Type 3) またはExpanded Nak (Type 254) は、メソッドネゴシエーションの目的で使用されます。ピアは、受け入れられないTypeの初期EAP RequestにNak Response (Type 3) またはExpanded Nak Response (Type 254) で応答します。Nak Response(s)の内容が別のメソッドで利用可能であると仮定することはできません。Nak Type(s)については、セクション5.3で説明します。

SuccessまたはFailureのCodeを持つEAPパケットにはTypeフィールドが含まれず、EAPメソッドに配信されません。SuccessおよびFailureについては、セクション4.2で説明します。

これらの考慮事項を考えると、Success、Failure、Nak Response(s)、およびNotification Request/Responseメッセージは、他のEAPメソッドへの配信を目的としたデータを運ぶために使用してはなりません (MUST NOT)。

2.3. パススルー動作 (Pass-Through Behavior)

「パススルー認証器」として動作する場合、認証器はセクション4.1で説明されているように、Code、Identifier、およびLengthフィールドのチェックを実行します。ピアから受信し、その認証器層を宛先とするEAPパケットをバックエンド認証サーバーに転送します。バックエンド認証サーバーから受信し、ピアを宛先とするパケットはピアに転送されます。

EAPパケットを受信するホストは、それに対して3つのことのうち1つしか実行できません。それに対して動作する、それを破棄する、またはそれを転送する。転送の決定は、通常、Code、Identifier、およびLengthフィールドの検査のみに基づいています。パススルー認証器の実装は、Code=2 (Response)でピアから受信したEAPパケットをバックエンド認証サーバーに転送できる必要があります (MUST)。また、バックエンド認証サーバーからEAPパケットを受信し、Code=1 (Request)、Code=3 (Success)、およびCode=4 (Failure)のEAPパケットをピアに転送できる必要があります (MUST)。

認証器が認証器の役割をサポートする1つ以上の認証方法をローカルで実装していない限り、EAPメソッド層ヘッダーフィールド（Type、Type-Data）は転送決定の一部として検査されません。認証器がローカル認証方法をサポートしている場合、パケット自体に対して動作するか転送するかを決定するためにTypeフィールドを検査できます (MAY)。準拠するパススルー認証器実装は、デフォルトで任意のTypeのEAPパケットを転送する必要があります (MUST)。

Code=1 (Request)、Code=3 (Success)、およびCode=4 (Failure)で受信されたEAPパケットは、EAP層によって逆多重化され、ピア層に配信されます。したがって、ホストがEAPピア層を実装していない限り、これらのパケットは静かに破棄されます。同様に、Code=2 (Response)で受信されたEAPパケットは、EAP層によって逆多重化され、認証器層に配信されます。したがって、ホストがEAP認証器層を実装していない限り、これらのパケットは静かに破棄されます。「パススルーピア」の動作は、この仕様内では定義されておらず、RADIUS [RFC3579]やDiameter [DIAM-EAP]などのAAAプロトコルではサポートされていません。

転送モデルを図2に示します。

ピアパススルー認証器認証サーバー

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         +-------->--------+           +--------->-------+

図2: パススルー認証器

認証器がパススルーとして機能するセッションの場合、バックエンド認証サーバーによって送信されたAccept/Reject指示のみに基づいて認証の結果を決定する必要があります (MUST)。結果は、Accept/Reject指示とともに送信されたEAPパケットの内容、またはそのようなカプセル化されたEAPパケットの不在によって決定してはなりません (MUST NOT)。

2.4. ピアツーピア動作 (Peer-to-Peer Operation)

EAPはピアツーピアプロトコルであるため、逆方向で独立した同時認証が行われる可能性があります（下位層の機能に依存します）。リンクの両端は、同時に認証器とピアとして機能できます。この場合、両端がEAP認証器層とピア層を実装する必要があります。さらに、両方のピアのEAPメソッド実装は、認証器とピアの両方の機能をサポートする必要があります。

EAPはピアツーピア動作をサポートしていますが、一部のEAP実装、メソッド、AAAプロトコル、およびリンク層はこれをサポートしていない場合があります。一部のEAPメソッドは、ピアに必要な資格情報の1つのタイプと認証器に必要な別のタイプで、非対称認証をサポートする場合があります。このようなメソッドでピアツーピア動作をサポートするホストは、両方のタイプの資格情報でプロビジョニングする必要があります。

例えば、EAP-TLS [RFC2716]は、クライアントとサーバーに通常異なる証明書プロファイルが使用されるクライアント-サーバープロトコルです。これは、EAP-TLSを使用してピアツーピア認証をサポートするホストが、EAPピア層と認証器層の両方を実装し、EAP-TLS実装でピアと認証器の両方の役割をサポートし、各役割に適した証明書をプロビジョニングする必要があることを意味します。

RADIUS/EAP [RFC3579]やDiameter EAP [DIAM-EAP]などのAAAプロトコルは、「パススルー認証器」動作のみをサポートしています。[RFC3579]セクション2.6.2に記載されているように、RADIUSサーバーは、EAP-Request、Success、またはFailureパケットをカプセル化するAccess-RequestにAccess-Rejectで応答します。したがって、「パススルーピア」動作のサポートはありません。

相互認証と結果指示をサポートするメソッドが使用されている場合でも、いくつかの考慮事項により、2つのEAP認証（各方向に1つ）が必要になる場合があります。これらには以下が含まれます:

[1] 下位層での双方向セッションキー派生のサポート。IEEE 802.11などの下位層は、一時的なセッションキーの単方向派生とトランスポートのみをサポートする場合があります。例えば、[IEEE-802.11i]で定義されているグループキーハンドシェイクは単方向です。なぜなら、IEEE 802.11インフラストラクチャモードでは、アクセスポイント(AP)のみがマルチキャスト/ブロードキャストトラフィックを送信するためです。IEEE 802.11アドホックモードでは、どちらのピアもマルチキャスト/ブロードキャストトラフィックを送信できるため、2つの単方向グループキー交換が必要です。設計の制限により、これは各方向でユニキャストキー派生とEAPメソッド交換が必要であることも意味します。

[2] 下位層でのタイブレーキングのサポート。IEEE 802.11アドホックなどの下位層は、2つのホストが相互に認証を開始する「タイブレーキング」をサポートしておらず、単一の認証のみを進めます。これは、802.11が双方向グループキーハンドシェイクをサポートしたとしても、各方向に1つずつ、2つの認証が依然として発生する可能性があることを意味します。

[3] ピアポリシーの満足。EAPメソッドは結果指示をサポートする場合があり、ピアがメソッド内でEAPサーバーにEAPサーバーを正常に認証したことを示すことができ、サーバーがピアを認証したことを示すこともできます。ただし、パススルー認証器は、この情報がAAAプロトコルを介して認証器に提供されない限り、ピアがEAPサーバーによって提供された資格情報を受け入れたことを認識しません。認証器は、Acceptパケット内のキー属性の受信を、ピアがサーバーを正常に認証したことの指示として解釈すべきです (SHOULD)。

ただし、相互認証が発生したとしても、初期EAP交換中にEAPピアのアクセスポリシーが満たされなかった可能性があります。例えば、EAP認証器は、ピアと認証器の両方の役割で動作する権限を示していない可能性があります。その結果、ピアがEAPサーバーが正常に認証されたことの指示を提供した場合でも、ピアは逆方向での追加の認証を必要とする場合があります。