扩展阅读
1.EAP PSK(预共享密钥)
2.EAP结构
EAP 是一组以插件模块的形式为任何 EAP 类型提供结构支持的内部组件。为了成功进行身份验证,远程访问客户端和验证程序必须安装相同的 EAP 身份验证模块。ISA 服务器支持两种 EAP 类型:MD5-Challenge 和 EAP-TLS。
MD5-Challenge
Message Digest 5 Challenge (MD5-Challenge) 是一种必需的 EAP 类型,其使用与基于 PPP 的 CHAP 相同的质询/握手协议,但是质询和响应是作为 EAP 消息发送的。MD5-Challenge 的典型用法是通过使用用户名和密码安全系统对远程 VPN 客户端的凭据进行身份验证。您还可以使用 MD5-Challenge 来测试 EAP 的互操作性。
EAP-TLS
EAP-Transport Level Security (EAP-TLS) 是在基于证书的安全环境中使用的 EAP 类型。如果您将智能卡用于远程访问身份验证,则必须使用 EAP-TLS 身份验证方法。EAP-TLS 的消息交换可以提供远程 VPN 客户端和验证程序之间的相互身份验证、加密方法的协商和加密密钥的确定。EAP-TLS 提供了最强大的身份验证和密钥确定方法。
EAP-RADIUS
EAP-RADIUS 并不是一种 EAP 类型,但是可以通过验证程序将任何 EAP 类型的 EAP 消息传递到 RADIUS 服务器,以便进行身份验证。例如,将 ISA 服务器配置为用于 RADIUS 身份验证时,将封装在远程 VPN 客户端和 ISA 服务器之间发送的 EAP 消息,并在远程访问服务器和 RADIUS 服务器之间将格式设置为 RADIUS 消息。
EAP-RADIUS 用在将 RADIUS 作为身份验证提供程序的环境中。使用 EAP-RADIUS 的优势在于不需要在每个远程访问服务器上安装 EAP 类型,只需要在 RADIUS 服务器上安装即可。在 Internet 验证服务 (IAS) 中,只需要在 ISA 服务器上安装 EAP 类型。
EAP协议帧结构
802.1x协议在实现整个认证的过程中,其三个关键部分(客户端、认证系统、认证服务器)之间是通过不同的通信协议进行交互的,其中认证系统和认证服务器之间是EAP报文。
EAP帧结构如下表所示:
字段 | 字节 |
Code | 1 |
Identifier | 2 |
Length | 3-4 |
Data | 5-N |
EAP帧格式中各字段含义如下:
字段 | 占用字节数 | 描述 |
Code | 1个字节 | 表示EAP帧四种类型:1.Request;2.Response 3.Success;4.Failure |
Identifier | 1个字节 | 用于匹配Request和Response。Identifier的值和系统端口一起单独标识一个认证过程 |
Length | 2个字节 | 表示EAP帧的总长度 |
Data | 0或更多字节 | 表示EAP数据 |
其中Code的取值如下:
1:Request
2:Response
3:Success
4:Failure
参考:EAPoL协议
802.1x协议定义了一种报文封装格式,这种报文称为EAPoL(EAP over LANs局域网上的扩展认证协议)报文,主要用于在客户端和认证系统之间传送EAP协议报文,以允许EAP协议报文在LAN上传送。
标准EAPoL帧结构如下表所示:
字段 | 字节 |
PAE Ethernet Type | 1-2 |
Protocol Version | 3 |
Packet Type | 4 |
Packet Body Length | 5-6 |
Packet Body | 7-N |
EAPoL帧格式中各字段含义如下:
字段 | 占用字节 | 描述 |
PAE Ethernet Type | 2个字节 | 表示协议类型,802.1x分配的协议类型为888E |
Protocol Version | 1个字节 | 表示EAPOL 帧的发送方所支持的协议版本号。本规范使用值为0000 0001 |
Packet Type | 1个字节 | 表示传送的帧类型,如下几种帧类型: a) EAP-Packet.值为 0000 0000 b)EAPOL-Start.值为0000 0001 b) EAPOL-Logoff.值为0000 0010 |
Packet Body Length | 2个字节 | 表示Packet Body的长度 |
Packet Body | 0/多字节 | 如果Packet Type为EAP-Packet,取相应值。对于其他帧类型,该值为空。 |
EAPOL帧在二层传送时,必须要有目标MAC地址,当客户端和认证系统彼此之间不知道发送的目标时,其目标MAC地址使用由802.1x协议分配的组播地址01-80-c2-00-00-03。
---------------------------------------------------------------------------------------------------------------
3.EAP协议类型
转自:https://blog.csdn.net/banrieen/article/details/51437260
可扩展身份认证协议(Extensible Authentication Portocol,EAP)最早定义在RFC2284中,是一种支持多种认证方法的认证框架,而不是一个认证机制。EAP最初被设计用于PPP,后来被RFC 3748更新,用于基于端口的802.1X访问控制,最后又被RFC 5247所更新。
EAP是一种非常灵活的二层协议,包括多种类型。有些EAP类型是产商私有的,有些EAP类型是标准的,如LEAP是Cisco私有的,PEAP是公有的标准。有些EAP仅能提供单向认证,而有些EAP可提供双向认证(mutual authenticaiton)。在双向认证中,不仅认证服务器需要对请求方的身份进行认证,请求方也必须对认证服务器的身份进行认证,以防止自己提供的用户名和密码被非法或假冒的认证服务器窃取。大部分要求双向认证的EAP采用服务器证书对认证服务器的身份进行验证。下表列出了各种EAP的特点和具体特性:
表-1 EAP类型
1. “弱”EAP协议
传统的EAP类型极容易受到各种攻击,包括社会工程学和离线字典的攻击。这些传统的EAP类型是企业WLAN绝对不可能接受的解决方案,包括EAP-MD5和EAP-LEAP。
1.1 EAP-MD5
EAP-MD5是一种相当简单的EAP类型,很长一段时间在有线网络中用于端口认证,因此也成为第一个用于WLAN中的EAP类型。然而,由于EAP-MD5的存在几大缺点,因此在企业WALN环境中不建议EAP-MD5,这几大缺点是:
• 单向认证: 只有请求方被认证,服务器不需要被认证。相互认证需要创建动态加密密钥,如果选择EAP-MD5为身份验证方法,则加密方法只能是静态WEP,或根本没有加密;
• 用户名明文: 请求方的用户名总是明文可见,如果黑客知道用户的身份,黑客可以尝试使用社会工程学技术获取到密码。因此,EAP-MD5很容易受到社会工程学攻击;
• 弱MD5哈希:请求方的密码使用MD5哈希功能,但其很容易受到各种黑客工具所破解。因此,EAP-MD5极容易受到离线字典攻击;
下图描述了EAP-MD5的认证过程:
图-1 EAP-MD5的认证过程
1.2 EAP-LEAP
EAP-LEAP也被简称为LEAP(Lightweight Extensible Authentication
Protocol, 轻量级可扩展身份认证协议),是多年来被企业WLAN使用的一个非常成功的EAP类型。LEAP很容易部署,所有终端用户可使用相同的身份凭证:用户名和密码。
与EAP-MD5不同,LEAP使用动态生成的WEP密钥对数据传输进行加密,并执行一种类型的伪双向认证,尽管许多文档声称LEAP支持双向认证。MS-CHAP和MS-CHAPv2在双向认证的过程中使用相同的密码进行哈希以认证对方,但这不是真正的双向认证。LEAP有以下几大缺点:
• 用户名明文:请求方的用户名总是明文可见,如果黑客知道用户的身份,黑客可以尝试使用社会工程学技术获取到密码。因此,EAP-MD5很容易受到社会工程学攻击;
• 弱MS-CHAPv2哈希:请求方的密码使用MS-CHAPv2哈希功能,但其很容易受到各种黑客工具所破解。因此,EAP-MD5极容易受到离线字典攻击;
• 伪双向认证:LEAP使用MS-CHAPv2协议支持一种“类型”的双向认证;
尽管LEAP可以使用强大和复杂的密码抵御攻击,但强制终端用户使用强大的密码策略是一个挑战。为了企业WLAN的安全,不建议在企业WLAN中部署使用LEAP。
下图描述了EAP-LEAP的认证过程:
图-2 EAP-LEAP的认证过程
2. “强”EAP协议
“强”EAP类型使用基于TLS的身份认证或TLS隧道化身份认证,与EAP-MD5/EAP-LEAP只使用一个请求方身份不同,基于隧道身份验证的EAP类型使用两个请求方身份:外层身份(outer identity)和内层身份(inner identity)。外层身份只是一个有效的虚假用户名(通常为anonymous),而内层身份是请求方的真实身份。外层身份以明文出现在加密TLS隧道外,而内层身份被TLS隧道所保护。
注意:所有的请求方都有能力配置外层身份的虚假用户名,除了Microsoft WZC请求方。WZC请求认证时内层和外层身份都使用相同的用户名。因此,真正的用户名可见,这是为什么建议不是用Microsoft内置的WZC请求方。
2.1 EAP-PEAP
EAP-PEAP简称为PEAP(Protected Extensible Authentication
Protocol,受保护的可扩展身份验证协议),其创建一个加密的TLS隧道,并在该TLS隧道内验证请求方内层身份。由于PEAP的高安全性,因此,PEAP是企业WLAN中最常用也是使用最广泛的的EAP类型。
PEAP最开始由Csico、Microsoft、RSA
Security三家公司所联合提议,但是据报道Microsoft和Cisco没有完全同意提议的每一个细节。Microsoft实施PEAPv0使用MS-CHAPv2作为内部认证方法,MS-CHAPv2是Microsoft自由的CHAP版本,随着微软在客户端和服务器操作系统占有的统治地位,并内置支持MS-CHAPv2,因此这也导致了EA-PEAPv0(EAP-MSCHAPv2)的成功。而Cisco从原始的标准中分离出PEAPv1,其使用EAP-GTC作为内部认证方法。PEAP包括三个主要版本:
• EAP-PEAPv0(EAP-MSCHAPv2)
微软的EAP-PEAPv0 (EAP-MSCHAPv2)是最常用的一种PEAP类型,使用EAP-MSCHAPv2协议作为隧道内部的认证方法,其使用用户名和密码作为用户凭证。
• EAP-PEAPv0(EAP-TLS)
EAP-PEAPv0(EAP-TLS)是微软的另一种类型的PEAP,使用EAP-TLS协议作为隧道内部的认证方法,其使用客户端证书作为用户凭证。EAP-TLS也可以作为一个单独的EAP认证协议使用。
• EAP-PEAPv1(EAP-GTC)
EAP-PEAPv1(EAP-GTC)是Cisco版本的一种PEAP类型,使用EAP-GTC(EAP-GenericToken Card,通用令牌卡)协议作为隧道内部的认证方法。EAP-GTC定义在RFC3748中,然后被发展成与现有的安全令牌系统提供互操作性,如RSA的SecurID解决方案的OTP。EAP-GTC方法建议使用安全令牌设备,但是其身份凭证也可以为明文的用户名和密码。因此,当EAP-GTC被用于PEAPv1的隧道中,通常其身份凭证是一个简单的明文用户名和密码。
由于在TLS隧道中使用的PEAP内部认证协议是另一种类型的EAP,所以PEAP通常也被称为”EAP inside EAP“认证,唯一的区别就是使用在TLS隧道中的内部EAP协议不同。
PEAP操作的关键点是建立TLS隧道,这需要一个服务器端证书(server-side certificate)。EAP-PEAP认证过程包括两个阶段,下面以EAP-PEAPv0 (EAP-MSCHAPv2) 来说明,下图描述了EAP-PEAP的认证过程:
图-3 EAP-PEAP的认证过程
注意:加密TLS隧道只会存在几毫秒,用于保护用户身份凭证,而不是用于加密802.11数据帧。
2.2 EAP-TTLS
EAP-TTLS(EAP-Tunneled Transport Layer Security,隧道传输层安全)由Certicom和FunkSoftware设计,定义在RFC 5281中。与PEAP一样,EAP-TTLS也使用TLS隧道保护相对不安全的内层认证方法。如下图所示,EAP-TTLS与PEAP相似,认证过程也包含两个阶段。
图-4 EAP-TTLS的认证过程
EAP-TTLS与EAP-PEAP的区别相当小,最大的不同就是EAP-TTLS支持更多的内层认证协议。EAP-TTLS支持传统的认证方法PAP、 CHAP、MS-CHAP和MS-CHAPv2,也支持使用EAP协议作为内层认证方法,支持使用客户端证书作为身份凭证,而EAP-PEAP只支持EAP协议作为内层认证方法。
EAP-TTLS曾被广泛部署过,在许多企业WLAN中也能遇到。然而,EAP-TTLS与EAP-PEAP几乎相同,且不被Microsoft WZC所支持。因此,相对其他的EAP协议类型来说市场较小。如果不使用Microsoft WZC作为请求方,EAP-TTLS是可考虑的一种选择。
2.3 EAP-TLS
EAP-TLS(EAP-Transport Layer Security,传输层安全)定义在RFC 5216中,是使用最广泛,也是WLAN中最安全的一种EAP类型。EAP-TLS除了与EAP-PEAP和EAP-TTLS一样需要服务器端证书外,还需要客户端证书。
部署服务器端证书并不需要太大的负担,然而为每一个客户端部署唯一的数字证书需要企业PKI基础设施,这对企业来说是一个负担。因此,除非企业已经存在PKI基础设施,否议在企业WLAN中部署EAP-TLS不是第一建议。下图描述了EAP-TLS的认证过程:
图-5 EAP-TLS的认证过程
使用客户端数字证书作为身份凭证是EAP-TTLS和EAP-PEAP的可选项,然而在TLS隧道中使用客户端证书是不必要的。因此,只建议在部署EAP-TLS时使用客户端数字证书。认证服务器配置EAP-TLS时,通常允许通过比较用户数字证书中包含的一个或多个信息来验证客户端证书,这些信息包括:
• 证书持有者别名(Certificate Subject Alternative Name ,SAN)
• 证书持有者通用名称(Certificate Subject Common Name ,CN)
• 证书二进制(Certificate Binary)
2.4 EAP-FAST
EAP-FAST(EAP-Flexible Authentication via Secure Tunneling,基本安全隧道的灵活认证)由Cisco所开发设计,用于取代易破解的LEAP。EAP-FAST目前已经被标准化定义在RFC 4851中,并在2009年,与EAP-AKA一起加入到Wi-Fi联盟的WPA2互操作认证中。
EAP-FAST与EAP-PEAP和EAP-TTLS一样,提供双向认证和隧道化认证。但是EAP-FAST并不使用基于X.509标准的数字证书去建立TLS隧道,而是使用PAC(Protected Authentication Credential,受保护的接入凭证)。
PAC是一种类数字证书,实际上是一个共享密钥,主要包含以下三部分:
• Shared Secret—The PAC-Key:客户端与认证服务器之间的一个预共享密钥,是一个强32字节的密钥,由认证服务器随机产生,是建立TLS隧道的先期主密钥;
• Opaque Element—The PAC-Opaque:在隧道建立时发送给认证服务的一个可变长度的数据元素,这样认证服务器就可以解码所需的信息来验证客户端的身份;
• Other Information—PAC-Info:是一个可变长度的数据元素,,能够以最简洁方式的提供认证服务器或PAC发布者的身份(A-ID)。为了避免混绕,各个认证服务器的A-ID是不同的。PAC-Info还可能包括其他的有用但非强制的信息,例如,PAC-Key生存时间,也可能在PAC分发或更新时被服务器传递到申请者。
以上三个部分统一构成了一个完整的PAC证书,在EAP-FAST认证之前由认证服务器一次性产生并通过安全的方式送给申请者,完成PAC的发放。
EAP-FAST的认证过程包含3个阶段:其中阶段1是一个可选的阶段,如下图所示:
图-6 EAP-FAST认证过程
• EAP-FAST 阶段0 —— 此阶段用于自动分发部署PAC,是一个可选的阶段,所有的PAC可以通过手动方式安装在每个客户端上。
• EAP-FAST 阶段1 —— 客户端请求方发送外层伪装的身份ID给认证服务器,让认证服务器知道有客户端尝试认证。客户端和认证服务器之间使用对称密钥加密进行协商,建立起一个加密的TLS隧道;
• EAP-FAST阶段2 —— 在加密隧道内进行客户端请求方的身份验证。EAP-FAST支持多种内层认证方法,但通常使用的内层认证协议为EAP-GTC,使用用户名和密码进行验证。
阶段0执行的自动分发部署PAC文件是使用一个匿名的Diffie-Hellman交换,客户端仅是简单的信任提供PAC文件的。因此,EAP-FAST如果是使用自动分发部署PAC文件,很容易遭受到中间人攻击。如果不经过阶段0,则手动安装PAC文件到每个客户端上则是一件很繁重的任务,还不如使用已经被广泛部署过的EAP-TLS和EAP-PEAP。
3. 其他EAP协议
除了以上介绍的EAP协议外,还有多种其他EAP协议的存在。如EAP-POTP协议,用于移动电话产业的EAP-SIM和EAP-AKA等,这里不做详细介绍。
参考文献:
[1] Certified Wireless Security Professional Official Study Guide

