2. 可扩展认证协议 (EAP)

EAP 认证交换过程如下:

[1] 认证器 (authenticator) 发送一个 Request (请求) 来认证对等体 (peer)。

Request 有一个 Type (类型) 字段来指示请求的内容。Request 类型的示例包括 Identity (身份)、MD5-challenge 等。MD5-challenge 类型与 CHAP 认证协议 [RFC1994] 非常接近。通常，认证器会发送一个初始的 Identity Request；但是，初始 Identity Request 不是必需的，可以被绕过。例如，当身份由对等体连接的端口确定时（专线、专用交换机或拨号端口），或者当身份以其他方式获得时（通过呼叫站身份或 MAC 地址、在 MD5-Challenge Response 的 Name 字段中等），身份可能不需要。

[2] 对等体发送一个 Response (响应) 数据包来回复有效的 Request。与 Request 数据包一样，Response 数据包包含一个 Type 字段，该字段对应于 Request 的 Type 字段。

[3] 认证器发送额外的 Request 数据包，对等体用 Response 回复。Request 和 Response 的序列会根据需要继续进行。EAP 是一个"锁步"协议，因此除了初始 Request 之外，在收到有效 Response 之前不能发送新的 Request。认证器负责按照第 4.1 节所述重传请求。在适当次数的重传后，认证器应该 (SHOULD) 结束 EAP 会话。当重传或未能从对等体获得响应时，认证器不得 (MUST NOT) 发送 Success 或 Failure 数据包。

[4] 会话继续进行，直到认证器无法认证对等体（对一个或多个 Request 的不可接受的 Response），在这种情况下，认证器实现必须 (MUST) 传输 EAP Failure (Code 4)。或者，认证会话可以继续进行，直到认证器确定成功认证已发生，在这种情况下，认证器必须 (MUST) 传输 EAP Success (Code 3)。

优点:

o EAP 协议可以支持多种认证机制，而无需预先协商特定机制。

o 网络接入服务器 (NAS) 设备（例如交换机或接入点）不必了解每种认证方法，可以 (MAY) 充当后端认证服务器的透传代理。透传支持是可选的。认证器可以 (MAY) 认证本地对等体，同时充当非本地对等体和它本地未实现的认证方法的透传代理。

o 将认证器与后端认证服务器分离简化了凭据管理和策略决策制定。

缺点:

o 在 PPP 中使用 EAP 需要向 PPP LCP 添加新的认证类型，因此需要修改 PPP 实现才能使用它。它也偏离了先前在 LCP 期间协商特定认证机制的 PPP 认证模型。同样，交换机或接入点实现需要支持 [IEEE-802.1X] 才能使用 EAP。

o 当认证器与后端认证服务器分离时，这会使安全分析复杂化，并且如果需要，会使密钥分发复杂化。

2.1. 序列支持 (Support for Sequences)

EAP 会话可以 (MAY) 使用一系列方法。常见的例子是 Identity 请求后跟单个 EAP 认证方法，如 MD5-Challenge。但是，在 EAP 会话中，对等体和认证器必须 (MUST) 仅使用一种认证方法（Type 4 或更大），之后认证器必须 (MUST) 发送 Success 或 Failure 数据包。

一旦对等体发送了与初始 Request 相同 Type 的 Response，认证器不得 (MUST NOT) 在给定方法的最后一轮完成之前发送不同 Type 的 Request（Notification-Request 除外），并且不得 (MUST NOT) 在初始认证方法完成后发送任何 Type 的附加方法的 Request；接收到此类 Request 的对等体必须 (MUST) 将它们视为无效并静默丢弃它们。因此，不支持身份重新查询 (Identity Requery)。

在发送初始非 Nak Response 之后，对等体不得 (MUST NOT) 发送 Nak（传统或扩展）来回复 Request。由于攻击者可能发送伪造的 EAP Request 数据包，接收到意外 Nak 的认证器应该 (SHOULD) 丢弃它并记录该事件。

不支持在 EAP 会话中使用多种认证方法，因为它们容易受到中间人攻击（参见第 7.4 节）并且与现有实现不兼容。

当使用单个 EAP 认证方法，但在其中运行其他方法（"隧道"方法）时，禁止多种认证方法的规定不适用。此类"隧道"方法在 EAP 中显示为单个认证方法。可以提供向后兼容性，因为不支持"隧道"方法的对等体可以使用 Nak（传统或扩展）回复初始 EAP-Request。为了解决安全漏洞，"隧道"方法必须 (MUST) 支持针对中间人攻击的保护。

2.2. EAP 多路复用模型 (EAP Multiplexing Model)

从概念上讲，EAP 实现由以下组件组成:

[a] 下层 (Lower layer)。下层负责在对等体和认证器之间传输和接收 EAP 帧。EAP 已在各种下层上运行，包括 PPP、有线 IEEE 802 LAN [IEEE-802.1X]、IEEE 802.11 无线 LAN [IEEE-802.11]、UDP（L2TP [RFC2661] 和 IKEv2 [IKEv2]）以及 TCP [PIC]。第 3 节讨论了下层行为。

[b] EAP 层 (EAP layer)。EAP 层通过下层接收和传输 EAP 数据包，实现重复检测和重传，并向 EAP 对等体和认证器层发送和接收 EAP 消息。

[c] EAP 对等体和认证器层 (EAP peer and authenticator layers)。基于 Code 字段，EAP 层将传入的 EAP 数据包解复用到 EAP 对等体和认证器层。通常，给定主机上的 EAP 实现将支持对等体或认证器功能，但主机可以同时充当 EAP 对等体和认证器。在这样的实现中，EAP 对等体和认证器层都将存在。

[d] EAP 方法层 (EAP method layers)。EAP 方法实现认证算法，并通过 EAP 对等体和认证器层接收和传输 EAP 消息。由于 EAP 本身不提供分片支持，这是 EAP 方法的责任，第 5 节将讨论这些方法。

图 1 说明了 EAP 多路复用模型。请注意，不要求实现符合此模型，只要线路上的行为与之一致即可。

         +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
         +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                 +------------>-------------+

图 1: EAP 多路复用模型

在 EAP 中，Code 字段的功能非常类似于 IP 中的协议号。假定 EAP 层根据 Code 字段对传入的 EAP 数据包进行解复用。Code=1 (Request)、3 (Success) 和 4 (Failure) 的接收到的 EAP 数据包由 EAP 层传递到 EAP 对等体层（如果已实现）。Code=2 (Response) 的 EAP 数据包被传递到 EAP 认证器层（如果已实现）。

在 EAP 中，Type 字段的功能非常类似于 UDP 或 TCP 中的端口号。假定 EAP 对等体和认证器层根据传入 EAP 数据包的 Type 对其进行解复用，并仅将它们传递到与该 Type 对应的 EAP 方法。主机上的 EAP 方法实现可以注册从对等体或认证器层或两者接收数据包，具体取决于它支持的角色。

由于 EAP 认证方法可能希望访问 Identity，实现应该 (SHOULD) 使 Identity Request 和 Response 可供认证方法（Type 4 或更大）访问，除了 Identity 方法之外。第 5.1 节讨论了 Identity Type。

Notification Response 仅用作确认对等体收到 Notification Request，而不是它已处理它或向用户显示了消息。不能假定另一种方法可以使用 Notification Request 或 Response 的内容。第 5.2 节讨论了 Notification Type。

Nak (Type 3) 或 Expanded Nak (Type 254) 用于方法协商的目的。对等体使用 Nak Response (Type 3) 或 Expanded Nak Response (Type 254) 响应不可接受 Type 的初始 EAP Request。不能假定另一种方法可以使用 Nak Response(s) 的内容。第 5.3 节讨论了 Nak Type(s)。

Code 为 Success 或 Failure 的 EAP 数据包不包含 Type 字段，不会传递到 EAP 方法。第 4.2 节讨论了 Success 和 Failure。

鉴于这些考虑，Success、Failure、Nak Response(s) 和 Notification Request/Response 消息不得 (MUST NOT) 用于携带要传递到其他 EAP 方法的数据。

2.3. 透传行为 (Pass-Through Behavior)

当作为"透传认证器"操作时，认证器执行第 4.1 节所述的 Code、Identifier 和 Length 字段检查。它将从对等体接收并发往其认证器层的 EAP 数据包转发到后端认证服务器；从后端认证服务器接收并发往对等体的数据包被转发到它。

接收 EAP 数据包的主机只能对其执行以下三项操作之一：对其采取行动、丢弃它或转发它。转发决策通常仅基于对 Code、Identifier 和 Length 字段的检查。透传认证器实现必须 (MUST) 能够将从对等体接收的 Code=2 (Response) 的 EAP 数据包转发到后端认证服务器。它还必须 (MUST) 能够从后端认证服务器接收 EAP 数据包并将 Code=1 (Request)、Code=3 (Success) 和 Code=4 (Failure) 的 EAP 数据包转发到对等体。

除非认证器在本地实现一个或多个支持认证器角色的认证方法，否则 EAP 方法层头字段（Type、Type-Data）不作为转发决策的一部分进行检查。当认证器支持本地认证方法时，它可以 (MAY) 检查 Type 字段以确定是对数据包本身采取行动还是转发它。符合标准的透传认证器实现默认情况下必须 (MUST) 转发任何 Type 的 EAP 数据包。

Code=1 (Request)、Code=3 (Success) 和 Code=4 (Failure) 接收到的 EAP 数据包由 EAP 层解复用并传递到对等体层。因此，除非主机实现 EAP 对等体层，否则这些数据包将被静默丢弃。同样，Code=2 (Response) 接收到的 EAP 数据包由 EAP 层解复用并传递到认证器层。因此，除非主机实现 EAP 认证器层，否则这些数据包将被静默丢弃。本规范未定义"透传对等体"的行为，RADIUS [RFC3579] 和 Diameter [DIAM-EAP] 等 AAA 协议不支持它。

图 2 说明了转发模型。

对等体透传认证器认证服务器

   +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
   |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
   +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
         +-------->--------+           +--------->-------+

图 2: 透传认证器

对于认证器充当透传的会话，它必须 (MUST) 仅根据后端认证服务器发送的 Accept/Reject 指示来确定认证结果；结果不得 (MUST NOT) 由与 Accept/Reject 指示一起发送的 EAP 数据包的内容或缺少此类封装的 EAP 数据包来确定。

2.4. 对等操作 (Peer-to-Peer Operation)

由于 EAP 是对等协议，可以在反向进行独立和同时的认证（取决于下层的能力）。链路的两端可以同时充当认证器和对等体。在这种情况下，两端都必须实现 EAP 认证器和对等体层。此外，两个对等体上的 EAP 方法实现必须支持认证器和对等体功能。

尽管 EAP 支持对等操作，但某些 EAP 实现、方法、AAA 协议和链路层可能不支持这一点。某些 EAP 方法可能支持非对称认证，对等体需要一种类型的凭据，认证器需要另一种类型。支持使用此类方法的对等操作的主机需要配置两种类型的凭据。

例如，EAP-TLS [RFC2716] 是一个客户端-服务器协议，其中通常为客户端和服务器使用不同的证书配置文件。这意味着支持使用 EAP-TLS 进行对等认证的主机需要实现 EAP 对等体和认证器层，在 EAP-TLS 实现中支持对等体和认证器角色，并为每个角色配置适当的证书。

RADIUS/EAP [RFC3579] 和 Diameter EAP [DIAM-EAP] 等 AAA 协议仅支持"透传认证器"操作。如 [RFC3579] 第 2.6.2 节所述，RADIUS 服务器使用 Access-Reject 响应封装 EAP-Request、Success 或 Failure 数据包的 Access-Request。因此不支持"透传对等体"操作。

即使使用支持双向认证和结果指示的方法，几个考虑因素可能决定需要两个 EAP 认证（每个方向一个）。这些包括:

[1] 下层中双向会话密钥派生的支持。诸如 IEEE 802.11 之类的下层可能仅支持瞬态会话密钥的单向派生和传输。例如，[IEEE-802.11i] 中定义的组密钥握手是单向的，因为在 IEEE 802.11 基础设施模式中，只有接入点 (AP) 发送多播/广播流量。在 IEEE 802.11 ad hoc 模式中，任一对等体都可以发送多播/广播流量，需要两个单向组密钥交换。由于设计的限制，这也意味着需要在每个方向进行单播密钥派生和 EAP 方法交换。

[2] 下层中打破平局的支持。诸如 IEEE 802.11 ad hoc 之类的下层不支持"打破平局"，其中两个相互发起认证的主机将仅继续进行单个认证。这意味着即使 802.11 支持双向组密钥握手，仍然可能发生两个认证，每个方向一个。

[3] 对等体策略满足。EAP 方法可能支持结果指示，使对等体能够在方法内向 EAP 服务器指示它已成功认证 EAP 服务器，以及使服务器指示它已认证对等体。但是，除非通过 AAA 协议向认证器提供此信息，否则透传认证器将不会知道对等体已接受 EAP 服务器提供的凭据。认证器应该 (SHOULD) 将在 Accept 数据包中接收密钥属性解释为对等体已成功认证服务器的指示。

但是，即使发生了双向认证，在初始 EAP 交换期间，EAP 对等体的访问策略也可能未得到满足。例如，EAP 认证器可能未证明授权同时充当对等体和认证器角色。因此，即使对等体提供了 EAP 服务器已成功向其认证的指示，对等体也可能需要反向的额外认证。