Cisco EAP-FAST验证入门

对于系统管理员和企业CIO来说，企业无线局域网的安全问题一直是他们关注的重心。今天我们将向大家介绍Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)，即通过安全隧道灵活验证的EAP方式 。

在ASLEAP的威胁下，Cisco不得不开发了新的通过安全隧道灵活验证的EAP方式，即EAP-FAST协议，并将其提交给了IETF。根据 Cisco的市场销售宣传，EAP-FAST是一个“像PEAP一样安全，像LEAP一样方便”的协议。EAP-FAST可以像PEAP那样建立一个安全的加密通道，保护验证线程中的用户证书传递，而不需要客户端甚至服务器端具备PKI。我见到这种宣传语的第一个自然反映就是怀疑。当然，其它一些方法，比如安全密钥加密，也可以实现不需要PKI的安全密钥交换，但是还没有一种方法可以简单的实现大范围的部署。难道EAP-FAST真的可以实现这一突破么？

EAP-FAST阶段
 
EAP-FAST在普通操作模式下和PEAP类似，有两个主要阶段。第一阶段是建立一个安全的加密隧道，第二阶段是通过 MS-CHAPv2线程在验证服务器上对客户端身份进行验证。由于 MS-CHAPv2是一个相当脆弱的协议，通过字典攻击很容易被破解，因此第一阶段建立的安全加密隧道为MS-CHAPv2线程提供了一个安全的环境。与PEAP不同的是，EAP-FAST采用PAC（受保护的接入证书）来建立隧道，而PEAP则是采用服务器端的数字证书建立TLS隧道（与安全的Web服务器工作方式类似）。验证服务器的EAP-FAST Master Key会为每个用户提供一个特殊的PAC文件。而配发这个PAC的过程可以被认作是“阶段0”（也就是自动提供），或者通过其他一些方式，比如通过移动存储设备传输，通过管理员建立的共享文件夹，或者有用户限制的共享文件夹。

市场vs现实

如果仔细阅读Cisco提供给IETF的EAP-FAST协议草案，不难发现，EAP-FAST与Cisco的市场宣传还是有比较大的出入的。虽然从技术上说，EAP-FAST“可以”和PEAP一样安全，也“可以”和LEAP一样简单，但是Cisco的市场宣传并没有指出，用户不可能鱼与熊掌兼得。

事实上，为了让EAP-FAST达到与PEAP相同的安全级别，它必须采用在“阶段0”采用“服务器端验证的Diffie-Hellman模式”，即需要服务器端的数字证书。如果看过本系列的前几篇文章，你就会知道，对于服务器端数字证书的需求是很多用户放弃PEAP的主要原因。虽然Cisco表示采用PAC方式并不需要服务器端的数字证书，但是近乎手动实现的PAC文件配发，其中的不确定因素更多。另一方面，虽然EAP-FAST PAC参考机制可以通过安全的方式自动提供密钥 ，但它仅限于维护PAC，并不能解决首次的PAC文件发布问题。

为了要实现如LEAP般的简单，EAP-FAST必须在“阶段0”采用匿名的Diffie-Hellman模式。而匿名的Diffie-Hellman密钥交换意味着用户并不知道交换的另一端到底是谁。在这种情况下，黑客可以假装成阶段0的接入点和验证服务器，然后等待对此毫不怀疑的用户进行阶段0的连接，接收用户以明文发送的用户名和经过哈希计算的密码。由于服务器是伪造的，因此服务器必定无法响应，此时阶段令0会被用户放弃。不过这时候黑客已经获取了足够多的MS-CHAPv2线程的信息了，他只需要使用ASLEAP进行离线的字典攻击即可。由于大多数用户的密码不够强壮，因此很快黑客就可以获取到用户的证书并成功进入企业无线局域网。

根据EAP-FAST IETF草案的说明，一旦出现这种情况，用户应该立即更换密码。但是EAP-FAST客户端对此并没有明确的提示，也没有自动警告用户和管理员，或是强制进行密码修改。虽然这种比较便利的EAP-FAST方式在自动配发PAC是会出现漏洞，但是起码有两个因素使得他比LEAP要更安全一些。

◆首先，PAC文件的发布只会执行一次，用来建立服务器和客户端的PAC。之后建立的EAP-FAST线程都会绕过“阶段0”。而LEAP则是每次都要面临风险。每次用户在与radius服务器进行无线局域网接入验证时，都会出现类似的风险。

◆其次，就在在阶段0的匿名Diffie-Hellman模式下，黑客如果要攻击必须采用主动方式，这就会暴露黑客的行为。而LEAP的攻击要相对隐蔽。

虽然与LEAP相比进步很大，但是EAP-FAST的安全性仍然不如EAP-TLS, EAP-TTLS,或PEAP。不过EAP-FAST的验证线程速度较快，因为它采用的是对称加密，而不是EAP-TLS, EAP-TTLS,或PEAP所采用的非对称加密，但是这这种速度优势并没有什么实际意义。我曾经使用一款266 MHz PDA进行PEAP验证测试，这是能采用EAP验证协议的最低端配置，但是我并没有感觉PEAP验证速度有任何延迟。我觉得，如果用户使用笔记本进行PEAP验证，与EAP-FAST验证相比，速度可能仅仅会延迟几个毫秒。我所关心的另一个问题是部署的速度，在这方面EAP-FAST依然处于劣势。

EAP-FAST部署问题

根据宣传，EAP-FAST是“像LEAP一样简单”的，但是事实上并非如此。根据Cisco自己的EAP-FAST开发指南 ，用户不应该完全依赖PAC文件自动配发，因为这会给黑客的主动型攻击提供机会。

注意：由于阶段0的PAC配发是通过MS-CHAPv2验证进行防护的，而MS-CHAPv2很容易遭受字典攻击，因此我们建议您在首次部署EAP-FAST时尽量少用自动发布功能。在大范围部署EAP-FAST后，应该采用手动配发PAC方式，以确保PAC的最佳安全性。

根据这些信息，我们可以发现，EAP-FAST的部署并非一帆风顺。用户最终还是会回到手动配发PAC文件的地步，以确保整个系统的安全性。而合法用户也必须要承担维护网络安全的责任，因为谁都不愿意看到多个用户使用一个相同的PAC登录。

读过了Cisco文档中的手动PAC配发章节，对于安全的部署EAP-FAST的工作量，我们就更吃惊了。根据我多年来部署EAP-TLS和PEAP的经验，我可以肯定的告诉大家，安全的部署EAP-FAST，通过手动方式实现PAC配发，绝对是部署安全验证项目中的一件最重的体力活。而在部署PEAP的过程中，如果已经从CA机构获取了数字证书，那么整个过程会相当简单。

如果企业不乐意每年花300美元从CA机构获取数字证书，还可以自己建立一个CA或者通过活动目录生成一个自签名的数字证书。如果企业采用的是Windows NT域，或者是非Windows用户，并不支持自动部署根证书，那么PEAP服务器的“.cer”公共证书文件也可以通过企业内部网页发送到每个客户端，再由客户端手动添加到CTL（证书信任列表）中。对于最后一种方法，我们也完全没有必要担心“.cer”文件会被黑客利用，因为这个文件中仅包含了1024bit的公钥内容，根据这些内容，几乎没有可能成功破解。

对于大范围部署EAP-FAST和配发PAC，你必须建立和管理成百上千个独立的用户私钥。不要指望可以通过企业内部网络和活动目录实现这些用户私钥的自动配发，因为每个PAC都是不同的，必须手动输入到每个用户的笔记本中的Cisco ACU（Aironet Client Utility）中才可以生效。我想你也会理解为什么我一看到Cisco的EAP-FAST宣传语“像LEAP一样简单”就会发笑，因为EAP-FAST的部署甚至比在一个受控环境中部署EAP-TLS还要麻烦。

Cisco EAP-FAST的更多局限

由于EAP-FAST不支持较老的Cisco Wi-Fi设备，因此用户需要使用近年来推出的Cisco Wi-Fi产品。Cisco EAP-FAST还需要用户使用基于Cisco ACS (Access Control Server)的昂贵的验证平台，这种平台的灵活性和易用性都不如微软的RADIUS server IAS (Internet Authentication Service)。以上观点都是来自那些管理过这两种平台的IT人员。另外，Cisco的客户端还不支持“机器登录”，这种方式可以在用户还没有登录Windows时就对该系统进行身份验证。对于企业来说，有这种功能是相当重要的，因为它可以使登录脚本以及组策略更好的工作。Cisco的网站上也建议用户，如果需要使用机器登录功能，可以选择使用Microsoft Wireless Client。

有关EAP-FAST的总结

那么，在没有PKI的环境下，Cisco的EAP-FAST验证协议真的如其所说是一种优秀的密钥交换协议吗？我想大家的答案肯定都是否定的。读过了这篇文章或者Cisco的EAP-FAST开发手册，也许大家都会有这样一个疑问：为了在验证服务器上避免使用数字证书，为了不在企业内部安装PKI Certificate Authority或者不希望每年花300美元获取CA机构的数字证书，而采用Cisco EAP-FAST，是否真的值得呢？如果你指望通过Cisco EAP-FAST来降低工作的难度，那你就大错特错了，因为如果你要实现PEAP那样的安全性，就绝不会像Cisco宣传的那样“像LEAP一样简单”。 在我看来，最佳的解决方案就是使用PEAP验证。