如果您的RADIUS后端支持，您可以同时支持。 然而，有些客户端“自动”连接（例如Mac OS X> = 10.7 + iOS），如果您支持多种types，它们可能不是最佳的，因为它们只是尝试不同的组合，直到它们中的一个如果只有一种连接方式，则可以减less麻烦。

所以基本上：只支持PEAP，或者如果您的客户端需要TTLS，则支持PEAP + TTLS。

PEAPv0，PEAPv1和TTLS具有相同的安全属性。

PEAP是EAP附带的EAP的SSL封装。 TTLS是一个带有RADIUS身份validation属性的直径TLV的SSL封装。

如果后端authentication数据库以非可逆散列格式（如bigcrypt或任何与MSCHAP（NT-OWF）不兼容的散列格式存储凭证，则EAP-TTLS-PAP可能对EAP-PEAP有用。在这种情况下，无法使用任何基于CHAP的方法。

虽然您也可以使用EAP-PEAPv1-GTC来模拟PAP，但这并不像客户那样得到广泛的支持。

PEAP对于TTLS有一些额外的负担，比如PEAP版本协商头疼和PEAPv1中的历史不兼容（比如从PRF获得主密钥时的客户端魔术），这些都是早期实现的。

我通常会看到EAP-TTLS在embedded式客户端（如用于无线设备的用户模块）中实现，而PEAP则更多地用于笔记本电脑和手机。

EAP-TTLS历来不受Windows客户端的支持，无需安装第三方软件。 现在从Windows 8开始支持EAP-TTLS。

一些额外的想法：

EAP-TTLS是由RADIUS供应商发明的。 EAP-PEAPv0是由Microsoft发明的。 EAP-PEAPv1出来了IETF过程。

在PEAPv2上还有一些额外的IETF工作，通过与内部authentication方法的encryption绑定，使系统更安全。 这还没有像我所知的那样接近任何地方。

客户限制

• 除非手动（通过计算机）安assembly置文件，否则iOS客户端将不支持带有PAP （仅限MsCHAPv2 ）的EAP-TTLS 。

• 除非客户使用英特尔无线网卡，否则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使用EAP （可扩展authentication协议）上的TLS （传输层安全性）。

如您所知， TLS是较新版本的SSL并且基于由可信中央权威机构（Certification Authority-CA）签署的证书工作。

要build立TLS隧道，客户端必须确认它正在与正确的服务器通话（在这种情况下，用于authentication用户的radius服务器）。 它通过检查服务器是否提供了由受信任的CA颁发的有效证书来做到这一点。

问题是：通常情况下，您不会拥有由可信任的CA颁发的证书，而是由您为此目的而创build的临时CA颁发的证书。 操作系统会向用户抱怨，不知道CA和用户（以你为导向）会高兴地接受这一点。

但是这会带来重大的安全风险：

有人可以在你的业务中设置一个stream氓无线接入点（在一个袋子里，甚至在笔记本电脑上），configuration它与他自己的radius服务器（运行在他的笔记本电脑或自己的stream氓无线接入点）通信。

如果你的客户发现这个AP有一个更强的信号，那么你的接入点，他们会尝试连接到它。 将看到一个未知的CA（用户接受），将build立一个TLS隧道，将发送authentication信息在这个隧道上，stream氓半径将logging它。

现在最重要的部分是： 如果您使用的是纯文本身份validationscheme（例如PAP ），那么stream氓半径服务器将有权访问您的用户密码。

您可以通过使用由证书颁发机构颁发的有效证书来解决这个问题，包括iOS，Windows（和Android）信任。 或者，您可以将CA根证书分发给您的用户，并在他们看到证书问题时通知他们拒绝连接（祝您好运）。

正如磁盘写者所说，人们使用TTLS的主要原因是您可以允许您的radius服务器以这种方式查看明文密码，这取决于您的validation后端。

一个可能有利于PEAP的更新的考虑因素是，SoH是AFAICT，只有在RADIUS服务器提出请求时才提交给AFAICT，在PEAP会话期间唯一要求在Microsoft系统上进行的方法是。 所以如果你想从无代理评估中获得类似于代理的评估（可能会有更多的AV供应商提供支持），那么你需要PEAP，但是如果你想通过采用裸体密码来解决一个单因素的OAUTH后端问题（因为哎呀，那些不能提供内部隧道服务的大型国内stream离失所者应该得到这样的支持，而且他们的用户还没有足够的把它input）使用TTLS。

您必须考虑客户端本身支持的EAP方法与其他软件以及服务器支持哪些内部authentication方法。

PEAP和EAP-TTLS旨在让您validation服务器的身份，但您必须确保客户端已正确configuration以validation证书。

PEAP和MS-CHAPv2得到了客户端的很好的支持，但是如果你的服务器不支持MS-CHAPv2（因为你不存储明文密码），你必须想出另外一个解决scheme。 这是你会看到人们使用EAP-TTLS和PAP的主要原因。

我认为自动连接会受益于这两种select，更多的select更less的麻烦…例如。 如果自动连接先尝试TTLS-PAP然后再尝试PEAP-MSCHAP，则自动连接速度更快，TTLS-PAP可用。 所以基本上都支持，我看不出缺点。

由于MSCHAPs安全性被破坏（谷歌的“裂缝mschap”）pap与明文密码通过ttls具有与PEAP-MSCHAP相同的安全级别。

我不知道EAP-TTLS和PEAP之间的安全性有什么区别，所以基本上是支持，PEAP是赢家。