【转】 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