2. Extensible Authentication Protocol (EAP)

EAP 认证交换按如下方式进行：

[1] 认证者发送一个 Request 来认证对端。该 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 节所述进行 Request 的重传。在适当的重传次数之后，认证者应当结束 EAP 对话。在重传时，或在未能从对端获得响应时，认证者 MUST NOT 发送 Success 或 Failure 包。

[4] 对话持续进行，直到认证者无法认证对端（对一个或多个 Request 的不可接受的 Response），在这种情况下认证者实现 MUST 发送一个 EAP Failure（Code 4）。或者，认证对话可以一直持续到认证者确定已成功认证为止，在这种情况下认证者 MUST 发送一个 EAP Success（Code 3）。

优点：

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

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

o 认证者与后端认证服务器的分离，简化了凭据管理和策略决策。

缺点：

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

o 在认证者与后端认证服务器分离的情况下，会使安全分析复杂化，并且在需要时进行密钥分发也变得复杂。

2.1. 对序列的支持

一个 EAP 对话 MAY 利用一系列方法。常见的例子是一个 Identity request 后跟一个单一的 EAP 认证方法，如 MD5-Challenge。但是，对端和认证者 MUST 在一个 EAP 对话内仅使用一种认证方法（Type 4 或更大），之后认证者 MUST 发送 Success 或 Failure 包。

一旦对端发送了与初始 Request 相同 Type 的 Response，认证者 MUST NOT 在特定方法的最终轮次完成之前（Notification-Request 除外）发送不同 Type 的 Request，并且 MUST NOT 在初始认证方法完成后发送任何 Type 的额外方法的 Request；收到此类 Request 的对端 MUST 将其视为无效，并静默丢弃。因此，不支持 Identity 重查询。

对端 MUST NOT 在发送了初始非 Nak Response 之后，针对 Request 发送 Nak（传统的或扩展的）。由于伪造的 EAP Request 包可能由攻击者发送，认证者收到意外的 Nak 时 SHOULD 丢弃它并记录该事件。

由于对中间人攻击的脆弱性（见第 7.4 节）以及与现有实现的不兼容性，不支持在一个 EAP 对话中使用多种认证方法。

在仅使用单一 EAP 认证方法，但在该方法内部运行其他方法（"隧道式"方法）的情况下，对多认证方法的禁止不适用。此类"隧道式"方法对 EAP 表现为单一认证方法。由于不支持"隧道式"方法的对端可以用 Nak 回应初始 EAP-Request（传统的或扩展的），因此可以提供向后兼容性。为了解决安全漏洞，"隧道式"方法 MUST 支持对中间人攻击的防护。

2.2. EAP 多路复用模型

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

[a] 下层。下层负责在对端和认证者之间传输和接收 EAP 帧。EAP 已在多种下层上运行，包括 PPP、有线 IEEE 802 局域网 [IEEE-802.1X]、IEEE 802.11 无线局域网 [IEEE-802.11]、UDP（L2TP [RFC2661] 和 IKEv2 [IKEv2]）和 TCP [PIC]。下层行为在第 3 节中讨论。

[b] EAP 层。EAP 层经由下层接收和发送 EAP 包，实现重复检测和重传，并向 EAP 对端层和认证者层投递和接收 EAP 消息。

[c] EAP 对端和认证者层。EAP 层根据 Code 字段，将传入的 EAP 包解复用（demultiplex）到 EAP 对端层和认证者层。通常，给定主机上的 EAP 实现将支持对端或认证者功能之一，但主机也可能同时充当 EAP 对端和认证者。在这样的实现中，EAP 对端层和认证者层都将存在。

[d] EAP 方法层。EAP 方法实现认证算法，并经由 EAP 对端和认证者层收发 EAP 消息。由于 EAP 本身不提供分片支持，这是 EAP 方法的职责，EAP 方法在第 5 节中讨论。

EAP 多路复用模型如下图所示。请注意，只要在线行为（on-the-wire behavior）与此模型一致，就不要求实现符合此模型。

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

Figure 1: EAP Multiplexing Model

在 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 对端层和认证者层根据 Type 对传入的 EAP 包进行解复用，并仅将其投递到对应于该 Type 的 EAP 方法。主机上的 EAP 方法实现可以根据其支持的角色，注册从对端层或认证者层（或两者）接收包。

由于 EAP 认证方法可能希望访问 Identity，除 Identity 方法外，实现 SHOULD 使 Identity Request 和 Response 对认证方法（Type 4 或更大）可访问。Identity 类型在第 5.1 节中讨论。

Notification Response 仅用于确认对端收到了 Notification Request，而不是确认它已处理该消息，或已向用户显示该消息。不能假定 Notification Request 或 Response 的内容可供其他方法使用。Notification 类型在第 5.2 节中讨论。

Nak（Type 3）或 Expanded Nak（Type 254）用于方法协商。对端以 Nak Response（Type 3）或 Expanded Nak Response（Type 254）来回应不可接受 Type 的初始 EAP Request。不能假定 Nak Response(s) 的内容可供其他方法使用。Nak 类型（s）在第 5.3 节中讨论。

Code 为 Success 或 Failure 的 EAP 包不包含 Type 字段，并且不会被投递到 EAP 方法。Success 和 Failure 在第 4.2 节中讨论。

鉴于这些考虑，Success、Failure、Nak Response(s) 和 Notification Request/Response 消息 MUST NOT 被用于承载发送给其他 EAP 方法的数据。

2.3. 透传行为

当作为"透传认证者"运行时，认证者如第 4.1 节所述对 Code、Identifier 和 Length 字段进行检查。它将从对端接收并 destined 到其认证者层的 EAP 包转发给后端认证服务器；从后端认证服务器接收并 destined 到对端的包被转发给它。

接收 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）不作为转发决策的一部分被检查。在认证者支持本地认证方法的情况下，它可以检查 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 所示。

Peer Pass-through Authenticator Authentication Server

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

Figure 2: Pass-through Authenticator

对于认证者充当透传的会话，它 MUST 仅基于后端认证服务器发送的 Accept/Reject 指示来确定认证的结果；结果 MUST NOT 由随 Accept/Reject 指示一起发送的 EAP 包的内容，或缺少此类封装的 EAP 包来确定。

2.4. 对等（Peer-to-Peer）操作

由于 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] 对下层中双向会话密钥 derivation 的支持。诸如 IEEE 802.11 之类的下层可能仅支持单向 derivation 和传输临时会话密钥。例如，[IEEE-802.11i] 中定义的组密钥握手是单向的，因为在 IEEE 802.11 基础设施模式下，只有接入点（AP）发送多播/广播流量。在 IEEE 802.11 自组织（ad hoc）模式下，由于任一端都可以发送多播/广播流量，因此需要两次单向组密钥交换。由于设计的局限性，这也意味着需要在每个方向上进行单播密钥 derivation 和 EAP 方法交换。

[2] 对下层中"平局打破"（tie-breaking）的支持。诸如 IEEE 802.11 自组织之类的下层不支持"平局打破"，即两个相互发起认证的主机只会进行一次认证。这意味着即使 802.11 支持双向组密钥握手，仍然可能发生在每个方向上的两次认证。

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

但是，即使在发生了双向认证的情况下，EAP 对端的访问策略也可能在初始 EAP 交换期间未被满足。例如，EAP 认证者可能未表现出同时在了对端和认证者角色上行事的授权。因此，即使对端提供了它已成功认证 EAP 服务器的指示，对端也可能需要在反向进行额外的认证。