EAP

802.1x认证的EAP协议（总体流程）

­参考RFC 3748

­

Supplicant主机                  服务器

-----------                 -------------

    |------------------------------>| 主机向服务器（多播或广播地址）发送EAPOL-Start

    | 1.  EAPOL-Start               |

    |                               |

    |<------------------------------| 要求验证身份的请求

    | 2. EAP-REQUEST-Identity       |

    |                               |

    |------------------------------>| 回应(用户名)

    | 3. EAP-RESPONSE-Identity      |

    |                               |

    |<------------------------------| 要求验证密码的MD5校验值(随机加密字Challenge)

    | 4. EAP-REQUEST-MD5_Challenge  |

    |                               |

    |------------------------------>| 回应（使用Challenge加密口令）

    | 5. EAP-RESPONSE-MD5_Challenge |

    |                               |

    |<------------------------------| EAP-Success（判断正确性）

    | 6.       EAP-Success          |

    |                               |

 

在任何时候服务器发来EAP-Failure数据包，都表示整个认证过程终止。

­

在以太网中，EAP协议当然也是通过以太网帧的格式来传送，帧类型为0x888e，在基于pcap的抓包程序中，可使用"ether proto 0x888e"来抓取。

­

Ethernet-Header： (802.3,局域网标准)

################################################

#  0              5               11       13  #

# +----------------+----------------+--------+ #

# |DST--MAC        |SRC--MAC        |0x888e  | #

# +----------------+----------------+--------+ #

################################################

EAP协议不仅可用于本文关注的以太网环境中，还可在无线WLAN、令牌环网中应用，而这些链路帧是各不相同的，这就是为什么有EAPOL类型的数据帧，用以抽象EAP协议报文。

­

EAPOL-报文结构

############################################

#  0                           14 15       #

# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #

# | Ethernet-Header           |a|b|        #

# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #

#    17                                    #

# +-+-+-------------                       #

# |c  |Packet Body                         #

# +-+-+-------------                       #

############################################

a:EAPOL 协议版本

b:EAPOL 报文类型

c:EAPOL 帧长度

a类型说明：通常为常量0x01

b类型取值：

EAPOL-Packet :   0x00 //各种EAP协议的信息交互，封装在EAPOL-Packet类型的EAPOL报文内

EAPOL-Start:     0x01

EAPOL-Logoff:    0x02

­

EAP-报文结构

#########################################

#  0                            15      #

# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #

# |                               |     #

# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #

#   17 18 19 21 22                      #

# +-+-+-+-+-+-+-+--------------         #

# |   |d|e|f  |g|EAP Body               #

# +-+-+-+-+-+-+-+--------------         #

#########################################

d:EAP通信类型

e:EAP通信id

f:EAP数据长度

g:EAP协商类型

d类型取值：

EAP-Request:  0x01

EAP-Resopnse: 0x02

EAP-Success:  0x03

EAP-Failure:  0x04

e类型说明：

通常由服务器发来的报文指定，在连续的报文内使用这个id来协商或者计算MD5值的数据之一。

g类型取值：

Identity:        0x01

MD5_Challenge:   0x04

注意EAPOL帧和EAP帧的两处长度位置，前者的长度是不算EAPOL头的4个字节的，而后者则包含自身头部的5个字节，所以这两个长度的值可能是一致的，但具体可能有扩展信息放在EAPOL帧尾部，则前者比后者大。

­

下面是需要程序构建的数据包的大概细节：

      1.EAPOL-Start、EAPOL-Logoff

      通常是比较简单的数据包，只需填好相应的位，没有其他附加消息，EAPOL-Start、EAPOL-Logoff两种报文长度为0，通常建立起来两个报文的长度就只有18字节。

­

      2.EAP-REQUEST-Identity

      服务器发来的这个报文也比较简单，可能唯一有用的数据是“e:EAP通信id”位，需要给发送回去的报文中把相应位设置为该值，虽然这很可能是常数。

­Identity格式

     +-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| EAP Header      |  Username

+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      3.EAP-RESPONSE-Identity

      只需要设置“d:EAP通信id”位，然后在EAP头后紧接用户名的ASCII码信息。有些品牌的协议中，则顺带在此数据包开始校验客户端的IP、版本号等信息。

­

      4.EAP-REQUEST-MD5_Challenge

      找到该用户名对应的口令信息，用随机生成的一个加密字Challenge对它进行加密处理（MD5）

服务器请求MD5校验的报文中包含了重要的信息，首先也是“e:EAP通信id”位，后一个报文也需要设置该位；

在EAP报头后紧接一个一位的长度值L（常量0x10），表示紧跟其后的重要数据的长度，其后的16位值则需要用来计算下一个报文中的信息，我们称之为attach-key。

­MD5_Challenge格式

+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| EAP Header      |L|MD5-Key/Value

+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      5.EAP-RESPONSE-MD5_Challenge

      首先需要设置“d:EAP通信id”位，然后构建一个这样的字节数组［(e:EAP通信id)(用户密码的ASCII)(attach-key)]，这个字节的长度当然是(1+用户密码长度+16)，然后送入MD5计算函数中，获得16位的计算结果，再把这16位计算结果填入报文。报文格式跟请求的类似，在包头后紧接一位长度值，当然是0x10，然后是16位的计算结果。 用该加密字对口令部分进行加密处理（MD5) 来的加密后的口令信息和其自己经过加密运算后的口令信息进行对比，判断用户是否合法

­

一个客户端程序所做的事情通常就是这么多，而因为EAP协议的“Extensible”的特性，几乎我们见到的每个品牌的协议都有所扩展，而且各不相同，所以各个品牌之间的客户端甚至交换机等设备都可能完全不可兼容的，其协议很可能在上述的报文中都添加一个信息尾，用来校验各种信息。

 

­

EAP-SIM学习 ­

 

      EAP-

 

Response/SIM/Challenge (AT_MAC)步骤说明：

            据AT_RAND等Sres信息|NONCE_MT|Version|... 计算自己的AT_MAC'和AT_MAC比较

            然后生成一个序列，部分为四次握手MK(万能钥匙，这增加了后面的四次握手的安全性)

            Response含Sres的AT_MAC''，让服务器再认证。

­

      GSM subscribers身份标识：IMSI（International Mobile Subscriber Identity）。IMSI组成：不多于15数字的String，MCC（Mobile Country Code）3位，MNC（Mobile Network Code）2或3位，MSIN（Mobile Subscriber Identification Number）不多于10位.

      Internet AAA protocols身份标识：NAI(Network Access Identifier)[RFC4282]. 形式为：(username@realm).对于永久用户，可以使用IMSI生成用户名（第一位加‘１’）；pseudonym usernames and fast re-authentication, identities由认证服务器生成。

­

­

EAP-AKA学习

 

      EAP-AKA用于第三代移动通讯网络(3G)的认证和密匙协商机制 (Authentication and Key Agreement). AKA基于对称密码学原理，通常运行在手机的SIM卡上,3G中称为USIM.

 

       Peer                                             Authenticator
          |                      EAP-Request/Identity             |
          |<------------------------------------------------------|
          |                                                       |
          | EAP-Response/Identity                                 |
          | (Includes user's NAI)                                 |
          |------------------------------------------------------>|
          |                            +------------------------------+
          |                            | Server runs AKA algorithms,  |
          |                            | generates RAND and AUTN.     |
          |                            +------------------------------+
          |                         EAP-Request/AKA-Challenge     |
          |                         (AT_RAND, AT_AUTN, AT_MAC)    |
          |<------------------------------------------------------|
      +-------------------------------------+                     |
      | Peer runs AKA algorithms,           |                     |
      | verifies AUTN and MAC, derives RES  |                     |
      | and session key                     |                     |
      +-------------------------------------+                     |
          | EAP-Response/AKA-Challenge                            |
          | (AT_RES, AT_MAC)                                      |
          |------------------------------------------------------>|
          |                          +--------------------------------+
          |                          | Server checks the given RES,   |
          |                          | and MAC and finds them correct.|
          |                          +--------------------------------+
          |                                          EAP-Success  |
          |<------------------------------------------------------|

            Figure 1: EAP-AKA full authentication procedure•           

AT_MAC(Message Authentication Code)用来保护EAP数据包的完整性。

•

•支持用户身份的保密

EAP-AKA支持利用已得到的KEY进行快速重新认证。

交互记录：

       Server不应该依赖EAP-Response/Identity中的Indentity信息，应该使用EAP-Request/AKA-Identity包主动请求（EAP-Response/AKA-Identity的AT_IDENTITY属性指示）。

      1）使用AT_PERMANENT_ID_REQ属性：Server想让Peer反馈永久认证身份（permanent identity）在EAP-Response/AKA-Identity 包的AT_IDENTITY属性。如果Peer只有permanent identity，反馈EAP-Response/AKA-Identity（在AT_IDENTITY属性中包含permanent identity）；如果还有pseudonym identity，反馈可能是EAP-Response/AKA-Client-Error（code "unable to process packet"），或者permanent identity。然后，如果Server发现不是合法的permanent identity，发送EAP-Request/AKA-Notification（AT_NOTIFICATION code"General failure" (16384)），终止EAP认证。否则EAP-Request/AKA-Challenge开始全认证过程。

      2）AT_FULLAUTH_ID_REQ属性：Server想让Peer反馈全认证身份（full authentication identity (pseudonym identity))。服务器不支持快速重认证。首先反馈pseudonym identity（如果有），否则反馈permanent identity。然后，如果Server发现不能把pseudonym identity映射到一个合法的permanent identity，发送AT_PERMANENT_ID_REQ。

      3）AT_ANY_ID_REQ属性：Server想让Peer反馈一个身份（an identity）。如果Peer维护了快速重连状态信息，并且想使用快速重连，反馈re-authentication identity属性信息。其次，判断pseudonym identity，最后判断permanent identity。如果Server同意重认证，发送EAP-Request/AKA-Reauthentication，否则发送AT_FULLAUTH_ID_REQ或者AT_PERMANENT_ID_REQ。

 

      EAP/AKA-Identity可能轮回多次（最多3次），这种情况的顺序：

                  AT_ANY_ID_REQ -> AT_FULLAUTH_ID_REQ -> AT_PERMANENT_ID_REQ.

 

WLAN\3G应用AKA:

WLAN-UE（User Equipment）：WLAN 用户的移动终端设备

WLAN-AN（Access Network）：WLAN接入网络

3GPP AAA 服务器: 3GPP 网络认证、授权、计费服务器

HSS/HLR: 家乡用户服务器/ 家乡位置寄存器

IMSI: 国际移动用户标志( International Mobile Station Identity)

f1 ～f5。为3G 安全结构中定义的算法,

      f1 算法用于产生消息认证码,

      f2 算法用于消息认证中计算期望响应值,

      f3 算法用于产生加密密钥,

      f4 算法用于产生完整性密钥,

      f5 算法用于产生匿名密钥。

 协议流程

① WLAN-UE→ WLAN-AN: NAI(身份标志)
② WLAN-AN→ 3GPP AAA: NAI
③ 3GPP AAA→WLAN-AN: RAND, AUTH, WLAN-UE 的临时标志, 消息鉴别码
④ WLAN-AN→ WLAN-UE: RAND, AUTH, WLAN-UE 的临时标志, 消息鉴别码
⑤ WLAN-UE→ WLAN-AN: RES, 消息鉴别码
⑥ WLAN-AN→ 3GPP AAA: RES, 消息鉴别码
⑦ 3GPP AAA→ WLAN-AN: WLAN-UE 的认证结果, WLAN-AN 与WLAN-UE的共享密钥
⑧ WLAN-AN→ WLAN-UE: WLAN-UE 的认证结果

说明：
      ③收到WLAN-UE 的身份标志后, 3GPP AAA 服务器首先询问HSS, 该用户是否有使用WLAN提供的服务权限。然后从HSS/HLR 中取得与该用户相关的认证向量AV, 同时也获得与该用户IMSI 对应的新的临时标志。

      其中, AV = RAND‖XRES‖ CK ‖ IK ‖ AUTN, RAND 为随机数, XRES = f2k( RAND) , CK = f3k( RAND) , IK = f4k ( RAND) , AUTN = SQN ‖AK‖AMF‖MAC; SQN为序列号, AK = f5k ( RAND) , AMF 为认证管理域, MAC = f1k ( SQN‖RAND‖AMF) 。

      随后, 从IK 和CK 中生成共享密钥, 这些共享密钥一方面可用于WLAN通信的机密性和一致性保护, 另一方面也用于保护WLAN-UE 的临时标志。

      构造EAP 请求/AKA 挑战消息, 消息包含RAND、AUTH、临时标志, 并计算消息鉴别码。最后, 将EAP 请求/AKA 挑战消息发送给WLAN-AN。

      ⑤WLAN-UE 首先验证AUTH, 并确认接收的序列号SQN是否在有效范围内, 如果都正确, 则实现了对3G 网络的认证。

      计算IK和CK, 从IK和CK 中生成共享密钥, 然后验证消息鉴别码是否正确, 并保存收到的临时标志。

      计算RES = f2k( RAND) , 构造EAP回应/AKA 挑战消息, 消息包含RES, 并计算消息鉴别码。最后, 将EAP 回应/AKA 挑战消息发送给WLAN-AN。

      ⑦3GPP AAA 服务器首先验证消息鉴别码, 然后计算XRES, 并与收到的RES 进行比较。如果正确, 则认证了WLAN-UE 的身份, 并向WLAN-AN发送EAP 成功的消息。同时一起发送的还有在WLAN通信中用于机密性和一致性保护的共享密钥。

      ⑧WLAN-AN保存共享密钥, 此共享密钥将用于与WLANUE通信时的机密性和一致性保护, 同时将EAP 成功的消息发送给WLAN-UE。

 

安全性分析

     EAP-AKA 协议基于WLAN-UE 与HSS/HLR 之间共享的秘密密钥K, 实现WLAN用户与3G 网络的相互认证和密钥分配。

 

( 1) WLAN用户与3G 网络之间的双向认证。

      WLAN用户对3G 网络的认证是在上述第⑤ 步实现的。WLAN-UE 收到3GPP AAA 服务器发送过来的AUTN = SQNī AK‖ AMF‖MAC, 确认序列号SQN是否在有效范围内, 并验证AUTH 是否正确。因为只有使用正确的秘密密钥K 才能生成正确的AUTN, 而只有合法的HSS/HLR 才有秘密密钥K, 因此上述过程实现了对3G网络合法性认证。
      3G网络对WLAN 用户的认证是在上述第⑦ 步实现的。3GPP AAA 服务器首先计算XRES = f2k ( RAND) , 然后与收到的RES= f2k ( RAND) 进行比较。也因为只有合法的WLAN 用户才有秘密密钥K, 因此如果XRES = RES, 就可以认证WLAN用户的合法身份。

( 2) WLAN-UE 与WLAN-AN 之间的密钥分配。

      合法的WLAN-UE 收到正确的随机数RAND 后, 能正确生成CK = f3k( RAND) 和IK= f4k ( RAND) , 进而能正确生成用于WLAN 通信中机密性和一致性保护的会话密钥。而WLAN-AN的会话密钥是从3GPP AAA 服务器得到的, 3GPP AAA 服务器首先生成CK 和IK, 然后生成会话密钥, 再传送给WLAN-AN。因此, EAP-AKA 协议能确保WLAN-UE 与WLAN-AN 之间能共享会话密钥, 并且会话密钥没有在无线接口中传输, 具有一定的安全性。

 

( 3) 密钥的新鲜性。

      在EAP-AKA 协议的每次认证过程中, WLAN-UE 与WLAN-AN 共享的会话密钥通过CK 与IK 生成, 而CK与IK 是采用随机数计算得到的, 从而确保了密钥的新鲜性。

( 4) 防重放攻击。

      协议传递的消息使用了随机数和不断递增的序列号SQN作为输入, 因而保证了消息的新鲜性。并且, 该随机数包含在保证消息完整性的消息鉴别码, 而响应方在响应消息的鉴别码中也包含了该随机数, 因此任何第三方都无法利用先前截获的消息发起重放攻击。

( 5) 潜在的漏洞。

      与3G 的认证与密钥分配协议AKA 一样, EAP-AKA 协议也没有WLAN 用户与3G 网络之间共享的秘密密钥K 的更新机制, 这可能会导致USIM克隆攻击。另外, 当WLAN 用户首次进行认证, 或3G 网络不认识WLAN用户的临时标志时,WLAN用户需传送IMSI, 并且使用的是明文, 这会影响用户身份的机密性。

 

( 6) 可能的攻击。

      3G 网络的认证与密钥分配协议AKA 存在MS( 移动站) 假冒攻击的可能。事实上,同样的攻击也可能发生在EAP-AKA 协议上。并且, 由于WLAN的覆盖范围小,WLAN-AN与WLAN-UE 一样, 都处在比较开放的环境中, 因而还有可能发生WLAN-AN假冒攻击。具体描述如下: ①WLAN-AN 假冒攻击。EAP-AKA 协议实现了WLAN用户与3G 网络之间的相互认证, 但双方都没有对WLAN-AN 的身份进行认证。并且, 在协议第⑧ 步中, 3GPPAAA 服务器将用于WLAN通信中机密性和完整性保护的会话密钥, 直接以明文的形式发送给WLAN-AN。如果攻击者首先利用某种方式( 如DoS 攻击) 攻陷WLAN-AN, 然后假冒成WLAN-AN, 则可以获取WLAN 中的会话密钥, 这样就使得WLAN的通信失去了保密性。②WLAN-UE 假冒攻击。攻击者A 还可利用截获的合法用户身份标志进行攻击。这样, 攻击者A 就可以假冒该用户的身份入网。因为没有会话密钥, 因此攻击者A 此时还不能进行正常的通信。而如果攻击者A 同时对WLAN-AN 与3GPP AAA 服务器之间的
通信进行窃听, 则可以获取WLAN-UE 的会话密钥。此时攻击者A 就可以假冒该用户, 在3G 与WLAN互联网络中进行正常的通信。

 

EAP扩展的比较：

 

Conent	EAP-MD5	EAP-SIM	EAP-AKA	EAP-TLS
是否需要　　智能卡	均可	是	是	均可
密码学原理	对称	对称	对称	非对称
支持双向认证	否	可以[有缺陷]	是	是
产生会话密匙	否	是	是	是
抗字典攻击	否	是	是	是
数据签名	否	否	否	是

­

­EAP-TLS基于非对称密码学原理(也称作PKI),智能卡实现成本高，系统实施复杂，主要用于网上银行，电子商务领域。

•EAP-AKA克服了EAP-SIM的已知缺陷，提供了足够的安全性。

•

补充：

4 way handshake

如果抓包，那么4-way handshake就是里面的四个EAPOL-KEY的包。如果是RSN方式那么GTK的2-way handshake其实也包含在这四个包里面，最后两条就是。

4-way的分析我翻译自802.11i-2004 8.5.2.2，因为这个东西三言两语是说不清楚的。网上的那些只能作为科普而不可以用来精确的理解。

 

8.5.2.2 EAPOL-key Frame notation

EAPOL-Key(S, M, A, I, K, KeyRSC, ANonce/SNonce, MIC, RSNIE, GTK[N])

                其中:

         S:   initial key exchange完成标志，它是key information中的安全位标志位

M:  MIC包含标志位。除了message 1外，其他三条信息都应该置该位，它是key information中的KEY MIC位

A: 信息需要ACK标志位，当接收方需要回应这条消息时，置该位。它是key information  中的KEY Ack位

I:    安装标志位，是否安装paiwise key。他是key information中的Install位

K:   key类型标志位，P (Pairwise), G (Group/STAKey). 他是key information中的key type位

KeyRSC  KeyRSC，它在KeyRSC域中

Anounce/SNounce:  他是Authenticator/Supplicant nonce.它在 the Key Nonce域中

MIC               :               MIC

RSNIE:          RSN IE，它在Key data域中

GTK:             加密的GTK，它在Key data域中

N:                   key标识，用于只是GTK的索引。

 

8.5.3.4 4-way handshake

                4次握手过程可以用下面的公式表示。

          Message 1. Authenticator → Supplicant: EAPOL-Key(0,0,1,0,P,0,ANonce,0,0,0)

Message 2. Supplicant → Authenticator: EAPOL-Key(0,1,0,0,P,0,SNonce,MIC,RSNIE,0)

Message 3. Authenticator → Supplicant: EAPOL-Key(1,1,1,1,P,KeyRSC,ANonce,MIC,RSNIE,GTK[N])

Message 4. Supplicant → Authenticator: EAPOL-Key(1,1,0,0,P,0,0,MIC,0,0)

                用简单的言语解释一下，基本意思就是

         PTK是两边都要对上的，而GTK是在PTK成功后，AP直接将加密过GTK发给STA，STA再把GTK解出来。抓包看到有四个EAPOL-KEY，后两个包含AP和STA安装GTK。

 

对于PTK，AP送Anouce给STA，STA收到后，自己产生一个SNounce然后结合ANounce PMK AA和SA得出PTK，进而有MIC key然后连同一个802.1xdata通过HMAC_MD5算出MIC，STA把MIC和SNounce发给AP。AP收到Snouce后，自己也使用相同的算法，通过SA AA SNounce ANounce计算MIC，如果这个MIC和STA发过来的MIC是一样的，那么就说明两侧的PMK是一样的，不然过后AP就会发出deauth给STA

 

PTK成功后，两侧的PTK Key结构就确定下来了，随后AP会通过EAPOL-KEY把GTK发给STA，AP发一个MIC给STA，STA把KEY解出来，发一个确认信息给AP。

 

WPA和RSN在处理流程还存在下面一些不同：

   基本上就是PTK和GTK何时安装到驱动的时机是不一样以及传输使用的descriptor格式不同。

EAP-AKA给3G、WLAN、互联网提供了统一认证方法的可能。