为什么要使用 EAP-TTLS 而不是 PEAP？

Question

据我了解，在无线网络中实施时，EAP-TTLS 和 PEAP 具有相同的安全级别。两者都仅通过证书提供服务器端身份验证。

EAP-TTLS 的缺点可能是 Microsoft Windows 中的非本机支持，因此每个用户都必须安装其他软件。

EAP-TTLS 的好处是可以支持不太安全的身份验证机制（PAP、CHAP、MS-CHAP），但为什么在现代且安全的无线系统中需要它们？

你有什么意见？为什么我应该实施 EAP-TTLS 而不是 PEAP？假设我拥有最多的 Windows 用户、中等 Linux 用户和最少的 iOS、OSX 用户。

Answer 1

客户端限制

因此，真正的问题是您的密码是如何存储的。

如果他们在：

Active Directory，然后您可以使用EAP-PEAP-MsCHAPv2（Windows 框）和EAP-TTLS-MsCHAPv2（使用 iOS 客户端）。
如果您将密码存储在LDAP 上，您可以使用EAP-TTLS-PAP（Windows 设备），但您将无法使用iOS。

您可能知道，它TLS是SSL基于受信任的中央机构（Certification Authority - CA）签署的证书的较新版本并基于其工作。

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

问题是：通常，您不会拥有由受信任的 CA 颁发的证书，而是由专门为此目的而制作的临时 CA 颁发的证书。操作系统会向用户抱怨它不知道 CA 和用户（以您为导向）会很乐意接受这一点。

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

有人可以在您的企业内部（在包中甚至在笔记本电脑上）设置一个流氓 AP，将其配置为与他自己的 Radius 服务器（在他的笔记本电脑上或在自己的流氓 AP 上运行）通信。

如果您的客户发现此 AP 的信号强于您的接入点，他们将尝试连接到它。将看到一个未知的 CA（用户接受），将建立一个TLS隧道，将发送有关此隧道的身份验证信息，流氓半径将记录它。

现在重要的部分是：如果您使用纯文本身份验证方案（PAP例如），流氓半径服务器将可以访问您的用户密码。

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

Answer 2

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

PEAP 是围绕 EAP 承载 EAP 的 SSL 包装器。TTLS 是围绕携带 RADIUS 身份验证属性的直径 TLV 的 SSL 包装器。

EAP-TTLS-PAP 可能有用（而不是 EAP-PEAP 或 EAP-TTLS），如果后端身份验证数据库以不可逆转的散列格式（例如 bigcrypt 或任何与 MSCHAP (NT-OWF) 不兼容的形式存储凭据）在此如果无法使用任何基于 CHAP 的方法进行身份验证。

虽然您也可以使用 EAP-PEAPv1-GTC 模拟 PAP，但这并没有得到客户端的广泛支持。

PEAP 以 PEAP 版本协商问题和 PEAPv1 中的历史不兼容性（例如从 PRF 派生主密钥时的客户端魔术）的形式在 TTLS 上有一些额外的负担，这些问题已经进入早期实现。

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

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

一些额外的想法：

EAP-TTLS 是由 RADIUS 供应商发明的。EAP-PEAPv0 是由微软发明的。EAP-PEAPv1 来自 IETF 流程。

在 PEAPv2 上有一些额外的 IETF 工作，通过加密绑定到内部身份验证方法，这将使系统更加安全。据我所知，这还没有发生。

Answer 3

如果您的 RADIUS 后端支持，您可以同时支持两者。然而，某些客户端“自动”连接（例如 Mac OS X >= 10.7 + iOS），如果您支持不止一种类型，它们的工作效果可能不太理想，因为它们只是尝试不同的组合，直到其中一种工作正常，即它们连接如果只有一种连接方式，麻烦会更少。

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