拡張可能な認証プロトコル

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

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

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 ]} 3Com、Apple、Avaya、Brocade Communications、Cisco、Enterasys Networks、Fortinet、Foundry、Hirschmann、HP、Juniper、Microsoft、およびオープンソースのオペレーティングシステムには、EAP-TLS のクライアントおよびサーバーの実装があります。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 ]}これにより、無線ホットスポットが無料アクセスを許可し、ステーションクライアントを認証しないが、ステーションクライアントが暗号化（IEEE 802.11i-2004、つまりWPA2 ）を使用し、無線ホットスポットを認証したい場合など、HTTPSとよく似た状況が可能になります。また、アクセスポイントがサーバー側認証のみを使用してEAP-TLSを許可することを通知するためにIEEE 802.11uを使用するという提案もあり、ベンダー固有のEAPタイプではなく、標準のEAP-TLS IETFタイプを使用します。^{[ 11 ]} 

クライアント側証明書の要件は、たとえ不評であっても、EAP-TLS の認証強度を支え、利便性とセキュリティのトレードオフという典型的な例を示しています。クライアント側証明書があれば、侵害されたパスワードだけでは EAP-TLS 対応システムに侵入することはできません。侵入者はクライアント側証明書も必要とするからです。実際、パスワードはクライアント側証明書を暗号化して保存するためにのみ使用されるため、必要ありません。最も高いセキュリティは、クライアント側証明書の「秘密鍵」がスマートカードに格納されている場合です。^{[ 12 ]}これは、スマートカード自体を盗まない限り、スマートカードからクライアント側証明書の対応する秘密鍵を盗む方法がないためです。スマートカードの物理的な盗難は、（一般的な）パスワードの盗難よりも​​、すぐに発覚し（そしてスマートカードは即座に失効する）可能性が高いのです。さらに、スマートカード上の秘密鍵は通常、スマートカードの所有者のみが知っているPINコードを使用して暗号化されているため、カードが盗難届が出されて無効化される前から、泥棒にとっての有用性は最小限に抑えられている。

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 ]} 

RFC 4793で説明されているEAP Protected One-Time Password（EAP-POTP）は、RSA Laboratoriesが開発したEAP方式で、携帯型ハードウェアデバイスやパーソナルコンピュータ上で動作するハードウェア/ソフトウェアモジュールなどのワンタイムパスワード（OTP）トークンを使用して認証キーを生成します。EAP-POTPは、EAPを使用するプロトコルにおいて、一方的または相互的な認証およびキーマテリアルを提供するために使用できます。 

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

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

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

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

EAP-PWD は Android 4.0 (ICS) の基本機能です。FreeRADIUS ^{[ 16 ]}および Radiator ^{[ 17 ]} RADIUS サーバー、hostapd および wpa_supplicant ^{[ 18 ]に含まれています。}

EAP Tunneled Transport Layer Security (EAP-TTLS) は、 TLSを拡張した EAP プロトコルです。Funk SoftwareとCerticomが共同開発し、プラットフォーム間で広くサポートされています。Microsoft は、Windows XP、Vista、または7に EAP-TTLS プロトコルのネイティブ サポートを組み込んでいません。これらのプラットフォームで TTLS をサポートするには、サードパーティの Encryption Control Protocol (ECP) 認定ソフトウェアが必要です。Microsoft Windows はWindows 8で EAP-TTLS のサポートを開始し^{[ 19 ]}、EAP-TTLS のサポート^{[ 20 ]} は Windows Phoneバージョン 8.1に登場しました。^{[ 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）は、インターネット鍵交換プロトコルバージョン2（IKEv2）に基づくEAP方式です。EAPピアとEAPサーバ間の相互認証とセッション鍵の確立を提供します。以下の種類の認証情報に基づく認証技術をサポートしています。

非対称鍵ペア

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

パスワード

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

対称鍵

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

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

EAP-IKEv2はRFC 5106で規定されており、プロトタイプ実装が存在する。 

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

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

自動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 以降でネイティブにサポートされています。Ciscoは、新しい認証方法とサプリカントのための拡張可能な EAPHost アーキテクチャを備えたWindows Vista ^{[ 26 ]}以降のオペレーティングシステム向けにEAP-FAST モジュール^{[ 25 ]}を提供しています。^{[ 27 ]}

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

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

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

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

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

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

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

ユニバーサルモバイルテレコミュニケーションシステム（UMTS）認証および鍵合意のための拡張認証プロトコル方式（EAP-AKA）は、UMTS加入者識別モジュール（USIM）を使用した認証およびセッション鍵配布のためのEAPメカニズムです。EAP-AKAはRFC 4187で定義されています。 

EAP-AKA' は、RFC 5448で定義されている EAP-AKA のバリアントであり、 3GPPコアネットワークへの非 3GPP アクセスに使用されます。たとえば、EVDO、WiFi、またはWiMAXを介してアクセスする場合などです。 

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

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

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

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

EAP-NOOBは、インバンドEAPチャネル上でエフェメラル楕円曲線ディフィー・ヘルマン（ECDHE）を実行します。ユーザーは、OOBメッセージを転送することでこの交換を確認します。例えば、QRコードを表示できるスマートテレビの場合、ユーザーはピアからサーバーへOOBメッセージを転送できます。あるいは、例えば、ブートストラップ対象のデバイスがQRコードしか読み取れないカメラの場合、ユーザーはサーバーからピアへOOBメッセージを転送できます。

IEEE 802上での EAP のカプセル化はIEEE 802.1Xで定義されており、「LAN 上の EAP」または EAPOL として知られています。^{[ 32 ] [ 33 ] [ 34 ]} EAPOL は元々 802.1X-2001 でIEEE 802.3 Ethernet 用に設計されましたが、 802.1X-2004 でIEEE 802.11無線やFiber Distributed Data Interface (ANSI X3T9.5/X3T12、ISO 9314 として採用) などの他の IEEE 802 LAN テクノロジーに適合するように明確化されました。^{[ 35 ]} EAPOL プロトコルは、 802.1X-2010 でIEEE 802.1AE (MACsec) およびIEEE 802.1AR (Initial Device Identity、IDevID) で使用するためにも変更されました。^{[ 36 ]}

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

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

PEAP は、Cisco Systems、Microsoft、および RSA Security によって共同開発されました。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メッセージをカプセル化できます。これらは、IEEE 802.1XエンドポイントとAAAサーバー間でEAPパケットを転送し、IEEE 802.1Xを円滑に動作させるために、ネットワークアクセスサーバー（NAS）デバイスでよく使用されます。

ネットワークアクセス認証プロトコル（PANA）は、デバイスがネットワークに対して認証を行い、アクセス権を取得できるようにするIPベースのプロトコルです。PANAは、新たな認証プロトコル、鍵配布、鍵合意、鍵導出プロトコルを定義するものではありません。これらの目的にはEAPが使用され、PANAはEAPペイロードを伝送します。PANAは、動的なサービスプロバイダ選択を可能にし、様々な認証方式をサポートし、ローミングユーザーに適しており、リンク層メカニズムに依存しません。

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