其他分享
首页 > 其他分享> > 【转】 IEEE 802.1X-PEAP认证过程分析(抓包)

【转】 IEEE 802.1X-PEAP认证过程分析(抓包)

作者:互联网

 

转自:https://blog.csdn.net/u012503786/article/details/79296522

IEEE 802.1X-PEAP认证过程分析(抓包)
 本文介绍IEEE802.1X认证的PEAP认证方式,是带有radius服务器的EAP中继认证。
 IEEE802.1X认证是使用EAP报文格式在申请者和认证者之间交换信息。带有radius服务器,即认证者不对申请者发送的数据进行解析处理,而是封装后直接转发给radius服务器。由radius服务器进行处理。

 PEAP认证方式,是在此基础上,首先建立一个申请者到认证服务器的传输隧道。然后在隧道中进行认证挑战等操作。隧道保证了挑战等数据的安全性

下面将根据把整个802.1X认证过程分为三部分

1、认证初始化:radius服务器获取申请者的身份信息,并回应认证开始

2、建立TLS隧道:为了保证认证数据的安全性

3、认证过程:由于在安全的TLS隧道内传输,我们并不知道进行的是什么挑战方式。只有申请者和认证服务器才能知道。

1、过程报文介绍
1.1、认证初始化
1、申请者向认证者发送EAPOL-start报文,开始802.1X接入的开始

2、认证者向申请者发送EAPOL-request/identity报文,要求申请者将用户信息送上来

 

 

EAP-request/identity

1、     申请者回应认证者发送EAPOL-response/identity报文。其中包含用户名

 

 

EAP-response/identity

2、  认证者以EAP overRADIUS 的报文格式将EAP-response/identity发送给认证服务器,并带上相关的RADIUS属性

 

 

Access-request/identity

字段含义:

Authenticator域占用16个字节,用于RadiusClient 和Server之间消息认证的有效性,和密码隐藏算法。访问请求Access-Request报文中的认证字的值是16字节随机数,认证字的值要不能被预测并且在一个共享密钥的生命期内唯一。

1.访问请求认证字

在Access-Request包中认证字的值是16字节随机数,认证字的值要不能被预测,并且在一个共享密钥的生命期内唯一;

2.访问回应认证字

Access-Accept Access-Reject 和Access-Challenge包中的认证字称为访问回应认证字,访问回应认证字的值定义为MD5(Code+ID+Length+RequestAuth+Attributes+Secret);

Attributevalue pairs:

service-type:2:为接入用户

          NAS-IP-address:网络接入服务器IP地址

         called-station-ID:认证者的MAC地址

         NAS-port-type:NAS的端口类型,总是802.11

          NAS-port:NAS的端口

          calling-station-ID:申请者的MAC地址

         acct-session-ID:计费连接号

          framedMTU:最大传输单元

          EAP-message:EAP报文

          message-authenticator:(RFC3579)客户端发送一个access-request,或者是服务器发送access-challenge时,添加的一个标识。接收方可以根据相同的操作进行验证。计算方法:

Message-Authenticator = HMAC-MD5(Type, Identifier, Length, Request Authenticator,
Attributes)

每一个EAP报文都可以使用该属性。

3、  认证服务器收到认证者发来的EAP-response/identity,根据配置确定使用EAP-peap认证,向认证者发送RADIUS-access-challenge报文,里面含有radius发送给申请者的EAP-request/peap/start报文,希望开始进行EAP-PEAP认证

 

 

Access-challenge/EAP-peap-start

字段含义:state:如果RADIUS服务器发送给设备的接入质询报文中包含该值,则设备在后续的接入请求报文中必须包含相同的值

4、  认证者向申请者发送EAP-request/peap/start报文

 

 

EAP-request/protected EAP(EAP-PEAP)-start

3.1.2、建立TLS通道

 


5、  申请者收到EAP-request/peap/start报文,产生一个随机数、客户端支持的加密算法列表、TLS协议版本、会话ID、以及压缩方法(目前均为NULL),封装在EAP-response/TLS/clienthello报文中发送给认证者

 

 

TLSv1-client hello

字段含义:

 version:客户端支持的最高版本号

 random:客户端生成的随机值

 session ID:唯一标识一个session

 cipher suite:每个ciphersuite 包含一个密钥交换算法,一个大量数据加密算法,一个MAC算法和一个PRF(TLS的 PRF 就是把 P_hash 应用在secret上)构成

 

 

Compression methods:包含压缩算法的列表

客户端发送client hello后,服务器必须回复server hello。

6、  认证者以EAP overRADIUS 的报文格式将EAP-response/TLS/client hello发送给认证服务器,并带上RADIUS的属性

 

 

Access-request/client hello

7、  认证服务器收到clienthello报文后,会生成server hello、certificate、server key change、server hello done报文封装在EAP消息中,使用access-challenge报文发给认证者

 

 

Access-challenge/server hello

总共发送server hello,certificate,server key exchange,server hello done四组数据。由于数据太长,所以进行分段处理

使用EAP-response/protected EAP报文进行响应,直到接收最后一片。

Server hello字段:

version:服务器选择客户端client hello报文中version和服务器支持的版本号的最小值

random:服务器生成的random,与client hello中的random没有任何关系

session ID:服务器为本链接分配的session ID

cipher suite:服务器从client hello的cipher suite 字段选择的一个。

Compression method:压缩方法

certificate字段:

certificate:服务器证书

server key exchange字段:

EC Diffie-Hellman server params:

Curve type:支持3中曲线类型,可以自行制定椭圆曲线的多项式系数,基点等参数。但是现在基本不使用,而是使用named curve

Named curve:参数已经预先选定,各种密码学库普遍支持的一组曲线,最常见的是secp256r1

pubkey:公钥

signature:签名

server hello done:在serverhello和相关信息已经处理完毕之后,服务器发送server hello done。发送完server hello done后服务器开始等待客户端的响应

8、  认证者将认证服务器的报文中的EAP-request消息发送给申请者

 

 

TLSv1-server hello

11、申请者收到报文后,进行验证server的证书是否合法(使用刚从CA证书颁发机构获得的根证书进行验证,主要验证证书时间是否合法,名称是否合法),即对网络进行认证,从而可以保证server的合法。

     如果合法,提取server证书中的公钥,同时产生一个随机密码串pre-master-secret,并使用服务器的公钥对其进行加密,最后将加密的信息clientkeyexchange + 客户端的证书(如果没有证书,可以把属性置为0) + TLS finished属性封装成EAP-response/TLS clientkeyexchange报文发送给认证者,

如果申请者没有安装证书,则不会对server证书的合法性进行认证,即不能对网络进行认证

 

 

TLSv1-client keyexchange

Client key exchange字段:客户端必须在serverhello done 到达后发送client key exchange消息。

ec_diffie_hellman:pubkey:公钥

change cipther spec字段:客户端切换成密文模式

encrypted handshake message字段:(finished)这个包表示握手已经完成,并且对之前发过的数据进行加密发送给对方做校验,防止被篡改。同时也验证加密算法和密钥是否正常工作

12、认证者以EAP over RADIUS 的报文格式将EAP-response/TLSclientkeyexchang发送给认证服务器,并带上相关的RADIUS属性

 

 

Access-request/client key exchange

13、认证服务器收到报文后,用自己的证书对应的私钥对clientkeyexchange进行解密,从而获得pre-master-secret,然后对pre-master-secret进行运算处理,加上申请者和server产生的随机数,生成加密密钥、加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了。认证服务器将协商出的加密方法 + TLS finished消息封装在EAP over RADIUS 的报文access-challenge中,发送给认证者

 

 

Access-challenge/change cipher spec

changecipherspec:服务器切换到密文模式

 

14、认证者将认证服务器发送的报文,以EAP-request消息发送给申请者

 

 

TLSv1-change cipher spec

15、申请者回复认证者EAP-response/TLSOK

 

 

EAP-response/protected EAP(EAP-PEAP)

16、认证者将EAP-response/TLSOK消息封装在radius报文中,发送给认证服务器,告知服务器申请者和认证服务器之间的TLS隧道建立成功

 

 

Access-request/protected EAP(EAP-PEAP)

 

至此,隧道建立完毕,申请者和认证服务器之间使用协商的密钥进行加密传输,然后进行验证

3.1.3、认证过程
17、认证者将radius报文中的EAP域提取,封装成EAP-request报文发送给申请者

 

 

Access-challenge/application

 

 

TLSv1-request/application

18、申请者受到报文后,用服务器相同的方法生成加密密钥。加密初始化向量和hmac的密钥,并用相应的密钥及其方法对报文进行解密和校验,然后产生认证回应报文,用密钥进行

加密和校验,最后封装成EAP-response报文发送给认证者,认证者转发给认证服务器,并带上相关的RADIUS的属性,这样反复进行交互,直到认证完成。在认证过程中,认证服务器会下发认证后用于生成空口数据加密密钥PMK给申请者

 

 

TLSv1-response/application

 

 

Access-request/application

以上application data 的交换过程可能执行多次,直至成功。

19、服务器认证客户端成功后,会发送一个RADIUS-access-accept给认证者,并包含认证服务器提供的MPPE属性(vendor specific)。

 

 

Access-accept

20、认证者收到RADIUS-access-accept报文,会提取MPPE属性中的密钥作为WPA加密用的PMK,并且会发送EAP-SUCCESS报文给申请者

 

 

EAP-success

2、问题
(1)为什么server hello 要进行很多次?

数据太长了,需要分段,每次只发一小段。

(2)802.1X和PSK认证方式在RSN信息中,那么PEAP还是其他认证方式,在哪里体现?

    申请者连接时,输入用户名和密码的同时要选择认证类型PEAP、TTLS或其他。表明申请者并不知道radius服务器能支持什么认证 。挑战方式等是由申请者决定的,而radius服务器会发送一个默认的方式,如果与申请者想要的挑战方式不同,可以经过协商解决。如果服务器不支持这种认证方式,那么认证就会失败。

     如果在用户名传递之后(EAP-response/identity)之后,回复的挑战并不是申请者要进行的挑战,申请者可以发送EAP报文进行协商

(3)外层认证方式是PEAP,内层认证方式是什么?

 在报文中内层认证方式不能确定。因为在TLS隧道内传输。无法被破解。

 内层认证方式由申请者连接时选择的。



标签:报文,申请者,PEAP,认证,802.1,服务器,EAP,server,IEEE
来源: https://www.cnblogs.com/cxt-janson/p/11010672.html