EAP（Extensible Authentication Protocol），可扩展认证协议，是一种普遍使用的支持多种认证方法的认证框架协议，主要用于网络接入认证。该协议一般运行在数据链路层上，即可以直接运行于PPP或者IEEE 802之上，不必依赖于IP。EAP可应用于无线、有线网络中。

         EAP的架构非常灵活，在Authenticator（认证方）和Supplicant（客户端）交互足够多的信息之后，才会决定选择一种具体的认证方法，即允许协商所希望的认证方法。认证方不用支持所有的认证方法，因为EAP架构允许使用一个后端的认证服务器（也就是AAA服务器），此时认证方将在客户端和认证服务器之间透传消息。

图1 EAP典型使用组网（Ethernet）

       该协议支持重传机制，但这需要依赖于底层保证报文的有序传输，EAP不支持乱序报文的接收。协议本身不支持分片与重组，当一些EAP认证方法生成大于MTU（Maximum Transmission Unit，最大传输单元）的数据时，需要认证方法自身支持分片与重组。

EAP认证方法目前大约有40种，IETF的RFC中定义的方法包括：EAP-MD5、 EAP-OTP、EAP-GTC、EAP-TLS、EAP-SIM和EAP-AKA, 还包括一些厂商提供的方法和新的建议。

EAPOL报文的封装格式

EAP在LAN的报文（简称EAPOL）封装格式在IEEE-802.1X协议中定义，其数据包的格式如下所示。

PAE（Port Access Entity）Ethernet Type：2字节，表示协议类型，为0x888E。

Protocol Version：1字节，表示EAPOL帧的发送方所支持的协议版本号。

Type：1字节，表示EAPOL数据帧类型，具体类型如表1所示。

表1 EAPOL数据类型

Length：2字节，表示数据长度，也就是“Packet Body”字段的长度，单位为字节。如果为0，则表示没有后面的数据域。

EAPOL-Start和EAPOL-Logoff报文的Length值都为0。

Packet Body：表示数据内容，根据不同的Type有不同的格式。

eap报文格式

当EAPOL数据帧格式Type域为EAP-Packet时，Packet Body为EAP数据报文，结构如图4所示。

图4 EAP报文格式

Code：一个字节，指明EAP包的类型，共有4种，域值定义如下：

1--------Request

2--------Response

3--------Success

4--------Failure

由于该字段值只定义了1到4，如果EAP报文的该字段为其他值，则应被Authenticator和Supplicant丢弃。

Identifier：一个字节，用于应答报文和请求报文之间进行匹配。

Length：两个字节，EAP包的长度，包含Code、Identifier、Length和Data域，单位为字节。

Data：零个或多个字节，EAP包的内容，由Code类型决定

RFC 3748中定义的Success和Failure类型的包没有Data域，相应的Length域的值为4。但是某些软件的实现中，为了说明认证失败的原因，在Length域后面增加了字段用于说明下线的原因，故Length域的值可能为其他值。

Request和Response类型报文的Data域格式如图所示。

Type：一个字节，标识EAP的认证类型。

Type Data：该字段的内容由Type字段的值决定。

Type字段目前定义的值及其简要说明如下：

Type＝1 ----Identifier（用来询问对端的身份）

Type＝2 ----Notification（非必须的一个消息，传送一些警告消息，比如提示密码将要超期、OTP的顺序号码接近零以及认证失败的警告等）。

Type＝3 ----Nak (Response Only)（Request报文中的认证类型不可接受时回复该类型的报文）

Type＝4 ----MD5-Challenge（类似于CHAP中的MD5-Challenge，使用MD5算法）

Type＝5 ----One-Time Password (OTP)（一种密码交互的方式）

Type＝6 ----Generic Token Card（通用令牌卡类型，适用于各种需要用户输入信息的令牌卡的实现）

Type＝254 ----Expanded Types（供厂商支持自己的扩展类型）

Type＝255 ----Experimental use（在实验新的类型时使用）

每种Type对应的Type Data字段这里不作详细描述，有兴趣的读者请查阅RFC 3748相关章节。

 EAP认证过程

EAP过程由认证方发起，而认证协议一般都是由客户端发起，为了在特定的认证协议上支持EAP过程，认证协议需要增加一个或多个的附加报文来满足条件。如以太网上的认证通常情况下是以客户端发送EAPOL报文开始的。

EAP的典型过程如下：

1、Authenticator发送请求报文EAP-Request给Supplicant（客户端），表明EAP认证开始。该请求由一个字段标明需要请求的数据是什么。这个字段包含Identity（询问对端的身份）, MD5-challenge（MD5挑战字）等。上述发送EAP-Request的步骤在某些情况下也可省去，比如在有线网络中，Authenticator（有时也称为NAS）已经根据客户端连接的端口识别用户身份，或者通过MAC地址，IMSI卡等识别用户身份的情况下。

2、Supplicant针对Authenticator发过来的请求回应一个响应消息EAP-Response，该消息包含了请求消息中请求的字段信息，如身份识别信息。

3、Authenticator继续发送EAP-Request消息，消息中包含具体EAP Type及其协议数据，Supplicant对此做出响应。根据EAP Method的不同，此步骤可能会交互多次。

EAP交互过程是Supplicant与Authenticator一来一往的过程，每次只能处理一个EAP报文，在收到响应之前不能发送新的请求，即锁步机制（Lockstep）。因此Authenticator要负责请求消息的重传。如果重传一定次数后都没有收到应答消息，这次的EAP过程就要被终结。重传后收到应答消息或者一直没有收到应答消息，Authenticator都不发送成功或者失败消息。

4、交互多次之后，会出现两种情形：Authenticator不能确认Supplicant的接入权限，此时必须发送EAP-Failure，终结此次的EAP过程；或者确认接入权限，此时必须发送EAP-Success消息。

Authenticator也可以作为Pass Through设备，透传EAP报文。这种情形下Authenticator检查EAP的Code，Id及Length并将报文转发出去。Authenticator需要将EAP Code为2（Response）的报文转给后端的认证服务器，将EAP Code=1（Request），3（Success），4（Failure）的报文转给Supplicant。在这个处理过程中除非Pass Through Authenticator实现了某种EAP Methods，一般是只将消息转发，并不去检查EAP Methods Layer的的消息头（即EAP Type）。