精华内容
下载资源
问答
  • EAP

    千次阅读 2011-03-22 10:50:00
    扩展认证协议(Extensible Authentication Protocol, EAP),是一个普遍使用的认证机制,它常被用于无线网络或点到点的连接中。EAP不仅可以用于无线局域网,而且可以用于有线局域网,但它在无线局域网中使用的...

    扩展认证协议Extensible Authentication Protocol, EAP),是一个普遍使用的认证机制,它常被用于无线网络点到点的连接中。EAP不仅可以用于无线局域网,而且可以用于有线局域网,但它在无线局域网中使用的更频繁。最近,WPA和WPA2标准已经正式采纳了5类EAP作为正式的认证机制。 EAP是一个认证框架,不是一个特殊的认证机制。EAP提供一些公共的功能,并且允许协商所希望的认证机制。这些机制被叫做EAP方法,现在大约有40种不同的方法。IETF的RFC中定义的方法包括:EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-SIM,和EAP-AKA, 还包括一些厂商提供的方法和新的建议。无线网络中常用的方法包括EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP,和EAP-TTLS. 当EAP被基于802.1x的网络接入设备(诸如802.11a/b/g ,无线接入点)调用时,现代的EAP方法可以提供一个安全认证机制,并且在用户和网络接入服务器之间协商一个安全的PMK。该PMK可以用于使用TKIPAES加密的无线会话。

    目录

    [隐藏]

    [编辑] 轻量级的扩展认证协议(LEAP)

    轻量级的扩展认证协议,或LEAP是一个由CISCO私人拥有的EAP。Cisco通过允许其他厂家生产基于EAP的项目来保护该协议。在任何的windows操作系统中不支持LEAP,但LEAP被第三方的用户软件支持。该协议由于其容易受到字典攻击脆弱性,就象EAP-MD5,而在一开始便广为人知。但直到2003年Joshua Wright发表了ASLEAP以后,人们才开始讨论LEAP存在严重的安全问题。Cisco仍然认为如果使用十分复杂的密码,LEAP是安全的。但是在现实世界中人们几乎不使用十分复杂的密码,因为这对普通人来将是一件非常困难的事情。新的协议,诸如EAP-TTLS和PEAP,则没有这些问题,因为他们给MSCHAPv2用户认证会话建立了一个安全的传输层安全(TLS)通道,而且可以运行在使用Cisco和不使用Cisco的接入点上。

    [编辑] EAP-TLS

    EAP-TLS是IETF的一个开放标准,并且在无线厂商之间得到很好的支持。它能够提供很好的安全保证。因为TLS被认为是SSL的继承者。它使用PKI来保护Radius认证服务器的通信,这是很难完成的任务。所以即使EAP-TLS良好的安全,用户端在认证时的负载成为它的致命伤。 EAP-TLS是无线局域网扩展认证协议的原始版本,虽然它因为配置困难而很少被使用,但它仍被认为是最安全的EAP标准之一,而且广泛地被无线局域网硬件和软件制造厂商,包括微软所支持。要求用户方给出证书,虽然不是很流行,则是EAP-TLS在认证方面的长处,而且既方便又安全。一个脆弱的密码不会导致入侵基于EAP-TLS的系统,因为攻击者仍然需要客户端的证书。当客户端的证书是储存在智能卡中时,EAP-TLS提供了最安全的认证解决方案,因为如果不窃取智能卡是无法得到客户端证书的。如果将智能卡偷窃的话则会立刻引起注意并且更换新卡。到2005年四月,EAP-TLS是唯一厂商需要保证的WPA和WPA2的EAP类型。在微软,Cisco,Apple和Linux中都有实现客户端和服务器端的源代码。EAP-TLS在MAC OS 10.3(包括10.3以上), Windows 2000 SP4, Windows XP, Windows Mobile 2003(包括2003以上),和Windows CE 4.2中被支持。

    [编辑] EAP-MD5

    EAP-MD5是另一个IETF开放标准,但提供最少的安全。MD5Hash函数容易受到字典攻击,它被使用在不支持动态WEP的EAP中。

    [编辑] EAP-FAST

    EAP-FAST (基于安全隧道的灵活认证,Flexible Authentication via Secure Tunneling) 是一个由思科提出的协议方案,用于替代

    LEAP。设计该协议是为了解决LEAP实现“轻量级”时的缺点。在EAP-FAST中使用服务器证书是可选的。EAP-FAST使用一个保护访问凭证

    (Protected Access Credential,PAC)来建立TLS隧道,并通过该隧道对客户端证书进行验证。EAP-FAST拥有三个阶段。 阶段0是一个可选的阶段,

    在该阶段PAC可以是手工或者动态设置,但超出了RFC4851中定义的EAP-FAST的范围。尽管PAC设置存在着许多实现,但是官方的实现依然在进行状态

    。PAC典型地只需要为RADIUS服务器和客户单设置一次。 在阶段1中,客户端和AAA服务器使用PAC来建立TLS隧道。 在阶段2中,客户端证书在该加

    密的隧道中进行传输。

    当自动PAC设置开启之后,EAP-FAST拥有一个小漏洞。攻击者可以拦截该PAC并随后使用它来获得用户证书。 该漏洞可以通过手动配置PAC或者在PAC

    配置阶段使用服务器证书来解决。

    还有一个漏洞:黑客的AP可以使用同一个SSID,拒绝用户PAC并提供新的PAC。大多数恳求将会被设置来使得用户接收它。如果用户不这样做,那么

    用户将使用内部方法发送他的证书给黑客。而黑客将会获得明文的密码(EAP-FAST w/GTC)或者易受字典攻击的MSCHARPv2散列。

    值得一提的是,PAC文件的发放时基于每个用户的。这是RFC 4851 第7.4.4节中的要求,因此如果一个新的用户从设备进入网络,他首先需要一个新

    的已配置的PAC文件。这是为什么很难不以非安全匿名设置模式运行EAP-FAST的原因。另一种方式是使用设备密码来替代,但这就不是在网络中对用

    户进行认证了。

    EAP-FAST可以不使用PAC文件,则为普通的TLS。

    [编辑] EAP-TTLS

    EAP-TTLS是由Funk Software和Certicom合作开发的。它目前是IETF的开放标准草案。它可跨平台支持,提供非常优秀的安全,并且在认证服务器上使用PKI证书。

    [编辑] PEAP

    PEAP由CISCO微软RSA Security联合提出的开放标准的建议。它早已被运用在产品中,而且提供很好的安全。它在设计上和EAP-TTLS相似,只需要一份服务器端的PKI证书来建立一个安全的传输层安全通道(TLS)以保护用户认证。 到2005年5月,已有两个PEAP的子类型被WPA和WPA2标准批准。它们是:

    • PEAPv0/EAP-MSCHAPv2
    • PEAPv1/EAP-GTC

    TTLS与TLS最大的区别是TTLS不需要客户端认证的协议。

    [编辑] EAP-AKA

    EAP-AKA(EAP for UMTS Authentication and Key Agreement) 是用来在使用 USIM 接入 UMTS 移动通信网络时进行用户认证和密钥协商的方案。EAP-AKA 定义于 RFC 4187 中。

    展开全文
  • EAP 6.2.1

    2020-12-09 01:14:39
    <div><p>Seems like EAP 6.2.1 is available. Here you might want to copy the repositories section from EAP 6.2 parent pom.xml before compiling.</p><p>该提问来源于开源项目:hasalex/eap-build</p></...
  • 本文主要对Radius协议、EAPEAP-MSCHAPv2、EAP-TLS、EAP-TTLS和EAP-PEAP,从协议流程、数据格式等方面进行简单介绍。

    1. Radius协议

    Radius协议是目前AAA服务中所使用的最广泛的协议,它对认证,授权以及计费的功能都提供支持。Radius服务器通过建立一个唯一的用户数据库,存储用户名,用户密码等一系列信息,接入用户通过发送自己的用户名,密码,证书等信息给服务器来进行认证,认证成功后,服务器会给用户下发配置信息来完成授权,并且根据配置好的计费规则对用户进行计费。只有通过认证的用户,才能访问Radius服务器上的资源。

    1.1 RADIUS协议实体

    • 无线终端 (Authenticating peer)
    • NAS (RADIUS Client)
    • RADIUS Server & Authenticator Server

    1.2 RADIUS典型流程

    RADIUS协议在进行处理的时候,认证过程和授权过程是在一起进行的,具体的操作是将授权信息放入到响应报文中。认证方法大致可以支持两种:

    • 基于数字证书的认证方法,基于数字证书的认证方法一般是利用TLS协议建立安全通道,然后在通道中交换数据,嵌套别的认证方法。
    • 基于密码的认证方法,基于密码的认证方法的例子有PAP认证和CHAP认证等。
      Radius协议基本流程

    1.3 RADIUS报文格式

    Radius协议报文格式

    • 代码(报文号)Code域占位一个字节,它用来标识Radius报文类型,下文列出了常见的代码编码与对应意义:
    			1  接入请求报文
    			2  接入成功回应报文
    			3  接入拒绝回应报文
    			4  计费请求报文
    			5  计费回应报文
    			11  接入挑战报文
    			12  服务器状态报文
    			13  客户端状态报文
    			255  保留
    
    • 标识符Identifier域占位一个字节,用于匹配请求和回应报文。比如说,可以根据该值判断是否是重复请求报文,在某一个时间区间以内,如果两个报文来自于相同的地址和端口,而且具有相同的Idenfier值,则可以认定为是重复的报文。
    • 长度Length,长度域占位两个字节。它包含了报文中的Code域,Identifier域,Length域,Authenticator域和属性域的总长度。如果接收到的报文的长度大于这个值,则在接收报文时忽略多出来的字节;如果长度小于这个值,则说明报文不完整,直接丢弃报文。一个Radius报文的长度在20到4095个字节的范围内。
    • 认证字,Authenticator域占位16个字节。高位字节先传输。该域的值用来鉴别服务器的回应报文。
    1. 请求认证字:Authentictor的值是一个随机生成的16字节字符串。NAS和Radius服务器共享一个密钥,该共享密钥被加在请求认证字域后面,然后对之使用MD5算法生成一个16字节的摘要,将该摘要和用户输入的密钥进行异或,然后将异或结果放入接入请求报文的User-Password属性。
    2. 回应认证字:在访问接受、访问拒绝和访问挑战报文中。它的值定义为整个访问回应报文的内容和共享密钥进行MD5摘要计算得出的16字节字符串:从代码域开始,包含标识符域,长度域,接入请求报文中的请求认证字域和回应报文中的属性,然后后面加上共享密钥,即
    ResponseAuth=MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
    
    1. Accounting-Request认证字,其定义是整个Accounting-Request报文的内容和共享密钥进行MD5摘要计算得出的16字节字符串,其中在计算时Authentictor的16字节数据用16字节的0进行替换。计算公式为:
     MD5(Code+ID+Length+16 Zero Octets+Attributes+Secret)
    
    1. 计费回应报文中的认证字称为计费回应认证字。它的定义为整个计费回应报文的内容和共享密钥进行MD5摘要计算得出的16字节字符串,其中在进行计算时Authentictor的16字节数据用计费请求Accounting-Request报文的Authentictor进行替换。计算公式:
    MD5(Code+ID+Length+Accounting-Request Authenticator+Attributes+Secret)
    

    2. EAP介绍

    EAP(可扩展身份认证协议)协议基于PPP(Point to Point Protocol,点对点协议)协议机制,是支持多种认证机制的PPP协议扩展。EAP支持客户端向实际用户多次请求认证信息,由服务器端执行具体的认证方法。这样,客户端通过EAP协议,在服务器端和接入用户之间传递认证报文。EAP协议为身份认证提供了一个框架,在该框架上,可以支持各种EAP认证方法。EAP认证相比于PAP认证和CHAP认证,对网络的接入管理更加严格,可以更好的保证网络应用中信息的安全。

    2.1 EAP报文格式

    EAP报文格式

    • 代码(报文号)Code域占位一个字节,它用来标识EAP报文类型,具体对应如下所示。
    		1  EAP-Request,EAP请求
    		2  EAP-Response,EAP回应
    		3  EAP-Success,EAP成功
    		4  EAP-Failure,EAP失败
    
    • 标识符Identifier占位一个字节,用于对请求和回应消息进行标识。
    • 长度Length,长度域占位两个字节。用于表示Code+Identifier+Length+Type+Data的总长度。
    • 类型Type,占据一个字节,用来表示具体的EAP报文认证类型,具体类型如下所示:
    			1    EAP_Identity
    			4    EAP_MD5
    			11   EAP_Challenge
    			13   EAP_TLS
    			21   EAP_TTLS
    			25   EAP_PEAP
    			26   EAP_MSCHAPv2
    
    • 数据Data,当Code为EAP-Success或者Code为EAP-Failure的时候,Data内容为空。其它类型报文的Data内容与Type类型相关。

    2.2 EAP_MSCHAPv2

    EAP_MSCHAPv2是一种双向相互认证的协议,认证过程是challenge-response式的。在认证过程中,服务器和客户端会进行双向验证,只要其中一方失败,则这个连接会被拒绝。EAP_MSCHAPv2通常不单独使用,通常是嵌套在EAP_PEAP认证方法中使用。

    EAP_MSCHAPv2的认证过程

    2.2.1 EAP_MSCHAPv2的认证过程

    1. 首先客户端给接入用户发送Identity报文,要求客户端提供身份标识;
    2. 接入用户给客户端回应Identity报文,内容是用户的身份标识,客户端对这个报文的处理是将之封装成Radius访问请求报文传给服务器;
    3. 服务器在获取到接入用户的接入标识后,会给客户端发送Radius访问挑战报文,客户端在收到这个报文后,对报文进行解封装,将报文中的EAP-Request/EAP-MSCHAPv2(Challenge)发送给接入用户,Challenge报文中包含有服务器端产生的Server-Challenge;
    4. 接入用户进行计算,发送Response报文给客户端,客户端在接收到该报文后,将该报文封装到Access-Request中传给服务器,Response报文中包含用户产生的Peer-Challenge和根据用户密码,用户名,Peer-Challenge和Server-Challenge为输入通过MD4和DES算法生成的NT-Response;
    5. 服务器对接入用户进行验证,具体验证的方法是服务器端使用同样的算法以用户密码,用户名,Peer-Challenge和Server-Challenge为输入计算出NT-Response,如果和Response报文中NT-Response匹配,则认证成功。在认证成功的基础下,会给客户端发Success-Request报文,Success-Request报文中含有以用户密码,用户名,Peer-Challenge,Server-Challenge以及NT-Response为输入使用MD4算法和DES算法计算出来的Message,客户端收到报文后,进行解封装,将报文中的Success-Request发送给接入用户,请求用户对服务器进行验证;
    6. 接入用户对服务器进行验证,具体验证的方法是用同样算法以用户密码,用户名,Peer-Challenge,Server-Challenge以及NT-Response为输入计算出Message,然后与Success-Request中的Message做匹配,如果匹配失败,则不再向服务器发送报文,如果匹配成功,则向客户端发送EAP-Request/EAP-MSCHAPv2(Success-Response)报文,客户端收到后,将报文封装成Access-Request报文传给服务器;
    7. 服务器如果接收到Success-Response报文,则说明验证成功,接入用户收到的报文将是EAP成功报文,到此整个认证流程结束。

    在第5步中,服务器对接入用户验证失败时,服务器可以发送
    EAP MSCHAPv2(Failure-Request,R=1,E=691)来要求用户重新输入密码进行重试,然后又重新从第4步开始进行认证过程。

    2.2.2 EAP-Message和Message-Authenticator

    在RFC2869中,Radius为支持EAP认证增加了两个属性EAP-Message和Message-Authenticator(消息认证码)。

    • EAP-Message属性中存放的是整个EAP认证包内容,下图展示了EAP-Message属性的封装,这个属性用来封装EAP数据包,类型代码为79,String域最长253字节,如果EAP数据包长度大于253字节,可以对其进行分片,依次封装在多个EAP-Message属性中。
      EAP属性封装
    • Message-Authenticator属性封装,类型代码为80。这个属性用于在使用EAP认证方法的过程中,避免接入请求包被窃听。在含有EAP-Message属性的数据包中,必须同时也包含Message-Authenticator,否则该数据包会被认为无效而被丢弃,而且服务器或用户收到报文后,还将使用EAP消息和共享密钥作为输入计算该值,如果与传过来的属性值不一致,也将丢弃这个报文。

    对于Access-Request消息,需要使用共享密钥,Message-Authenticator计算方法为:

    Message-Authenticator=MD5(Code+Type+Identifier+Length+16 Zero Octets+Attributes+Secret) 
    

    对于Access-Challenge、Access-Accept、Access-Reject消息,Message-Authenticator计算方法为:

    Message-Authenticator=MD5(Code+Type+Identifier+Length+Request Authenticator+Attributes+Secret) 
    

    2.3 EAP_TLS

    EAP_TLS是基于PKI证书体系的,要求客户端和服务器都必须拥有有效的证书,支持导出密钥的功能,而且是一种支持双向认证的认证方法。PKI证书体系是非常复杂的,在企业中已经部署PKI证书体系的情况下,EAP_TLS认证是一种很安全且很方便的认证方法,但是在企业没有部署的情况下,使用EAP_TLS进行认证将会很复杂。一般来说,EAP_TLS用于验证设备,而不是普通的接入用户。

    TLS协议由TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)两个协议组成。TLS握手协议使用了公共密钥和证书,在客户端和服务器之间进行通信之前协商算法和加密实际数据传输的密钥,该过程在TLS记录协议之上进行,TLS握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程,这个过程实际上产生三个随机数:client random, server random,pre-master secret。前两个随机数都是明文传送的,只有pre-master secret是加密的(RSA或DHP)。一般生成证书的时候,签名算法可以使用RSA或者DSA。如果server使用RSA证书,RSA既可以用作签名也可以用作不对称加密,pre-master secret就是用server的RSA证书中包含的公钥加密的。如果server使用DSA证书,DSA只能完成签名的功能,所以交换密钥的功能还得由DH算法实现。TLS记录协议的作用是对数据进行处理,包括加密,压缩和重组等,而且会将处理后的数据传递给高层用户。

    EAP_TLS虽然安全性能高,但是证书维护成本高且配置难度高,而且EAP_TLS在传送用户名的时候没有加密,即抓包的时候EAP_Identity报文中的用户名是明文显示的,可以考虑用EAP_PEAP或者是EAP_TTLS来代替,这两种认证方式不需要建立复杂的PKI系统,可以在TLS隧道内嵌套其他的认证方法,这不仅使复杂度大大降低,而且还提高了安全性。

    2.3.1 EAP_TLS认证过程

    EAP_TLS的认证过程(以签名算法使用RSA为例)如图所示:
    EAP-TLS认证过程

    1. 首先客户端给接入用户发送Identity报文,要求客户端提供身份标识;
    2. 接入用户给客户端回应Identity报文,内容是用户的身份标识,客户端将这个报文封装成Radius访问请求报文传给服务器;
    3. 服务器在获取到接入用户的接入标识后,会给客户端发送Radius访问挑战报文,客户端在收到这个报文后,对报文进行解封装,将TLS-Start报文传给接入用户;
    4. 接入用户发送TLS Client Hello报文给客户端,Client Hello报文中包括支持的TLS协议版本,支持的的加密算法,支持的压缩方法以及客户端随机数等,客户端收到后,将该报文封装到Access-Request中传给服务器;
    5. 客户端在收到服务器发来的Radius访问质询报文后,将TLS Server Hello报文传给接入用户,这个报文中包括server_hello,certificate,certificate_request,server_hello_done,其中server_hello报文中包括确认使用的TLS协议版本,服务器生成的服务器随机数(server random),session ID,确认使用的加密算法等,certificate代表的是服务器证书,certificate_request代表的是请求客户端提供证书,server_hello_done代表的是整个server hello过程的结束。
    6. 接入用户给客户端发送TLS change cipher spec报文,这个报文将被客户端封装成Access-Request报文传给服务器,change cipher spec报文包括以下内容,其中certificate指的是客户端证书,client_key_exchange包含pre-master secret,客户端生成的第三个随机数,pre-master secret首先采用RSA算法,生成一个48字节随机数,然后用server的公钥加密之后再放入报文中,certificate_verify中的内容是到这一步为止收到和发送的所有握手消息签名结果,change_cipher_spec的作用是客户端通知服务器开始使用加密方式发送报文,客户端使用上面的3个随机数client random, server random,pre-master secret,计算出48字节的master secret,这个就是对称加密算法的密钥,finished为发送的第一个加密报文,它使用HMAC算法计算收到和发送的所有握手消息的摘要,然后通过RFC5269中定义的一个伪函数PRF计算出结果,加密后发送;
    7. 服务器给客户端发送Access-Challenge报文,接入用户将收到TLS change cipher spec报文,到这儿握手结束;
    8. 客户端在收到接入用户发送的EAP-TLS报文后,将这个报文封装成Access-Request报文传给服务器;
    9. 服务器给客户端发送Access-Accept报文,接入用户将收到EAP-Success。

    2.4 EAP_TTLS

    EAP_TTLS协议的规范文档是RFC5281,EAP_TTLS是EAP_TLS的一种扩展,与EAP_TLS的区别是对证书的要求没有那么严格,只需要提供服务器端证书,而客户端证书不是必须的。
    EAP_TTLS是一个复合的认证方法,主要包括两个阶段:

    • 第一个阶段是在用户和认证服务器之间建立TLS隧道
    • 第二阶段是在已经建立的隧道内使用其他的认证方法进行认证。该认证通过在TLS通道内嵌套其他的认证方法来完成对客户端的认证,也具有很高的安全性。TTLS的扩展性很好,几乎支持所有的认证方法,包括MSCHAPv2。

    2.5 EAP_PEAP

    EAP_PEAP是一个复合的认证方法,主要包括两个阶段:

    • 第一个阶段是在用户和认证服务器之间建立TLS隧道,
    • 第二阶段是在已经建立的隧道内使用其他的EAP方法进行认证,如EAP-MSCHAPv2。

    EAP_PEAP的认证过程,具体流程如下:

    1. 握手阶段和EAP_TLS相似,与之不同的是,只需要服务器发送证书给客户端,实现客户端对服务器的认证,客户端不再需要发送自身的证书给服务器;
    2. 服务器给客户端发送Access-Challenge报文,客户端收到报文之后,解封装该报文,将其中的Identity报文传给接入用户;
    3. 客户端在收到接入用户发来的回应报文Identity后,将读报文封装在Access-Request中传给服务器;
    4. 服务器根据用户的Identity査找该接入用户的认证方法,在获取认证方法之后,向接入用户发送嵌套的认证方法的Challenge报文;
    5. 根据嵌套的认证方法的类型,接入用户和服务器进行相应的认证过程,直到服务器对接入用户认证成功;
    6. 服务器对接入用户认证成功后,给客户端发送访问质询报文,客户端将其中的Result=Success报文传给接入用户;
    7. 同样的,接入用户在收到报文后,给客户端发送EAP回应报文,客户端将EAP报文封装成访问请求的格式传给服务器;
    8. 服务器给接入用户发送Access-Accept报文,接入用户将收到EAP-Success。

    EAP_TTLS和EAP_PEAP还可以支持快速恢复TLS会话。在认证的第二阶段成功的情况下,无须执行认证第一阶段或第二阶段就能够恢复该会话,可以通过发送一条EAP-Success消息来进行重新身份验证尝试,这称为快速重连。这可以减少域间切换的延迟。

    展开全文
  • <div><ul><li>Add EAP CD basic template to OSO starter</li><li>EAP template / imagestreams to ose-v1.4.15</li></ul>该提问来源于开源项目:openshift/library</p></div>
  • EAP协议类型

    万次阅读 2016-05-17 17:13:11
    EAP协议类型 ——*——Stonex CWNP无线网络 可扩展身份认证协议(Extensible Authentication Portocol,EAP)最早定义在RFC2284中,是一种支持多种认证方法的认证框架,而不是一个认证机制。EAP最初被设计用于PPP...

    可扩展身份认证协议(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

     

     

    展开全文
  • ocp_eap_demo:演示Java EAP Openshift
  • EAP-TLS/EAP-TTLS/EAP-PEAP

    千次阅读 2019-05-22 14:59:57
    IEEE的802.1X使用了EAP认证框架,因为EAP提供了可扩展的认证方法,但是这些认证方法的安全性完全取决于具体的认证方法,比如EAP-MD5、EAP-LEAP、EAP-GTC等,而802.1X最开始是为有线接入设计的,后来被用于无线网的接...

    原文:http://blog.chinaunix.net/uid-26422163-id-3457357.html

     

    IEEE的802.1X使用了EAP认证框架,因为EAP提供了可扩展的认证方法,但是这些认证方法的安全性完全取决于具体的认证方法,比如EAP-MD5、EAP-LEAP、EAP-GTC等,而802.1X最开始是为有线接入设计的,后来被用于无线网的接入,有线接入在安全性方面考虑毕竟少,如果要窃取信息需要物理上连接网络,而无线网完全不同,无线网信号没有物理边界,所以要使用802.1X的话,需要对802.1X进行安全性方面的增强,也就是增强EAP认证框架的安全性,而且要进行双向认证,那么EAP使用了IETF的TLS(Transport Layer Security)来保证数据的安全性,见如下描述:

     

    1. 802.1x was initially developed for authentication of users on traditional wired LANs, and therefore did not require strong encryption. Eavesdropping is certainly possible on wired networks, though it requires physical access to network equipment. Wireless networks are much easier to perform traffic analysis on because physical access to the network does not require physical access to the network equipment. Frames on wireless networks can be easily intercepted in transit with wireless network analysis software. Wireless networks also have additional authentication requirements. Without physical access to the equipment, users need to ensure that they are connecting to legitimate access points that are part of the organization's network, not "rogue" access points set up as part of a man-in-the-middle attack. In addition to the requirement for user (client) authentication, wireless network users also need to authenticate the networks they connect to.
    2.  
    3. These two requirements, strong encryption to prevent eavesdropping and mutual authentication to ensure that sensitive information is transmitted only over legitimate networks, must drive your wireless authentication strategy. In practice, only methods based on the IETF's well-known Transport Layer Security (TLS) standard can satisfy strict encryption and authentication requirements. Three TLS-based protocols have been developed for use with EAP and are suitable for deployments with wireless LANs:
    4.  
    5. EAP-Transport Layer Security (EAP-TLS)
    6. Tunneled Transport Layer Security (TTLS)
    7. Protected EAP (PEAP)

        现在有3种基于TLS的EAP认证方法:

      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,但是他们的实现有所区别。

     

        他们之间关系如下:

    展开全文
  • EAP 2019

    2020-12-30 08:57:48
    <div><p>Please, add support for new EAP version </p><p>该提问来源于开源项目:BashSupport/BashSupport</p></div>
  • EAP 6.2.4

    2020-12-09 03:46:12
    <div><p>ftp://ftp.redhat.com/redhat/jbeap/6.2.4/en/source/</p><p>该提问来源于开源项目:hasalex/eap-build</p></div>
  • <div><p>Right now in pfstats we use pap to test eduroam and ...We should use eap-peap, eap-tls or eap-ttls to test the authentication.</p><p>该提问来源于开源项目:inverse-inc/packetfence</p></div>
  • EAP segfault in HEAD

    2020-12-06 12:48:27
    (8) eap : Calling eap_mschapv2 to process EAP data (8) eap_mschapv2 : # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (8) eap_mschapv2 : group MS-CHAP { (8) eap_mschapv2 : - entering...
  • EAP认证

    千次阅读 2019-05-29 10:45:10
    上图中展示的是OTP(一次性密码)实现EAP交换过程,具体的EAP交换过程如下:步骤1:请求方向认证方发送EAPOL-Start消息,通知对方已经做到了认证准备(注意:若会话由认证方发起,不需要该报文)步骤2:在检测到链路...
  • <div><p>See the image below, the EAP6 servers and EAP7 servers are freshly unzipped with the agent and then run like: sh jboss-eap-6.4/bin/standalone.sh -Djboss.socket.binding.port-offset=100 -b ...
  • 设备EAP管理 Equipment Automation Program

    万次阅读 2020-06-20 17:38:47
    设备EAP管理 Equipment Automation Program
  • <p>I am just wondering why EAP templates doesn't have templates with no database for general templates. Are we are only providing persistent related templates? <p>When I do <code>oc get templates...
  • EAP协议技术简介

    2018-08-05 14:26:05
    第一章 EAP协议概述 - 2 - 1.1 简介 - 2 - 1.2 结构 - 2 - 第二章 EAP协议类型 - 3 - 2.1“弱”EAP协议 - 3 - 2.1.1 EAP-MD5 - 3 - 2.1.2 EAP-LEA - 3 - 2.2“强”EAP协议 - 3 - 2.2.1 EAP-PEA - 3 - 2.2.2 EAP-TTLS...
  • EAPEAP AKA算法

    千次阅读 2016-06-27 14:15:17
    AKA Authentication and Key Agreement CK cipher key IK integrity key RAND random number AUTN authentication token AMF authentication management field RES response XRES expected response ...1 EAP
  • EAP 6.4.0 support

    2020-12-09 14:58:05
    <div><p>Seems like EAP version 6.4.0 is available: http://ftp.redhat.com/redhat/jbeap/6.4.0/en/source/</p><p>该提问来源于开源项目:hasalex/eap-build</p></div>
  • 【Jboss EAP】初识JBoss EAP

    千次阅读 2018-03-04 23:31:33
    小编最近加入了公司的JavaEE团队,在做一些JavaEE相关的项目,在项目中用的是JBoss EAP服务器,由于是接触JavaEE项目的时间不长,所以对于JBoss EAP来说,自己只处于基本的会用的阶段。最近项目不是很紧,抽空研究...
  • 规范JBoss EAP 7基于以下规范构建:Java EE 7(JSR 342)Java SE 1.8Java EE 7 specifications:Note: orange indicate new specifications.JBoss EAP 7 implements the full Java EE 7 specification and is a ...
  • jboss-eap-7.1.0

    2018-03-08 16:59:47
    jboss-eap-7.1.0 jboss-eap-7.1.0 jboss-eap-7.1.0 jboss-eap-7.1.0 jboss-eap-7.1.0
  • EAP介绍.pdf

    2019-09-10 21:50:25
    对于EAP协议的介绍内容。EAP的架构非常灵活,在Authenticator(认证方)和Supplicant(客户端)交互足够多的信息之后,才会决定选择一种具体的认证方法,即允许协商所希望的认证方法。内容简单易懂。
  • (The EAP-PEAP code already does something like that: <a href="https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/src/modules/rlm_eap/types/rlm_eap_peap/peap.c#L439">src/modules/rlm_eap/types...
  • PHPStorm EAP access

    2020-12-27 17:46:31
    <div><p>it would be AMAZING if you could update teh version to allow the EAP users to install this plugin.</p><p>该提问来源于开源项目:OpherV/gitflow4idea</p></div>

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,096
精华内容 1,638
关键字:

eap