据我了解，在无线网络中实施时，EAP-TTLS和PEAP具有相同的安全级别。两者都仅通过证书提供服务器端身份验证。
EAP-TTLS的缺点可能是Microsoft Windows中的非本机支持，因此每个用户都必须安装其他软件。
EAP-TTLS的好处是可以支持不太安全的身份验证机制（PAP，CHAP，MS-CHAP），但是为什么在现代且适当安全的无线系统中需要它们？
您对此有何看法？为什么我应该实施EAP-TTLS而不是PEAP？假设我有大多数Windows用户，中型Linux用户以及最少的iOS，OSX用户。
Answers:
如果您的RADIUS后端支持，则可以同时支持这两种方法。但是，某些客户端会“自动”连接（例如，Mac OS X> = 10.7 + iOS），并且如果您支持多种类型的客户端，它们的工作效果可能会不佳，因为它们会尝试不同的组合，直到其中一种工作即连接如果只有一种连接方式，那么麻烦就少了。
因此，基本上：仅支持PEAP，如果您有需要TTLS的客户端，则仅支持PEAP + TTLS。
iOS版客户端将不支持EAP-TTLS用PAP（只MsCHAPv2），除非你手动（通过计算机）安装配置文件。
Windows客户端将不支持EAP-TTLS即用型（您需要安装诸如secure2w之类的软件），除非它们具有Intel无线网卡。
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例如），则流氓半径服务器将可以访问您的用户密码。
您可以通过使用由证书颁发机构颁发的有效证书来解决此问题，这两个证书均受iOS，Windows（和Android）信任。或者，您可以将CA根证书分发给您的用户，并在他们看到证书问题时通知他们拒绝连接（祝您好运）。
PEAPv0，PEAPv1和TTLS具有相同的安全性属性。
PEAP是围绕带有EAP的EAP的SSL包装。TTLS是一个带有RADIUS认证属性的直径TLV的SSL包装器。
如果后端身份验证数据库以不可逆的哈希格式（例如bigcrypt或与MSCHAP（NT-OWF）不兼容的任何形式）存储凭据，则EAP-TTLS-PAP可能比EAP-PEAP有用。在这种情况下，无法使用任何基于CHAP的方法。
虽然您也可以使用EAP-PEAPv1-GTC模拟PAP，但客户端对此的支持并不广泛。
PEAP通过TEAP版本协商的麻烦以及PEAPv1中的历史不兼容（例如从PRF派生主密钥时的客户魔力）等形式，在TTLS上增加了一些负担，这些已进入早期实现。
我通常会看到EAP-TTLS在嵌入式客户端中实现，例如无线设备中的订户模块，而笔记本计算机和移动手机更多地使用了PEAP。
历史上，Windows客户端无需安装第三方软件就不支持EAP-TTLS。从Windows 8开始，现在支持EAP-TTLS。
其他一些想法：
EAP-TTLS由RADIUS供应商发明。EAP-PEAPv0由Microsoft发明。EAP-PEAPv1来自IETF流程。
在PEAPv2上还有一些其他IETF工作，通过对内部身份验证方法的加密绑定，可以使系统更安全。据我所知，这还没有到位。