メインコンテンツまでスキップ

2. Extensible Authentication Protocol (EAP)

2. Extensible Authentication Protocol (EAP)​

EAP 認証交換は以下のように行われる。

[1] オーセンティケータは、ピアを認証するための Request を送信する。この Request には、要求内容を示す Type フィールドが含まれる。Request タイプの例には、Identity、MD5-challenge などがある。MD5-challenge タイプは CHAP 認証プロトコル [RFC1994] に非常に近い。通常、オーセンティケータは最初に Identity Request を送信するが、最初の Identity Request は必須ではなく、省略できる。たとえば、ピアの接続ポート（専用回線、専用交換機、またはダイヤルポート）によってアイデンティティが決定される場合、または他の方法（発信者識別や MAC アドレス、MD5-Challenge Response の Name フィールド内など）でアイデンティティが取得される場合、アイデンティティは不要である可能性がある。

[2] ピアは、有効な Request に応答して Response パケットを送信する。Response パケットは、Request パケットと同様に、Request の Type フィールドに対応する Type フィールドを含む。

[3] オーセンティケータは、追加の Request パケットを送信し、ピアはそれに Response で応答する。必要な限り、Request と Response のシーケンスは継続される。EAP は「ロックステップ」プロトコルであるため、最初の Request を除き、有効な Response を受信するまで新しい Request を送信してはならない (MUST NOT)。オーセンティケータは、第 4.1 節で規定されているとおり、Request の再送を担当する。適切な再送回数の後、オーセンティケータは EAP 対話を終了すべきである (SHOULD)。再送時、またはピアからの応答を得られない場合、オーセンティケータは Success または Failure パケットを送信してはならない (MUST NOT)。

[4] 対話は、オーセンティケータがピアを認証できない場合（1 つ以上の Request に対する受け入れられない Response）、この場合実装は EAP Failure (Code 4) を送信しなければならない (MUST)。あるいは、オーセンティケータが認証に成功したと判断するまで対話を続け、その場合オーセンティケータは EAP Success (Code 3) を送信しなければならない (MUST)。

長所：

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

o NAS（ネットワークアクセスサーバー）デバイス（スイッチやアクセスポイントなど）は、すべての認証方式を理解する必要がなく、バックエンド認証サーバーのパススループロキシとして動作してもよい (MAY)。パススルーのサポートはオプションである。オーセンティケータは、ローカルでピアを認証すると同時に、ローカルで実装していないリモートピアおよび認証方式のパススルーとして動作できる。

o オーセンティケータとバックエンド認証サーバーの分離により、クレデンシャルの管理とポリシー決定が簡素化される。

短所：

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

o オーセンティケータとバックエンド認証サーバーが分離されている場合、セキュリティ分析が複雑になり、必要な場合のキー配布も複雑になる。

2.1. シーケンスのサポート​

1 つの EAP 対話は、一連の方式を利用してもよい (MAY)。一般的な例は、Identity request の後に MD5-Challenge などの単一の EAP 認証方式が続く場合である。しかし、ピアとオーセンティケータは、1 つの EAP 対話内で 1 つの認証方式（タイプ 4 以上）のみを使用しなければならず (MUST)、その後オーセンティケータは Success または Failure パケットを送信しなければならない (MUST)。

ピアが初期 Request と同じタイプの Response を送信すると、オーセンティケータは、特定の方式の最終ラウンドが完了するまで（Notification-Request を除く）異なるタイプの Request を送信してはならず (MUST NOT)、また初期認証方式が完了した後に追加の方式の Request をいかなるタイプでも送信してはならない (MUST NOT)。そのような Request を受信したピアは、それを無効として黙って破棄しなければならない (MUST)。したがって、Identity の再クエリはサポートされない。

ピアは、初期の非 Nak Response を送信した後、Request に対して Nak（従来または拡張）を送信してはならない (MUST NOT)。偽造された EAP Request パケットが攻撃者によって送信される可能性があるため、オーセンティケータは予期しない Nak を受信した場合、それを破棄し、そのイベントを記録すべきである (SHOULD)。

中間者攻撃に対する脆弱性（第 7.4 節参照）および既存の実装との非互換性により、1 つの EAP 対話での複数の認証方式の使用はサポートされない。

単一の EAP 認証方式のみを使用するが、その方式内で他の方式（「トンネル」方式）を実行する場合、複数の認証方式に対する禁止は適用されない。このような「トンネル」方式は、EAP に対して単一の認証方式として現れる。複数の認証方式をサポートしないピアは、初期の EAP-Request（従来または拡張）に Nak で応答できるため、後方互換性を提供できる。セキュリティホールを解決するため、「トンネル」方式は中間者攻撃に対する保護をサポートしなければならない (MUST)。

2.2. EAP 多重化モデル​

概念的には、EAP 実装は以下のコンポーネントで構成される。

[a] 下位層。下位層は、ピアとオーセンティケータ間で 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 層は、下位層を介して EAP パケットを受信および送信し、再送検出と再送を実装し、EAP ピア層およびオーセンティケータ層との間で EAP メッセージを配信および受信する。

[c] EAP ピア層およびオーセンティケータ層。EAP 層は、Code フィールドに従って、着信 EAP パケットを EAP ピア層およびオーセンティケータ層に逆多重化（demultiplex）する。通常、特定のホスト上の EAP 実装は、ピアまたはオーセンティケータ機能のいずれかをサポートするが、ホストは同時に EAP ピアおよびオーセンティケータの両方として動作してもよい。そのような実装では、EAP ピア層とオーセンティケータ層の両方が存在する。

[d] EAP 方式層。EAP 方式は認証アルゴリズムを実装し、EAP ピア層およびオーセンティケータ層を介して EAP メッセージを送受信する。EAP 自体はフラグメント化をサポートしないため、これは EAP 方式の責任であり、EAP 方式は第 5 節で説明する。

EAP 多重化モデルを以下に示す。このモデルとオンライン動作が一致している限り、実装がこのモデルに準拠する必要はないことに注意。

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

Figure 1: EAP Multiplexing Model

EAP では、Code フィールドは IP のプロトコル番号とよく似ている。EAP 層は、Code フィールドに従って着信 EAP パケットを逆多重化すると想定される。Code=1（Request）、3（Success）、4（Failure）の EAP パケットは、実装されている場合、EAP ピア層に配信される。Code=2（Response）の EAP パケットは、EAP オーセンティケータ層（実装されている場合）に配信される。

EAP では、Type フィールドは UDP または TCP のポート番号とよく似ている。EAP ピア層およびオーセンティケータ層は、Type に従って着信 EAP パケットを逆多重化し、その Type に対応する EAP 方式にのみ配信すると想定される。ホスト上の EAP 方式実装は、そのサポートする役割に応じて、ピア層またはオーセンティケータ層（または両方）からのパケット受信用に登録できる。

EAP 認証方式は Identity にアクセスしたい可能性があるため、Identity Request および Response は、（タイプ 4 以上の）認証方式からアクセス可能であるべきである (SHOULD)。Identity タイプは第 5.1 節で説明する。

Notification Response は、ピアが Notification Request を受信したことを確認するためのみに使用され、メッセージが処理されたこと、またはユーザーに表示されたことを確認するためのものではない。Notification Request または Response の内容が他の方式で利用可能であるとは限らない。Notification タイプは第 5.2 節で説明する。

Nak（タイプ 3）または Expanded Nak（タイプ 254）は、方式ネゴシエーションに使用される。ピアは、受け入れられないタイプの初期 EAP Request に Nak Response（タイプ 3）または Expanded Nak Response（タイプ 254）で応答する。Nak Response(s) の内容が他の方式で利用可能であるとは限らない。Nak タイプ（s）は第 5.3 節で説明する。

Code が Success または Failure の EAP パケットには Type フィールドが含まれず、EAP 方式には配信されない。Success および Failure は第 4.2 節で説明する。

これらの考慮事項に照らし、Success、Failure、Nak Response(s)、および Notification Request/Response メッセージは、他の EAP 方式に送信されるデータを運ぶために使用してはならない (MUST NOT)。

2.3. パススルー動作​

「パススルーオーセンティケータ」として動作する場合、オーセンティケータは第 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 フィールドをチェックして、パケットを自身で処理するか転送するかを決定できる。互換性のあるパススルーオーセンティケータ実装は、デフォルトで任意のタイプの 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 に示す。

Peer Pass-through Authenticator Authentication Server

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

Figure 2: Pass-through Authenticator

オーセンティケータがパススルーとして動作するセッションの場合、結果はバックエンド認証サーバーから送信された Accept/Reject 指示のみに基づいて決定しなければならない (MUST)。結果は、Accept/Reject 指示と共に送信された EAP パケットの内容、またはそのようなカプセル化された EAP パケットの欠如によって決定されてはならない (MUST NOT)。

2.4. ピアツーピア動作​

EAP はピアツーピアプロトコルであるため、下位層の能力に応じて、独立して同時に行われる逆方向の認証が発生し得る。リンクの両端は同時にオーセンティケータとピアの両方として動作できる。この場合、両端で EAP オーセンティケータ層とピア層の両方を実装する必要がある。さらに、両端の EAP 方式実装は、オーセンティケータとピアの両方の機能を同時にサポートしなければならない。

EAP はピアツー�ピア動作をサポートしているが、一部の EAP 実装、方式、AAA プロトコル、およびリンク層はこの機能をサポートしていない可能性がある。一部の EAP 方式は非対称認証をサポートし、ピアにはある種のクレデンシャルを、オーセンティケータには別の種類のクレデンシャルを要求する場合がある。このような方式を使用したピアツー�ピア認証をサポートするホストは、両方の種類のクレデンシャルを構成する必要がある。

たとえば、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] 下位層での「タイブレーク」（tie-breaking）のサポート。IEEE 802.11 アドホックなどの下位層は、「タイブレーク」（相互に認証を開始する 2 つのホストが 1 回の認証のみを行う）をサポートしない。これは、802.11 が双方向グループキーハンドシェイクをサポートしている場合でも、各方向で 2 回の認証が発生する可能性があることを意味する。

[3] ピアポリシーの満足。EAP 方式は結果指示をサポートし、ピアが方式内で EAP サーバーを正常に認証したこと、およびサーバーがピアを認証したことを示すことができる。ただし、その情報が AAA プロトコルを介してオーセンティケータに提供されない限り、パススルーオーセンティケータはピアが EAP サーバーが提供したクレデンシャルを受け入れたことを知らない。オーセンティケータは、Accept パケット内のキー属性を受信することを、ピアが EAP サーバーを正常に認証したことの指示として解釈すべきである (SHOULD)。

ただし、双方向認証が行われた場合でも、EAP ピアのアクセスポリシーは、最初の EAP 交換中に満たされない可能性がある。たとえば、EAP オーセンティケータは、ピアおよびオーセンティケータの両方の役割で行動することを承認されていない可能性がある。したがって、ピアが EAP サーバーを正常に認証したことを示す指示を提供したとしても、ピアは逆方向で追加の認証を必要とする場合がある。