4. EAP Packet Format

EAP 数据包格式的摘要如下所示。字段从左到右传输。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

Code 字段为一个八位组，标识 EAP 数据包的类型。EAP 代码分配如下：

     Request
     Response
     Success
     Failure

由于 EAP 仅定义了代码 1-4，authenticator 和 peer 都 MUST 静默丢弃带有其他代码的数据包。

Identifier

Identifier 字段为一个八位组，用于帮助将响应与请求相匹配。

Length

Length 字段为两个八位组，以八位组为单位指示 EAP 数据包的长度，包括 Code、Identifier、Length 和 Data 字段。应将在 Length 字段范围之外的八位组视为数据链路层填充，并在接收时 MUST 忽略。Length 字段设置为大于接收到的八位组数量的数据包 MUST 被静默丢弃。

Data

Data 字段由零个或多个八位组组成。Data 字段的格式由 Code 字段决定。

4.1. Request 和 Response

描述

Request 数据包（Code 字段设为 1）由 authenticator 发送给 peer。每个 Request 都有一个 Type 字段，用于指示所请求的内容。应发送进一步的 Request 数据包，直到收到有效的 Response 数据包、可选的尝试计数器过期，或从较低层收到错误指示。

重传的 Request MUST 使用相同的 Identifier 值发送，以区别于新的 Request。data 字段的内容取决于 Request 类型。peer MUST 针对有效的 Request 数据包发送 Response 数据包。Response 只能为了响应有效的 Request 而发送，绝不能基于定时器重传。

如果 peer 收到一个其已经发送过 Response 的有效重复 Request，它 MUST 重新发送其原始 Response，而不重新处理该 Request。Request MUST 按照接收顺序处理，并且 MUST 在处理完当前 Request 之后再检查下一个 Request。

Request 和 Response 数据包格式的摘要如下所示。字段从左到右传输。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1 for Request
   2 for Response

Identifier

Identifier 字段为一个八位组。如果 Request 数据包由于等待 Response 超时而重传，则 Identifier 字段 MUST 保持不变。任何新的 Request（非重传）MUST 改变 Identifier 字段。

Response 的 Identifier 字段 MUST 与当前挂起的 Request 匹配。接收到 Identifier 值与当前挂起的 Request 不匹配的 Response 的 authenticator MUST 静默丢弃该 Response。

为了避免新的 Request 和重传之间的混淆，为每个新 Request 选择的 Identifier 值只需与先前的 Request 不同，而不必在会话中唯一。一种实现方式是从一个初始值开始，并对每个新 Request 递增。建议将第一个 Identifier 初始化为随机数，而不是从零开始，因为这样可以使序列攻击略微困难一些。

由于 Identifier 空间对每个会话是唯一的，authenticator 不限于仅 256 个同时进行的认证会话。类似地，在重新认证时，EAP 会话可能持续很长时间，并且不限于仅 256 次往返。

实现说明：authenticator 负责重传 Request 消息。如果 Request 消息是从其他地方（例如从后端认证服务器）获得的，则 authenticator 需要保存 Request 的副本以便能够重传。peer 负责在以自己的方式处理 Request 之前（包括将其传递给外部方之前）检测并处理重复的 Request 消息。authenticator 还负责在以自己的方式处理 Response 之前（包括将其传递给后端认证服务器进行验证之前）丢弃 Identifier 值不匹配的 Response 消息。由于 authenticator 可能在收到 peer 的 Response 之前就重传，authenticator 可能收到多个 Response，每个都具有匹配的 Identifier。在从 authenticator 收到新的 Request 之前，Identifier 值不会更新，因此 authenticator 将 Response 逐一转发给后端认证服务器。

Length

Length 字段为两个八位组，表示 EAP 数据包的长度，包括 Code、Identifier、Length、Type 和 Type-Data 字段。应将在 Length 字段范围之外的八位组视为数据链路层填充，并在接收时 MUST 忽略。Length 字段设置为大于接收到的八位组数量的数据包 MUST 被静默丢弃。

Type

Type 字段为一个八位组。该字段指示 Request 或 Response 的类型。每个 Request 或 Response EAP MUST 指定单一 Type。本文件第 5 节提供了 Types 的初始规范。

Response 的 Type 字段 MUST 与 Request 的 Type 字段匹配，或者匹配传统的或扩展的 Nak（见第 5.3 节），表示 Request Type 不被 peer 接受。在发送了初始的非 Nak Response 之后，peer MUST NOT 发送 Nak（传统或扩展）以响应 Request。接收到不符合这些要求的 Response 的 EAP 服务器 MUST 静默丢弃它。

Type-Data

Type-Data 字段随 Request 的类型及其相应的 Response 而变化。

4.2. Success 和 Failure

Success 数据包由 authenticator 在 EAP 认证方法（类型 4 或更高）完成后发送给 peer，以指示 peer 已成功通过 authenticator 的认证。authenticator MUST 发送一个 Code 字段设为 3（Success）的 EAP 数据包。如果 authenticator 无法认证 peer（对一个或多个 Request 的 Response 不可接受），则在当前 EAP 方法完成失败后，实现 MUST 发送一个 Code 字段设为 4（Failure）的 EAP 数据包。authenticator 可能希望在发送 Failure 响应之前发出多个 Request，以允许人工输入错误。Success 和 Failure 数据包 MUST NOT 包含额外的数据。

如果给定方法的规范未明确允许该方法在该点结束，则 authenticator EAP MUST NOT 发送 Success 和 Failure 数据包。接收到发送未被明确允许的 Success 或 Failure 数据包的 peer EAP 实现 MUST 静默丢弃它。默认情况下，peer EAP MUST 静默丢弃一个"canned" Success 数据包（在连接打开时立即发送的 Success 数据包）。这确保了一个恶意的 authenticator 无法通过在该 EAP 方法会话结束之前发送 Success 数据包来绕过相互认证。

实现说明：由于 Success 和 Failure 数据包未被确认，authenticator 不会重传它们，并且它们可能丢失。peer 必须考虑到这种情况，如本说明中所述。另请参见第 3.4 节，了解有关处理较低层成功和失败指示的指南。

如第 2.1 节所述，EAP 会话中只允许一种 EAP 认证方法。EAP 方法可以实现结果指示。在 authenticator 向 peer 发送失败结果指示后，无论 peer 的响应如何，它 MUST 随后发送一个 Failure 数据包。在 authenticator 向 peer 发送成功结果指示并收到来自 peer 的成功结果指示后，它 MUST 随后发送一个 Success 数据包。

在 peer 侧，一旦该方法未成功完成（即 authenticator 发送失败结果指示，或 peer 决定不继续进行会话，可能在发送失败结果指示之后），peer MUST 终止会话并向较低层指示失败。peer MUST 静默丢弃 Success 数据包，并且 MAY 静默丢弃 Failure 数据包。因此，Failure 数据包的丢失不一定会导致超时。

在 peer 侧，在双方交换了成功结果指示之后，MUST 静默丢弃 Failure 数据包。如果未收到 EAP Success，peer MAY 推断出 EAP Success 数据包已丢失并且认证已成功完成。

如果 authenticator 尚未发送结果指示并且 peer 愿意继续会话，则 peer 在方法完成后等待 Success 或 Failure 数据包，并且 MUST NOT 静默丢弃它们。在未收到 Success 或 Failure 数据包的情况下，peer SHOULD 终止会话，以避免在丢失的数据包为 EAP Failure 时出现长时间的超时。

如果 peer 尝试通过 authenticator 认证但失败，authenticator MUST 发送 Failure 数据包，并且 MUST NOT 通过发送 Success 数据包来授予访问权限。但是，在提供有限访问（例如访客访问）的情况下，authenticator MAY 省略对 peer 的认证。在这种情况下，authenticator MUST 发送 Success 数据包。

在 peer 成功通过 authenticator 认证但 authenticator 未发送结果指示的情况下，如果 peer 当前未获授权进行网络访问，authenticator MAY 通过发送 Failure 数据包来拒绝访问。

Success 和 Failure 数据包格式的摘要如下所示。字段从左到右传输。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   3 for Success
   4 for Failure

Identifier

Identifier 字段为一个八位组，用于帮助将响应与应答相匹配。Identifier 字段 MUST 与所响应的 Response 数据包的 Identifier 字段匹配。

Length

4.3. 重传行为

由于认证过程通常会涉及用户输入，因此在决定重传策略和认证超时时必须谨慎。默认情况下，在不可靠的较低层上运行 EAP 时，EAP 重传定时器 SHOULD 动态估算。建议最大重传次数为 3-5 次。

在可靠的较低层（例如，EAP over ISAKMP/TCP，如 [PIC] 中）上运行时，authenticator 的重传定时器 SHOULD 设置为无限大，以便在 EAP 层不发生重传。peer 仍可以保持超时值，以避免无限期地等待 Request。

当认证过程需要用户输入时，测量的往返时间可能由用户的响应速度而非网络特性决定，因此动态估算 RTO 可能没有用处。相反，重传定时器 SHOULD 设置为为用户提供足够的响应时间，在某些情况下（例如涉及令牌卡时，见第 5.6 节）需要更长的超时。

为了向 authenticator EAP 提供有关适当超时值的指导，后端认证服务器可以向 authenticator 传达建议（例如通过 RADIUS Session-Timeout 属性）。

为了动态估算 EAP 重传定时器，建议使用 [RFC2988] 中描述的用于估算 SRTT、RTTVAR 和 RTO 的算法，包括使用 Karn 算法，并可能进行以下修改：

[a] 为了避免在分布式系统之间使用固定定时器时可能出现的同步行为，重传定时器使用 RTO 值计算并随机添加介于 -RTOmin/2 和 RTOmin/2 之间的随机值来产生抖动。也可以使用其他计算来产生抖动。这些 MUST 是伪随机的。有关伪随机数生成的讨论，请参见 [RFC1750]。

[b] 当 EAP 在单个链路上传输（而不是在 Internet 上）时，可以使用比 RTOinitial、RTOmin 和 RTOmax 更小的值。建议的值为 RTOinitial=1 秒、RTOmin=200ms、RTOmax=20 秒。

[c] 当 EAP 在单个链路上传输（而不是在 Internet 上）时，估算可以基于每个 authenticator 进行，而不是基于每个会话。这使得重传估算能够最大限度地利用有关较低层行为的信息。

[d] EAP 实现 MAY 在多次降低定时器后清除 SRTT 和 RTTVAR，因为在这种情况下当前的 SRTT 和 RTTVAR 很可能是错误的。一旦清除了 SRTT 和 RTTVAR，应按照 [RFC2988] 中的公式 2.2 使用下一个采样的 RTT 对其进行初始化。