今天做了U9510的企业级加密标杆测试，写了企业级加密标杆设备的操作指南。最后做到server 2003却出了问题，peap能关联，但是TLS怎么都关联不上。用adb shell查看logcat日志，也没看出个所以然。哎，本来顺顺利利的一天却以这样的方式结尾了。无奈。
搜集一些今天遇到问题的资料：
1，EAP Method常见的有PEAP0，PEAP1，TLS，TTLS，AKA，SIM，企业级服务器也有四种，hostapd，devicecap，radiator，windows server。四种服务器在EAP Method选择上有没有什么优先级？既然有这种多种EAP Method，那么这么多服务器类型还有什么用？
从*上获取了一点资料，做一下总结吧。
四种服务器：
Hostapd：
Devicecap：
Radiator：
Windows server：
几种EAP Method：
1. EAP-TLS：
EAP-TLS使用TLS握手协议作为认证方式，TLS有很多优点，所以EAP选用了TLS作为基本的安全认证协议，并为TTLS和PEAP建立安全隧道，TLS已经标准化，并且进过了长期应用和分析，都没有发现明显的缺点。
TLS认证是基于Client和Server双方互相验证数字证书的，是双向验证方法，首先Server提供自己的证书给Client，Client验证Server证书通过后提交自己的数字证书给Server，客户端的证书可以放到本地、放到key中等等.
TLS有一个缺点就是TLS传送用户名的时候是明文的，也就是说抓包能看到EAP-Identity的明文用户名。
TLS是基于PKI证书体系的，这是TLS的安全基础，也是TLS的缺点，PKI太庞大，太复杂了，如果企业中没有部署PKI系统，那么为了这个认证方法而部署PKI有些复杂，当然，如果企业已经部署了PKI，那么使用EAP-TLS还是不错的选择。
2. EAP-TTLS：
3. EAP-PEAP:
正因为TLS需要PKI的缺点，所以设计出现了TTLS和PEAP，这两个协议不用建立PKI系统，而在TLS隧道内部直接使用原有老的认证方法，这保证了安全性，也减小了复杂度。
把TTLS和PEAP放到一起介绍的原因是他们俩很像，两个都是典型的两段式认证，在第一阶段建立TLS安全隧道，通过Server发送证书给 Client实现Client对Server的认证（这里TTLS和PEAP仍然使用证书，但是这里的证书都是服务器证书，管理起来比TLS客户端证书要 简单那的多）；当安全隧道一旦建立，第二阶段就是协商认证方法，对Client进行认证；
TTLS利用TLS安全隧道交换类似RADIUS的AVPs（Attribute-Value-Pairs），实际上这些AVPs的封装和RADIUS都 十分相似，TTLS这种AVPs有很好的扩展性，所以它几乎支持任何认证方法，这包括了所有EAP的认证方法，以及一些老的认证方法，比如PAP、 CHAP、MS-CHAP、MS-CHAPv2等，TTLS的扩展性很好，通过新属性定义新的认证方法。
PEAP之所以叫Protected EAP，就是它在建立好的TLS隧道之上支持EAP协商，并且只能使用EAP认证方法，这里为什么要保护EAP，是因为EAP本身没有安全机制，比如 EAP-Identity明文显示，EAP-Success、EAP-Failed容易仿冒等，所以EAP需要进行保护，EAP协商就在安全隧道内部来 做，保证所有通信的数据安全性。其实PEAP最大的优点就是微软支持开发，微软在Windows系统内集成了客户端，微软和Cisco都支持PEAP，但 是他们的实现有所区别。