PEAPの代わりにEAP-TTLSを使用するのはなぜですか？
私が理解したように、EAP-TTLSとPEAPは、ワイヤレスネットワークに実装された場合、同じレベルのセキュリティを共有します。どちらも証明書によるサーバー側の認証のみを提供します。
EAP-TTLSの欠点は、Microsoft Windowsの非ネイティブサポートである可能性があるため、すべてのユーザーが追加のソフトウェアをインストールする必要があります。
EAP-TTLSの利点は、安全性の低い認証メカニズム（PAP、CHAP、MS-CHAP）をサポートできることですが、現代の適切に安全なワイヤレスシステムでそれらを必要とするのはなぜですか？
あなたの意見は何ですか？ PEAPの代わりにEAP-TTLSを実装する必要があるのはなぜですか？私には、ほとんどのWindowsユーザー、中程度のLinuxユーザー、そして最も少ないiOS、OSXユーザーがいるとしましょう。
RADIUSバックエンドがサポートしている場合、両方をサポートできます。ただし、一部のクライアントは「自動」接続（Mac OS X> = 10.7 + iOSなど）し、以下の場合は最適に動作しない可能性があります。接続する方法が1つしかない場合、接続の手間をかけずに接続するため、複数のタイプをサポートします。
基本的には、PEAPのみ、またはTTLSを必要とするクライアントがある場合はPEAP + TTLSをサポートします。
クライアントの制限
iOSクライアント手動で（コンピューターを介して）プロファイルをインストールしない限り、
PAPでEAP-TTLSをサポートしません（MsCHAPv2のみ）。Windowsクライアントは、インテルワイヤレスカードがない限り、そのままでは
EAP-TTLSをサポートしません（secure2wなどのソフトウェアをインストールする必要があります）。Android
EAPとPEAPのほぼすべての組み合わせをサポートします。
パスワードデータベースの制限
したがって、実際の問題は、パスワードがどのように保存されるかです。
彼らがいる場合：
Active Directoryの場合、
EAP-PEAP-MsCHAPv2（Windowsボックス）およびEAP-TTLS-MsCHAPv2（iOSクライアント）を使用できます。[〜＃〜] ldap [〜＃〜]にパスワードを保存する場合、
EAP-TTLS-PAP（Windowsボックス）を使用できますが、iOSについては失われます。
重要なセキュリティ上の懸念
EAP-TTLSとPEAPはどちらもTLS（拡張認証プロトコル）ではなくEAP（トランスポート層セキュリティ）を使用します。
ご存知かもしれませんが、TLSはSSLの新しいバージョンであり、信頼できる中央機関（Certification Authority-CA）によって署名された証明書に基づいて機能します。
TLSトンネルを確立するには、クライアントはそれが正しいサーバー（この場合、ユーザーの認証に使用されるRADIUSサーバー）と通信していることを確認する必要があります。これは、サーバーが信頼できるCAによって発行された有効な証明書を提示したかどうかをチェックすることによって行われます。
問題は、通常、信頼できるCAから発行された証明書ではなく、この目的のために作成したアドホックCAから発行された証明書です。運用システムは、CAとユーザー（指向）が喜んでそれを受け入れることを知らないとユーザーに不平を言うでしょう。
しかし、これは主要なセキュリティリスクをもたらします。
誰かがあなたの会社の内部（バッグの中やラップトップ上でも）に不正なAPをセットアップし、自分のRADIUSサーバー（ラップトップ上または独自の不正なAPで実行されている）と通信するように構成できます。
クライアントがこのAPの信号があなたのアクセスポイントよりも強いことを発見した場合、クライアントはそれに接続しようとします。不明なCA（ユーザーが受け入れる）が表示され、TLSトンネルが確立され、このトンネルで認証情報が送信され、不正な半径がログに記録します。
ここで重要な部分：プレーンテキスト認証スキーム（たとえば、PAP）を使用している場合、不正なRADIUSサーバーはユーザーのパスワードにアクセスできます。
これは、iOS、Windows（およびAndroid）の両方の信頼を証明機関が発行した有効な証明書を使用して解決できます。または、CAルート証明書をユーザーに配布し、証明書の問題（幸運）が発生したときに接続を拒否するようにユーザーに通知することもできます。
PEAPv0、PEAPv1、およびTTLSには同じセキュリティプロパティがあります。
PEAPは、EAPを伝送するEAPのSSLラッパーです。 TTLSは、RADIUS認証属性を運ぶ直径TLVのSSLラッパーです。
EAP-TTLS-PAPは、バックエンド認証データベースがbigcryptやMSCHAP（NT-OWF）と互換性のない任意の形式などの不可逆ハッシュ形式で資格情報を保存する場合、EAP-PEAPよりも便利です。この場合、次を使用して認証することはできません。 CHAPベースのメソッドのいずれか。
EAP-PEAPv1-GTCを使用してPAPをエミュレートすることもできますが、これはクライアントによって広くサポートされていません。
PEAPには、PEAPバージョンのネゴシエーションの頭痛とPEAPv1の歴史的な非互換性（PRFからマスターキーを取得するときのクライアントの魔法など）の形で、TTLSを介した追加の手荷物がいくつかあります。
私は通常、EAP-TTLSが無線機器の加入者モジュールなどの組み込みクライアントに実装されており、PEAPがラップトップコンピューターや携帯電話でより多く使用されています。
EAP-TTLSは、サードパーティのソフトウェアをインストールする必要がないWindowsクライアントではこれまでサポートされていませんでした。 EAP-TTLSがWindows 8以降でサポートされるようになりました。
追加の考え：
EAP-TTLSはRADIUSベンダーによって発明されました。EAP-PEAPv0はMicrosoftによって発明されました。EAP-PEAPv1はIETFプロセスから生まれました。
PEAPv2でいくつかのIETF作業が行われたため、内部認証方法への暗号バインディングによってシステムがより安全になります。これは私の知る限りどこにも行きませんでした。
ディスクイーターが書いたように、人々がTTLSを使用する主な理由は、RADIUSサーバーがクリアテキストのパスワードをそのように見ることができるようにすることです。これは、認証バックエンドによっては役立つ場合があります。
PEAPを支持する可能性がある新しい考慮事項は、SoHがRADIUSサーバーに要求された場合にのみ提示され、Microsoftシステムで要求する唯一の方法はPEAPセッション中にあることです。したがって、エージェントなしの評価からエージェントのような評価を取得したい場合（おそらく今後さらに多くのAVベンダーによるサポートが必要になります）、PEAPが必要になりますが、1要素を回避したい場合はOAUTH =ネイキッドパスワードを取得することによるバックエンド（内部トンネルサービスを提供しない大きなIDPはそれに値するものであり、ユーザーはそれを入力するのに十分な手がかりがないため）TTLSを使用します。
クライアントがネイティブでサポートするEAP方法と、追加のソフトウェアを使用する方法、およびサーバーがサポートする内部認証方法を考慮する必要があります。
PEAPおよびEAP-TTLSはサーバーのIDを検証できるように設計されていますが、証明書を検証するようにクライアントが正しく構成されていることを確認する必要があります。
PEAPとMS-CHAPv2はクライアントから十分にサポートされていますが、サーバーがMS-CHAPv2をサポートしていない場合（クリアテキストのパスワードを保存しないため）、別のソリューションを考え出す必要があります。これが、EAP-TTLSとPAPを使用する主な理由です。
自動接続は両方のオプションから恩恵を受けると思います。オプションが多いほど手間が少なくなります...例自動接続が最初にTTLS-PAPを試行し、次にPEAP-MSCHAPを試行する場合、自動接続はTTLS-PAPを使用できるため、より高速です。つまり、基本的には両方をサポートしているので、不利な点はありません。
MSCHAPのセキュリティが壊れているため（google for "crack mschap"）、ttlsを介したクリアテキストパスワードのあるpapは、PEAP-MSCHAPと同じレベルのセキュリティを備えています。