拡張認証プロトコル

拡張認証プロトコル（EAP）は、ネットワークおよびインターネット接続で頻繁に使用される認証フレームワークです。RFC 2284 を廃止したRFC  3748で定義され、 RFC 5247で更新されています。 EAP は、EAP メソッドによって生成されたマテリアルとパラメータの転送と使用を提供するための認証フレームワークです。 RFC で定義されているメソッドは多数あり、ベンダー固有のメソッドや新しい提案も多数存在します。 EAP はワイヤプロトコルではなく、インターフェイスからの情報とフォーマットのみを定義します。 EAP を使用する各プロトコルは、ユーザーがそのプロトコルのメッセージ内に EAP メッセージをカプセル化する方法を定義します。   

EAPは広く使用されています。例えば、IEEE 802.11（Wi-Fi）では、WPAおよびWPA2規格において、IEEE 802.1X（様々なEAPタイプを含む）が標準的な認証メカニズムとして採用されています。

方法

EAPは認証フレームワークであり、特定の認証メカニズムではありません。^{[ 1 ]} EAPは、EAPメソッドと呼ばれる認証方法の共通機能とネゴシエーションを提供します。現在、約40種類のメソッドが定義されています。IETF RFCで定義されているメソッドには、EAP-MD5、EAP-POTP、EAP-GTC、EAP-TLS、EAP-IKEv2、EAP-SIM、EAP-AKA、EAP-AKA'などがあります。さらに、ベンダー固有のメソッドや新しい提案も多数存在します。ワイヤレスネットワークで動作可能な一般的な最新のメソッドには、EAP-TLS、EAP-SIM、EAP-AKA、LEAP、EAP-TTLSなどがあります。無線LAN認証で使用されるEAPメソッドの要件は、 RFC 4017に記載されています。EAPで使用されるタイプとパケットコードのリストは、IANA EAPレジストリから入手できます。^{[ 2 ]} 

この標準では、 RFC 4962で説明されている AAA キー管理要件を満たすことができる 条件についても説明されています。 

軽量拡張認証プロトコル (LEAP)

Lightweight Extensible Authentication Protocol (LEAP) 方式は、 IEEE が802.11iセキュリティ標準を承認する前に、Cisco Systemsが開発しました。 ^{[ 3 ]} Cisco は、標準がない中で 802.1X と動的WEPを業界に導入するため、CCX (Cisco Certified Extensions) を通じてこのプロトコルを配布しました。LEAP はWindows オペレーティング システムではネイティブ サポートされていませんが、WLAN (ワイヤレス LAN) デバイスに最も一般的に含まれるサードパーティ クライアント ソフトウェアによって広くサポートされています。Microsoft Windows 7 および Microsoft Windows Vista のLEAPサポートは、LEAP と EAP-FAST の両方をサポートするクライアント アドインを Cisco からダウンロードすることによって追加できます。ネットワーク業界で LEAP が広く採用されているため、他の多くの WLAN ベンダーも LEAP のサポートを主張しています。

LEAPはMS-CHAPの修正版を使用します。MS -CHAPはユーザ認証情報が強固に保護されておらず、簡単に侵害される認証プロトコルです。ASLEAPと呼ばれるエクスプロイトツールは2004年初頭にJoshua Wrightによって公開されました。 ^{[ 4 ]}シスコは、LEAPをどうしても使用しなければならないお客様には、十分に複雑なパスワードのみを使用することを推奨していますが、複雑なパスワードは管理や強制が困難です。シスコは現在、EAP-FAST、 PEAP 、EAP-TLSなどの新しく強力なEAPプロトコルの使用を推奨しています。

EAP トランスポート層セキュリティ (EAP-TLS)

RFC 5216で定義されている EAP トランスポート層セキュリティ (EAP-TLS) は、トランスポート層セキュリティ(TLS) プロトコルを使用するIETFオープン スタンダードであり、ワイヤレス ベンダーの間で広くサポートされています。EAP-TLS は、オリジナルの標準ワイヤレス LAN EAP 認証プロトコルです。  

EAP-TLS は今でも最も安全な EAP 標準の 1 つと考えられていますが、TLS が強力なセキュリティを提供するのは、ユーザーが偽の資格情報に関する潜在的な警告を理解している場合に限られ、無線 LAN ハードウェアおよびソフトウェアのすべてのメーカーによって広くサポートされています。2005 年 4 月までは、EAP-TLS は WPA または WPA2 ロゴの認定を受ける必要のある唯一の EAP タイプのベンダーでした。^{[ 5 ]} EAP-TLS のクライアントおよびサーバーの実装は、3Com、Apple、Avaya、Brocade Communications、Cisco、Enterasys Networks、Fortinet、Foundry、Hirschmann、HP、Juniper、Microsoft、およびオープンソースのオペレーティングシステムにあります。EAP- TLSは、Mac OS X 10.3 以上、wpa_supplicant、Windows 2000 SP4、Windows XP 以上、Windows Mobile 2003 以上、Windows CE 4.2、および Apple の iOS モバイルオペレーティングシステムでネイティブにサポートされています。

ワールド ワイド ウェブなどのHTTPSのほとんどの TLS 実装とは異なり、 EAP-TLS の実装の大部分は、標準でその使用が義務付けられていなくても、クライアント側のX.509証明書を使用した相互認証を必要とし、その要件を無効にするオプションは提供されていません。^{[ 6 ] [ 7 ]}一部の人は、これが EAP-TLS の採用を劇的に減らし、「オープン」だが暗号化されたアクセス ポイントを妨げる可能性があると認識しています。^{[ 6 ] [ 7 ]} 2012 年 8 月 22 日に、 hostapd (および wpa_supplicant) はGitリポジトリにベンダー固有の UNAUTH-TLS EAP タイプ (hostapd/wpa_supplicant プロジェクトのRFC 5612プライベート エンタープライズ番号を使用) のサポートを追加しました。^{[ 8 ]また、2014 年 2 月 25 日には、}ベンダー固有の WFA-UNAUTH-TLS EAP タイプ ( Wi-Fi Allianceプライベート エンタープライズ番号を使用)のサポートを追加しました。^{[ 9 ] [ 10}これにより、HTTPSによく似た状況が可能になります。つまり、無線ホットスポットは自由なアクセスを許可し、ステーションクライアントを認証しないものの、ステーションクライアントは暗号化（IEEE 802.11i-2004、つまりWPA2）を使用し、無線ホットスポットを認証する必要がある場合です。また、アクセスポイントがサーバー側認証のみでEAP-TLSを許可していることを、ベンダー固有のEAPタイプではなく標準のIETFタイプであるEAP-TLSを使用して通知するために、 IEEE 802.11uを使用するという提案もあります。^{[ 11 ]} 

クライアント側証明書の要件は、どれほど不評であろうとも、EAP-TLSの認証の強度を高め、利便性とセキュリティの典型的なトレードオフを如実に物語っています。クライアント側証明書があれば、侵入者は依然としてクライアント側証明書を所持している必要があるため、パスワードが侵害されただけではEAP-TLS対応システムに侵入できません。実際、パスワードはクライアント側証明書を暗号化して保存するためにのみ使用されるため、パスワードは不要です。最も高いセキュリティを実現するには、クライアント側証明書の「秘密鍵」をスマートカードに格納する必要があります。^{[ 12 ]}これは、スマートカード自体を盗まない限り、クライアント側証明書に対応する秘密鍵をスマートカードから盗む方法がないためです。（典型的な）パスワードの盗難よりも​​、スマートカードの物理的な盗難の方が、（そしてスマートカードが直ちに失効される）ことに気付く可能性が高くなります。さらに、スマート カード上の秘密鍵は通常、スマート カードの所有者のみが知っている PIN を使用して暗号化されるため、カードが盗難されたと報告され、取り消される前であっても、窃盗犯にとってそのカードの有用性は最小限に抑えられます。

EAP-MD5

EAP-MD5は、EAPのオリジナルRFCであるRFC 2284で初めて定義された当時、唯一のIETF標準化過程ベースのEAP方式でした。この方式は最低限のセキュリティしか提供しません。MD5ハッシュ関数は辞書攻撃に対して脆弱であり、キー生成をサポートしていないため、動的WEPやWPA/WPA2エンタープライズでの使用には適していません。EAP-MD5は、EAPピアからEAPサーバーへの認証のみを提供し、相互認証を提供しない点で他のEAP方式と異なります。EAPサーバー認証を提供しないことで、このEAP方式は中間者攻撃に対して脆弱です。^{[ 13 ]} EAP-MD5のサポートはWindows 2000で初めて追加され、 Windows Vistaで廃止されました。^{[ 14 ]} 

EAP 保護ワンタイムパスワード (EAP-POTP)

RFC 4793に記載されているEAP保護ワンタイムパスワード（EAP-POTP）は、RSA Laboratoriesによって開発されたEAP方式であり、ハンドヘルドハードウェアデバイスやパーソナルコンピュータ上で実行されるハードウェアまたはソフトウェアモジュールなどのワンタイムパスワード（OTP）トークンを使用して認証キーを生成します。EAP-POTPは、EAPを使用するプロトコルにおいて、片側認証または相互認証とキーマテリアルを提供するために使用できます。  

EAP-POTP方式は2要素ユーザー認証を提供します。つまり、ユーザーは認証を実行するためにトークンへの物理的なアクセスと個人識別番号（PIN）の知識の両方を必要とします。^{[ 15 ]}

EAP 事前共有キー (EAP-PSK)

^{[ 1 ]} RFC4764で定義されているEAP事前共有鍵（EAP-PSK）事前共有鍵を用いた相互認証とセッション鍵導出のためのEAP方式です。相互認証が成功した場合、双方が通信するための保護された通信チャネルを提供し、IEEE 802.11などの安全でないネットワーク上での認証用に設計されています。  

EAP-PSKは、公開鍵暗号を必要としない軽量かつ拡張可能なEAP方式を提供する実験的なRFCで文書化されています。EAP方式のプロトコル交換は、最低4つのメッセージで行われます。

EAP パスワード (EAP-PWD)

RFC 5931で定義されているEAPパスワード（EAP-PWD）は、認証に共有パスワードを使用するEAP方式です。パスワードは低エントロピーのパスワードである場合があり、辞書のようなパスワードの候補セットから抽出される可能性があり、攻撃者がこれを利用できます。基盤となる鍵交換は、能動攻撃、受動攻撃、および辞書攻撃に対して耐性があります。  

EAP-PWDはAndroid 4.0（ICS）のベースに含まれています。FreeRADIUS ^{[ 16 ]}およびRadiator ^{[ 17 ]} RADIUSサーバー、hostapdおよびwpa_supplicant ^{[ 18 ]にも含まれています。}

EAP トンネル トランスポート層セキュリティ (EAP-TTLS)

EAPトンネルトランスポート層セキュリティ（EAP-TTLS）は、 TLSを拡張したEAPプロトコルです。Funk SoftwareとCerticomによって共同開発され、幅広いプラットフォームでサポートされています。Microsoftは、Windows XP、Vista、7にEAP-TTLSプロトコルのネイティブサポートを組み込んでいません。これらのプラットフォームでTTLSをサポートするには、サードパーティの暗号化制御プロトコル（ECP）認定ソフトウェアが必要です。Microsoft WindowsはWindows 8でEAP-TTLSのサポートを開始し、^{[ 19 ]} EAP-TTLSのサポートは Windows Phoneバージョン8.1で登場しました^{[ 20 ]}。^{[ 21 ]}

クライアントは、CA署名のPKI証明書を使用してサーバーに認証を受けることができますが、必ずしもそうする必要はありません。これにより、すべてのクライアントに証明書が必要なくなるため、セットアップ手順が大幅に簡素化されます。

サーバーがCA証明書を介してクライアントに対して安全に認証され、必要に応じてクライアントがサーバーに対して認証された後、サーバーは確立された安全な接続（「トンネル」）を使用してクライアントを認証できます。サーバーは、既存の広く普及している認証プロトコルとインフラストラクチャ（従来のパスワードメカニズムと認証データベースを組み込んでいる）を利用できます。また、安全なトンネルは盗聴や中間者攻撃から保護します。ユーザー名は暗号化されていない平文で送信されることは決してないため、プライバシーが向上します。

EAP-TTLSには、オリジナルのEAP-TTLS（別名EAP-TTLSv0）とEAP-TTLSv1という2つの異なるバージョンが存在します。EAP-TTLSv0はRFC 5281で説明されており、EAP-TTLSv1はインターネットドラフトとして利用可能です。^{[ 22 ]} 

EAP インターネット鍵交換 v. 2 (EAP-IKEv2)

EAPインターネットキー交換v.2（EAP-IKEv2）は、インターネットキー交換プロトコルバージョン2（IKEv2）に基づくEAP方式です。EAPピアとEAPサーバー間の相互認証とセッションキーの確立を提供します。以下の種類の資格情報に基づく認証技術をサポートしています。

非対称鍵ペア

公開鍵がデジタル証明書に埋め込まれ、対応する秘密鍵は 1 つの当事者のみが知っている公開鍵/秘密鍵ペア。

パスワード

サーバーとピアの両方に知られている低エントロピーのビット文字列。

対称鍵

サーバーとピアの両方に知られている高エントロピー ビット文字列。

各方向で異なる認証資格情報（および認証手法）を使用することは可能です。例えば、EAPサーバーは公開鍵と秘密鍵のペアを使用して認証し、EAPピアは対称鍵を使用して認証します。しかし、実際には9つの理論的な組み合わせすべてが想定されるわけではありません。具体的には、RFC 5106規格では4つのユースケースが挙げられています。サーバーは非対称鍵ペアで認証し、クライアントは3つの方法のいずれかを使用するケース、そして両側で対称鍵を使用するケースです。  

EAP-IKEv2 はRFC 5106で説明されており、プロトタイプ実装が存在します。  

EAP セキュア トンネリング経由のフレキシブル認証 (EAP-FAST)

EAP-FAST（Flexible Authentication via Secure Tunneling; RFC 4851 ）は、シスコシステムズがLEAPの代替として提案したプロトコルです。^{[ 23 ]}このプロトコルは、LEAPの「軽量」な実装を維持しながら、LEAPの弱点に対処するように設計されています。EAP-FASTでは、サーバ証明書の使用はオプションです。EAP-FASTは、クライアント資格情報が検証されるTLSトンネルを確立するために、Protected Access Credential（PAC）を使用します。  

EAP-FASTには3つのフェーズがあります。^{[ 24 ]}

段階	関数	説明	目的
0	インバンドプロビジョニング - 安全なフェーズ1の会話で使用する共有秘密をピアに提供する	認証付きDiffie-Hellmanプロトコル（ADHP）を使用します。このフェーズは他のフェーズとは独立しているため、将来的には他の方式（インバンドまたはアウトオブバンド）も使用できます。	クライアントがネットワークアクセスを必要とするたびにマスターシークレットを確立する必要がなくなります。
1	トンネルの開設	PACを使用して認証し、トンネルキーを確立する	フェーズ2の認証プロセス中に機密性と整合性を確保するための鍵の確立
2	認証	ピアを認証する	複数のトンネル化された安全な認証メカニズム（資格情報の交換）

自動PACプロビジョニングが有効になっている場合、EAP-FASTには脆弱性があり、攻撃者がPACを傍受してユーザーの認証情報を侵害する可能性があります。この脆弱性は、PACを手動でプロビジョニングするか、PACプロビジョニングフェーズでサーバー証明書を使用することで軽減されます。

PACファイルはユーザーごとに発行される点に注意してください。これはRFC 4851 sec 7.4.4の要件であり、新しいユーザーがデバイスからネットワークにログオンする場合は、まず新しいPACファイルをプロビジョニングする必要があります。これが、EAP-FASTを安全でない匿名プロビジョニングモードで実行しないのが難しい理由の一つです。代替案としてはデバイスのパスワードを使用する方法がありますが、その場合、ネットワーク上ではユーザーではなくデバイスが検証されます。  

EAP-FAST は PAC ファイルなしで使用でき、通常の TLS にフォールバックします。

EAP-FASTはApple OS X 10.4.8以降でネイティブサポートされています。シスコは、新しい認証方式やサプリカントに対応する拡張可能なEAPHostアーキテクチャを備えたWindows Vista ^{[ 26 ]}以降のオペレーティングシステム向けにEAP-FASTモジュール^{[ 25 ]}を提供しています。^{[ 27 ]}

トンネル拡張認証プロトコル (TEAP)

トンネル拡張認証プロトコル（TEAP、RFC 7170）は、トンネルベースのEAP方式であり、トランスポート層セキュリティ（TLS）プロトコルを使用して相互認証されたトンネルを確立することにより、ピアとサーバー間の安全な通信を実現します。トンネル内では、TLV（Type-Length-Value）オブジェクトを使用して、EAPピアとEAPサーバー間の認証関連データが伝送されます。  

TEAPでは、ピア認証に加えて、 PKCS#10形式の要求を送信することで、ピアがサーバーに証明書を要求することができます。証明書要求を受信し、ピアを認証した後、サーバーはPKCS#7形式（RFC 2325 ）でピアに証明書をプロビジョニングできます。また、サーバーはPKCS#7形式（ RFC 2325 ）で信頼されたルート証明書をピアに配布することもできます。これらの操作はいずれも対応するTLVに格納され、既に確立されているTLSトンネル内で安全に実行されます。   

EAP 加入者識別モジュール (EAP-SIM)

EAP 加入者識別モジュール(EAP-SIM) は、グローバル システム for モバイル コミュニケーション ( GSM ) の加入者識別モジュール (SIM) を使用して、認証およびセッション キーの配布に使用されます。

GSMセルラーネットワークでは、加入者識別モジュールカードを使用してユーザー認証を行います。EAP-SIMは、クライアントと認証、承認、アカウンティング（AAA）サーバー間のSIM認証アルゴリズムを使用し、クライアントとネットワーク間の相互認証を実現します。

EAP-SIM では、SIM カードと認証センター (AuC) 間の通信により、クライアントと AAA サーバー間の事前設定されたパスワードの必要性がなくなります。

A3/A8アルゴリズムは、異なる128ビットチャレンジを用いて複数回実行されるため、より多くの64ビットKc-sが結合/混合され、より強力な鍵が生成されます（Kc-sは直接使用されません）。GSMにおける相互認証の欠如も克服されました。

EAP-SIM はRFC 4186で説明されています。  

EAP 認証と鍵共有 (EAP-AKA)

EAP-AKA （Extensible Authentication Protocol Method for Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement）は、UMTS加入者識別モジュール（USIM ）を用いた認証およびセッションキー配布のためのEAPメカニズムです。EAP-AKAはRFC 4187で定義されています。  

EAP 認証と鍵合意プライム(EAP-AKA')

EAP-AKAの派生形であるEAP-AKAは、RFC 5448で定義されており、 3GPPコアネットワークへの非3GPPアクセスに使用されます。例えば、EVDO、WiFi、WiMax経由などです。  

EAP 汎用トークン カード (EAP-GTC)

EAP Generic Token Card（EAP-GTC）は、PEAPv0/EAP-MSCHAPv2の代替としてシスコが開発したEAP方式であり、RFC 2284およびRFC 3748で定義されています。EAP-GTCは、認証サーバからのテキストチャレンジと、セキュリティトークンによって生成された応答を伝送します。PEAP-GTC認証メカニズムは、Novell Directory Service（NDS）やLightweight Directory Access Protocol （LDAP）などの多くのデータベースへの汎用認証に加え、ワンタイムパスワードの使用を可能にします。   

EAP 暗号化キー交換 (EAP-EKE)

暗号化鍵交換（EAP-EKE）を伴うEAPは、短いパスワードを使用し、公開鍵証明書を必要とせずに安全な相互認証を提供する数少ないEAP方式の一つです。これは、よく知られているEKEプロトコルの Diffie-Hellman版に基づく、3ラウンドの交換方式です。

EAP-EKE はRFC 6124で規定されています。  

EAP 用の Nimble アウトオブバンド認証 (EAP-NOOB)

EAP用のNimble帯域外認証^{[ 28 ]}（EAP-NOOB）は、認証資格情報が事前に設定されておらず、どのサーバーにも登録されていないデバイスのための汎用ブートストラップソリューションです。所有者、ネットワーク、サーバーに関する情報を持たないIoT（モノのインターネット）ガジェットや玩具に特に有効です。このEAP方式の認証は、サーバーとピア間のユーザー支援型帯域外（OOB）チャネルに基づいています。EAP-NOOBは、QRコード、NFCタグ、オーディオなど、多くの種類のOOBチャネルをサポートしており、他のEAP方式とは異なり、プロトコルのセキュリティはProVerifおよびMCRL2ツールによる仕様の正式なモデリングによって検証されています。^{[ 29 ]}

EAP-NOOBは、インバンドEAPチャネル上でEphemeral Elliptic Curve Diffie-Hellman（ECDHE）方式を実行します。ユーザーはOOBメッセージを転送することで、この交換を確認します。例えば、デバイスがQRコードを表示できるスマートテレビの場合、ユーザーはピアからサーバーにOOBメッセージを転送できます。また、例えば、ブートストラップ対象のデバイスがQRコードの読み取りのみ可能なカメラの場合、ユーザーはサーバーからピアにOOBメッセージを転送できます。

カプセル化

EAPは有線プロトコルではなく、メッセージフォーマットのみを定義します。EAPを使用する各プロトコルは、EAPメッセージをそのプロトコルのメッセージ内にカプセル化する方法を定義します。^{[ 30 ] [ 31 ]}

IEEE 802.1X

IEEE 802 を介した EAP のカプセル化はIEEE 802.1Xで定義されており、「EAP over LANs」または EAPOL として知られています。^{[ 32 ] [ 33 ] [ 34 ]} EAPOL はもともと802.1X-2001 でIEEE 802.3イーサネット用に設計されましたが、 802.1X-2004 でIEEE 802.11ワイヤレスやファイバー分散データインターフェース(ANSI X3T9.5/X3T12、ISO 9314 として採用) などの他の IEEE 802 LAN 技術に適合するように明確化されました。^{[ 35 ]} EAPOL プロトコルは、802.1X-2010 でIEEE 802.1AE (MACsec) およびIEEE 802.1AR (初期デバイス ID、IDevID)で使用できるように変更されました。 ^{[ 36 ]}

EAP がIEEE 802.11i-2004ワイヤレス アクセス ポイント (WAP)などの802.1X 対応ネットワーク アクセス サーバー(NAS) デバイスによって呼び出されると、最新の EAP 方式によって安全な認証メカニズムが提供され、クライアントと NAS の間で安全な秘密キー (ペアワイズ マスター キー、PMK) がネゴシエートされます。その後、この秘密キーはTKIPまたはCCMP ( AESに基づく) 暗号化を利用したワイヤレス暗号化セッションに使用できます。

ピープ

保護拡張認証プロトコル（Protected Extensible Authentication Protocol）は、保護EAPまたは単にPEAPとも呼ばれ、EAPを暗号化および認証されたトランスポート層セキュリティ（TLS）トンネル内にカプセル化するプロトコルです。^{[ 37 ] [ 38 ] [ 39 ]}その目的は、EAPの欠陥を修正することでした。EAPは、物理的セキュリティによって提供されるような保護された通信チャネルを想定していたため、EAP会話を保護するための機能は提供されていませんでした。^{[ 40 ]}

PEAPはシスコシステムズ、マイクロソフト、RSAセキュリティによって共同開発されました。PEAPv0はMicrosoft Windows XPに含まれていたバージョンで、draft-kamath-pppext-peapv0-00で名目上定義されていました。PEAPv1とPEAPv2はdraft-josefsson-pppext-eap-tls-eapの異なるバージョンで定義されていました。PEAPv1はdraft-josefsson-pppext-eap-tls-eap-00からdraft-josefsson-pppext-eap-tls-eap-05まで定義され、^{[ 41 ]} PEAPv2はdraft-josefsson-pppext-eap-tls-eap-06以降のバージョンで定義されました。^{[ 42 ]}

このプロトコルは複数のEAPメカニズムの連鎖のみを規定しており、特定の方法は規定していない。^{[ 38 ] [ 43 ]} EAP-MSCHAPv2とEAP-GTC方式の使用が最も一般的にサポートされている。

半径と直径

RADIUSプロトコルとDiameter AAAプロトコルはどちらもEAPメッセージをカプセル化できます。これらのプロトコルは、ネットワークアクセスサーバー（NAS）デバイスがIEEE 802.1XエンドポイントとAAAサーバー間でEAPパケットを転送し、IEEE 802.1Xの利便性を高めるためによく使用されます。

パナ

PANA（ネットワークアクセス認証プロトコル）は、デバイスがネットワークへのアクセスを許可される際に自身を認証するためのIPベースのプロトコルです。PANAでは、新しい認証プロトコル、鍵配布プロトコル、鍵共有プロトコル、鍵導出プロトコルは定義されません。これらの目的にはEAPが使用され、PANAがEAPペイロードを伝送します。PANAは動的なサービスプロバイダ選択を可能にし、様々な認証方式をサポートし、ローミングユーザーに適しており、リンク層メカニズムから独立しています。

購買力平価

EAPは元々 、ポイントツーポイントプロトコル（PPP）の認証拡張機能でした。EAPは、チャレンジハンドシェイク認証プロトコル（CHAP）とパスワード認証プロトコル（PAP）の代替として開発され、最終的にEAPに組み込まれて以来、PPPはEAPをサポートしています。PPPのEAP拡張機能は、 RFC 2284で最初に定義されましたが、現在はRFC 3748によって廃止されています。   

参照

• 認証プロトコル
• ハンドオーバーキーイング
• ITU-T X.1035

参考文献

1. 「はじめに」 .拡張認証プロトコル (EAP) . sec. 1. doi : 10.17487/RFC3748 . RFC 3748 .
2. 「拡張認証プロトコル（EAP）レジストリ」 www.iana.org . 2021年6月1日閲覧。
3. George Ou (2007年1月11日). 「究極のワイヤレスセキュリティガイド：LEAP認証入門」 . TechRepublic . 2008年2月17日閲覧。
4. Dan Jones (2003年10月1日). "Look Before You LEAP" . Unstrung. 2008年2月9日時点のオリジナルよりアーカイブ。2008年2月17日閲覧。
5. 「更新されたWPAおよびWPA2規格について理解する」 techrepublic.com 2008年2月17日閲覧。
6. Byrd, Christopher (2010年5月5日). 「Open Secure Wireless」(PDF) . 2013年12月12日時点のオリジナル(PDF)からのアーカイブ。 2013年8月14日閲覧。
7. EAP-TLS認証プロトコル. 2008年3月. doi : 10.17487/RFC5216 . RFC 5216 . certificate_requestメッセージは、サーバーがピアに公開鍵による認証を要求する場合に使用されます。EAPサーバーはピア認証を要求すべきですが、ピア認証が不要な状況（[UNAUTH]で説明されている緊急サービスなど）や、ピアが他の手段で認証を行う場合があるため、必須ではありません。
8. 「UNAUTH-TLSベンダー固有のEAPタイプを追加」 . hostapd . 2013年2月13日時点のオリジナルよりアーカイブ。 2013年8月14日閲覧。
9. 「HS 2.0R2: WFAサーバーのみのEAP-TLSピア方式を追加」 . hostapd . 2014年9月30日時点のオリジナルよりアーカイブ。 2014年5月6日閲覧。
10. 「HS 2.0R2: WFAサーバーのみのEAP-TLSサーバー方式を追加」 . hostapd . 2014年9月30日時点のオリジナルよりアーカイブ。 2014年5月6日閲覧。
11. Byrd, Christopher (2011年11月1日). 「Open Secure Wireless 2.0」 . 2013年11月26日時点のオリジナルよりアーカイブ。 2013年8月14日閲覧。
12. ランド・モリモト、ケントン・ガーディニア、マイケル・ノエル、ジョー・コカ (2003). Microsoft Exchange Server 2003 Unleashed . Sams. p. 244. ISBN 978-0-672-32581-6。
13. 「代替暗号化方式：静的WEPの弱点を狙う」 Ars Technica . 2008年2月17日閲覧。
14. "922574"、ナレッジベース、Microsoft
15. 「EAP-POTP認証プロトコル」 . J​​uniper.net . 2014年4月17日閲覧。
16. FreeRADIUS EAPモジュール rlm_eap_pwd
17. McCauley, Mike. 「RFC 5931に従ってEAP-PWDのサポートを追加しました」。radiator -announce（メーリングリスト）。
18. パスワードのみによる安全な認証
19. ネットワークアクセスのための拡張認証プロトコル（EAP）設定
20. 「802.1x / EAP TTLS のサポート？ – Windows Phone Central フォーラム」 . Forums.wpcentral.com . 2014年4月17日閲覧。
21. 「エンタープライズWi-Fi認証（EAP）」 . Microsoft.com . 2014年4月23日閲覧。
22. EAPトンネルTLS認証プロトコルバージョン1（EAP-TTLSv1）。ID draft-funk-eap-ttls-v1-01。
23. 「究極のワイヤレスセキュリティガイド：Cisco EAP-FAST認証入門」 techrepublic.com。2008年3月24日時点のオリジナル記事よりアーカイブ。 2008年2月17日閲覧。
24. 「EAP-FAST > WLAN向けEAP認証プロトコル」 . Ciscopress.com . 2014年4月17日閲覧。
25. 「EAP-FAST for Windows Vista 管理者ガイド」 。2009年2月10日時点のオリジナルよりアーカイブ。
26. CISCO EAP-FAST をコンピュータにインストールするにはどうすればよいですか?
27. Windows の EAPHost
28. Aura, Tuomas; Sethi, Mohit; Peltonen, A. (2021年12月). EAPのためのNimble帯域外認証 (EAP-NOOB) . doi : 10.17487/RFC9140 . RFC 9140 .
29. GitHub 上の EAP-NOOB モデル
30. ペダーセン、トーベン (2005). 「HTTPS、セキュアHTTPS」.暗号化とセキュリティ百科事典. pp.  268– 269. doi : 10.1007/0-387-23483-7_189 . ISBN 978-0-387-23473-1。
31. Plumb, Michelle, CAPPS: HTTPS ネットワーキング, OCLC 944514826 
32. 「IEEE 802におけるEAPの使用法」 .拡張認証プロトコル（EAP） . sec. 3.3. doi : 10.17487/RFC3748 . RFC 3748 .
33. 「リンク層」 .拡張認証プロトコル（EAP） . 7.12節. doi : 10.17487/RFC3748 . RFC 3748 .
34. IEEE 802.1X-2001、§7
35. IEEE 802.1X-2004、§3.2.2
36. IEEE 802.1X-2010、§5
37. 「EAPカプセル化」。MicrosoftのPEAPバージョン0（Windows XP SP1での実装）。1.1節。ID draft-kamath-pppext-peapv0-00。
38. 保護されたEAPプロトコル（PEAP）バージョン2。概要。ID draft-josefsson-pppext-eap-tls-eap-10。
39. 「はじめに」 .保護されたEAPプロトコル（PEAP）バージョン2. sec. 1. ID draft-josefsson-pppext-eap-tls-eap-10.
40. 「はじめに」 .保護されたEAPプロトコル（PEAP）バージョン2. sec. 1. ID draft-josefsson-pppext-eap-tls-eap-07.
41. 保護されたEAPプロトコル（PEAP）。2.3節。ID draft-josefsson-pppext-eap-tls-eap-05。
42. 「バージョンネゴシエーション」 .保護されたEAPプロトコル（PEAP） . 2.3節. ID draft-josefsson-pppext-eap-tls-eap-06.
43. 「プロトコルの概要」 .保護されたEAPプロトコル（PEAP）バージョン2. p. 11. ID draft-josefsson-pppext-eap-tls-eap-10.

さらに読む

• 「モバイルアクセスのためのAAAとネットワークセキュリティ。RADIUS、DIAMETER、EAP、PKI、IPモビリティ」M Nakhjiri著、John Wiley and Sons Ltd.

外部リンク

• RFC  3748 : 拡張認証プロトコル (EAP) (2004年6月)
• RFC  5247 : 拡張認証プロトコル (EAP) キー管理フレームワーク (2008 年 8 月)
• 安全な802.1x無線LAN用にRADIUSを構成する
• 安全なPEAPまたはEAP-TTLS認証のためにRADIUSサーバーに自己署名する方法
• Microsoft TechNet の拡張認証プロトコル
• Windows Vista および Windows Server 2008 の EAPHost
• ワイヤー1x
• 「IETF EAP メソッド更新 (emu) ワーキンググループ」
• 「EAP-POTP認証プロトコル」。Steel Belted Radius Carrier 7.0 管理および構成ガイド。Juniper Networks。