IEEE 802.1X-PEAP认证过程分析（抓包）

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隧道内传输。无法被破解。

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