☰

客户端限制

tag-icon • tag-icon security wifi radius peap
客户端限制

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

EAP-TTLS 的缺点是 Microsoft Windows 不支持本地支持，因此每个用户都必须安装额外的软件。

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

您的看法是什么？为什么我应该实施 EAP-TTLS 而不是 PEAP？假设我的 Windows 用户最多，Linux 用户中等，iOS、OSX 用户最少。

答案1

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

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

答案2

客户端限制

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

  • Windows 客户端不支持EAP-TTLS开箱即用（您需要安装像 secure2w 这样的软件），除非他们有英特尔无线网卡。

  • 安卓支持几乎所有的EAP和的组合PEAP。

密码数据库限制

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

如果他们在：

  • 活动目录，那么您就可以使用EAP-PEAP-MsCHAPv2（Windows 盒）和EAP-TTLS-MsCHAPv2（带有 iOS 客户端）。

  • 如果你将密码存储在LDAP，你可以使用EAP-TTLS-PAP（Windows 盒子），但你会对 iOS 感到困惑。

重要的安全问题

  • EAP-TTLS和都PEAP使用TLS(传输层安全性) 而不是EAP(可扩展身份验证协议)。

您可能知道，TLS这是一个较新版本，SSL其工作基于由受信任的中央颁发机构（认证机构 - CA）签署的证书。

要建立TLS隧道，客户端必须确认它正在与正确的服务器通信（在本例中，用于验证用户的 radius 服务器）。它通过检查服务器是否提供了由受信任 CA 颁发的有效证书来实现这一点。

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

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

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

如果您的客户发现此 AP 的信号比您的接入点强，他们就会尝试连接它。将看到未知的 CA（用户接受），将建立隧道TLS，将在此隧道上发送身份验证信息，并且流氓 radius 将记录它。

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

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

答案3

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

PEAP 是围绕 EAP 进行 SSL 包装，用于承载 EAP。TTLS 是围绕 Diameter TLV 进行 SSL 包装，用于承载 RADIUS 身份验证属性。

如果后端身份验证数据库以不可逆哈希格式（例如 bigcrypt 或任何与 MSCHAP（NT-OWF）不兼容的形式）存储凭据，则 EAP-TTLS-PAP 会很有用（而不是 EAP-PEAP 或 EAP-TTLS），在这种情况下，无法使用任何基于 CHAP 的方法进行身份验证。

虽然您也可以使用 EAP-PEAPv1-GTC 模拟 PAP，但客户端并不广泛支持它。

与 TTLS 相比，PEAP 增加了一些负担，包括 PEAP 版本协商问题和 PEAPv1 中的历史不兼容性（比如从 PRF 派生主密钥时的客户端魔法），这些都已进入早期实施阶段。

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

过去，除非安装第三方软件，否则 Windows 客户端不支持 EAP-TTLS。从 Windows 8 开始，EAP-TTLS 现已受支持。

一些额外的想法：

EAP-TTLS 是由 RADIUS 供应商发明的。EAP-PEAPv0 是由 Microsoft 发明的。EAP-PEAPv1 源自 IETF 流程。

IETF 在 PEAPv2 上进行了一些额外的工作，通过加密绑定到内部身份验证方法，可以使系统更加安全。据我所知，这还远没有实现。

答案4

您必须考虑客户端本身支持哪些 EAP 方法、通过附加软件支持哪些 EAP 方法以及服务器支持哪些内部身份验证方法。

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

PEAP 和 MS-CHAPv2 受到客户端的良好支持，但如果您的服务器不支持 MS-CHAPv2（因为您不存储明文密码），则必须想出其他解决方案。这就是您会看到人们使用 EAP-TTLS 和 PAP 的主要原因。

相关内容