私が理解したように、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つが機能するまで異なる組み合わせを試すだけなので、最適ではない場合があります。接続する方法が1つしかない場合は、面倒が少なくなります。
基本的には、PEAPのみをサポートするか、TTLSを必要とするクライアントがある場合はPEAP + TTLSをサポートします。
iOSクライアントはEAP-TTLS、PAP（MsCHAPv2コンピューターを介して）手動でプロファイルをインストールしない限り、（のみ）をサポートしません。
WindowsクライアントはEAP-TTLS、Intelワイヤレスカードを持たない限り、すぐに使用できません（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（拡張認証プロトコル）。ご存知のように、信頼できる中央機関（認証機関-CA）によって署名された証明書のTLS新しいバージョンでSSLあり、それに基づいて動作します。
TLSトンネルを確立するには、クライアントは正しいサーバー（この場合、ユーザーの認証に使用されるRADIUSサーバー）と通信していることを確認する必要があります。これは、サーバーが信頼できるCAによって発行された有効な証明書を提示したかどうかを確認することによって行われます。
問題は次のとおりです。通常、信頼できるCAによって発行された証明書はありませんが、この目的のために作成したアドホックCAによって発行された証明書はありません。運用システムは、CAとユーザー（あなたの指示どおり）が喜んでそれを受け入れることを知らないことをユーザーに不平を言うでしょう。
ただし、これには重大なセキュリティリスクが伴います。
誰かがあなたのビジネス内で（バッグ内またはラップトップ上でも）不正APをセットアップし、自分の半径サーバー（ラップトップ上または不正APで実行）と通信するように構成できます。
クライアントがこのAPがアクセスポイントよりも強力な信号を持っていると判断した場合、クライアントはそれに接続を試みます。未知のCAが表示され（ユーザーが受け入れる）、TLSトンネルを確立し、このトンネルで認証情報を送信し、不正な半径がログに記録します。
ここで重要な部分：プレーンテキスト認証スキーム（PAPたとえば）を使用している場合、不正なRADIUSサーバーはユーザーのパスワードにアクセスできます。
これは、iOS、Windows（およびAndroid）の両方が信頼する認証局によって発行された有効な証明書を使用することで解決できます。または、CAルート証明書をユーザーに配布し、証明書の問題が発生したときに接続を拒否するよう通知することができます（幸運を祈ります）。
PEAPv0、PEAPv1、およびTTLSのセキュリティプロパティは同じです。
PEAPは、EAPを運ぶEAPのSSLラッパーです。TTLSは、RADIUS認証属性を伝送するDiameter TLVのSSLラッパーです。
EAP-TTLS-PAPは、バックエンド認証データベースがbigcryptまたはMSCHAPと互換性のない形式（NT-OWF）などの非可逆ハッシュ形式で資格情報を保存する場合、EAP-PEAPよりも便利です。この場合、次を使用して認証することはできませんCHAPベースのメソッドのいずれか。
EAP-PEAPv1-GTCを使用してPAPをエミュレートすることもできますが、これはクライアントによって広くサポートされていません。
PEAPは、PEAPバージョンネゴシエーションの頭痛やPEAPv1の歴史的な非互換性（PRFからマスターキーを導出するときのクライアントマジックなど）の形で、TTLSにいくつかの追加の荷物を持ち、初期の実装になりました。
通常、ラップトップコンピューターや携帯電話で使用されるPEAPを備えたワイヤレス機器の加入者モジュールなどの組み込みクライアントにEAP-TTLSが実装されています。
EAP-TTLSは、サードパーティのソフトウェアをインストールすることなくWindowsクライアントでサポートされていませんでした。EAP-TTLSは、Windows 8以降でサポートされるようになりました。
いくつかの追加の考え：
EAP-TTLSは、RADIUSベンダーによって発明されました。EAP-PEAPv0はMicrosoftによって発明されました。EAP-PEAPv1はIETFプロセスから生まれました。
PEAPv2にはIETFの追加作業がいくつかあり、内部認証方法への暗号バインディングによってシステムのセキュリティが強化されました。これは、私が知る限り、どこにも行っていません。
Disk eaterが書いたように、人々がTTLSを使用する主な理由は、RADIUSサーバーがそのようにクリアテキストパスワードを見ることができるようにすることです。これは、認証バックエンドによっては便利です。
PEAPを支持する可能性のある新しい考慮事項は、SoHがRADIUSサーバーに要求した場合にのみ提示されるAFAICTであり、MicrosoftシステムでSoHを要求する唯一の方法はPEAPセッション中であることです。したがって、エージェントレスの評価からエージェントのような評価を取得したい場合（おそらく、より多くのAVベンダーによるサポート）、PEAPが必要になりますが、裸のパスワードを取得することによって1要素OAUTHバックエンドを回避したい場合は（ちなみに、内部トンネルサービスを提供しない大きなIDPは、それに値するものであり、ユーザーはそれを入力するのに十分に無知です）TTLSを使用します。
クライアントがネイティブにサポートするEAP方式と追加のソフトウェアを使用する場合、およびサーバーがサポートする内部認証方式を検討する必要があります。
PEAPおよびEAP-TTLSは、サーバーの識別を検証できるように設計されていますが、クライアントが証明書を検証するように適切に構成されていることを確認する必要があります。
PEAPとMS-CHAPv2はクライアントによって十分にサポートされていますが、サーバーがMS-CHAPv2をサポートしていない場合（クリアテキストパスワードを保存しないため）、別の解決策を考え出す必要があります。これが、人々がEAP-TTLSとPAPを使用する主な理由です。
自動接続は両方のオプションの恩恵を受けると思います。オプションが多ければ多いほど面倒です... 自動接続が最初にTTLS-PAPを試行し、次にPEAP-MSCHAPを試行する場合、TTLS-PAPが利用可能な場合、自動接続は高速になります。したがって、基本的には、両方をサポートしますが、欠点はありません。
MSCHAPのセキュリティが壊れているため（「crack mschap」のGoogle）、ttlsを介したクリアテキストパスワードを使用したpapは、PEAP-MSCHAPと同じレベルのセキュリティを備えています。