4. EAP 数据包格式
4. EAP 数据包格式
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 (代码)
Code 字段为一个八位字节，标识 EAP 数据包的类型。EAP 代码分配如下：
1 Request (请求) 2 Response (响应) 3 Success (成功) 4 Failure (失败)
由于 EAP 仅定义代码 1-4，认证器和对等体必须 (MUST) 静默丢弃具有其他代码的 EAP 数据包。
Identifier (标识符)
Identifier 字段为一个八位字节，有助于将响应与请求匹配。
Length (长度)
Length 字段为两个八位字节，以八位字节为单位指示 EAP 数据包的长度，包括 Code、Identifier、Length 和 Data 字段。Length 字段范围之外的八位字节应被视为数据链路层填充，并且必须 (MUST) 在接收时被忽略。Length 字段设置为大于接收的八位字节数的值的消息必须 (MUST) 被静默丢弃。
Data (数据)
Data 字段为零个或多个八位字节。Data 字段的格式由 Code 字段决定。
4.1. 请求和响应 (Request and Response)
描述
Request 数据包（Code 字段设置为 1）由认证器发送给对等体。每个 Request 都有一个 Type 字段，用于指示正在请求什么。必须 (MUST) 发送额外的 Request 数据包，直到收到有效的 Response 数据包、可选的重试计数器到期或收到下层故障指示。
重传的 Requests 必须 (MUST) 使用相同的 Identifier 值发送，以便将它们与新的 Requests 区分开来。data 字段的内容取决于 Request Type。对等体必须 (MUST) 发送 Response 数据包来回复有效的 Request 数据包。Responses 必须 (MUST) 仅作为对有效 Request 的回复发送，并且永远不要根据计时器重传。
如果对等体收到它已发送 Response 的有效重复 Request，它必须 (MUST) 重新发送其原始 Response，而不重新处理 Request。Requests 必须 (MUST) 按照接收的顺序进行处理，并且必须 (MUST) 处理到完成后才能检查下一个 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 (代码)
1 用于 Request 2 用于 Response
Identifier (标识符)
Identifier 字段为一个八位字节。如果由于等待 Response 时超时而重传 Request 数据包，则 Identifier 字段必须 (MUST) 相同。任何新的（非重传）Requests 必须 (MUST) 修改 Identifier 字段。
Response 的 Identifier 字段必须 (MUST) 与当前未完成的 Request 的 Identifier 字段匹配。认证器收到 Identifier 值与当前未完成的 Request 不匹配的 Response 必须 (MUST) 静默丢弃该 Response。
为了避免新 Requests 和重传之间的混淆，为每个新 Request 选择的 Identifier 值只需与前一个 Request 不同，但不需要在会话中唯一。实现此目的的一种方法是从初始值开始 Identifier，并为每个新 Request 递增它。建议使用随机数初始化第一个 Identifier 而不是从零开始，因为这使序列攻击变得更加困难。
由于 Identifier 空间对每个会话都是唯一的，认证器不限于仅 256 个同时认证会话。同样，通过重新认证，EAP 会话可能会持续很长一段时间，并且不限于仅 256 个往返。
实现说明：认证器负责重传 Request 消息。如果从其他地方获取 Request 消息（例如从后端认证服务器），则认证器需要保存 Request 的副本以实现此目的。对等体负责在以任何方式处理重复的 Request 消息之前检测和处理它们，包括将它们传递给外部方。认证器还负责在以任何方式对 Identifier 值不匹配的 Response 消息采取行动之前丢弃它们，包括将它们传递给后端认证服务器进行验证。由于认证器可以在从对等体收到 Response 之前重传，认证器可以接收多个 Responses，每个都具有匹配的 Identifier。在认证器收到新的 Request 之前，Identifier 值不会更新，因此认证器一次一个地将 Responses 转发到后端认证服务器。
Length (长度)
Length 字段为两个八位字节，指示 EAP 数据包的长度，包括 Code、Identifier、Length、Type 和 Type-Data 字段。Length 字段范围之外的八位字节应被视为数据链路层填充，并且必须 (MUST) 在接收时被忽略。Length 字段设置为大于接收的八位字节数的值的消息必须 (MUST) 被静默丢弃。
Type (类型)
Type 字段为一个八位字节。此字段指示 Request 或 Response 的类型。必须 (MUST) 为每个 EAP Request 或 Response 指定单个 Type。Types 的初始规范在本文档的第 5 节中。
Response 的 Type 字段必须 (MUST) 与 Request 的 Type 字段匹配，或者对应于传统或扩展 Nak（参见第 5.3 节），指示 Request Type 对对等体不可接受。对等体不得 (MUST NOT) 在发送初始非 Nak Response 后发送 Nak（传统或扩展）来响应 Request。EAP 服务器收到不符合这些要求的 Response 必须 (MUST) 静默丢弃它。
Type-Data
Type-Data 字段随 Request 的 Type 和相关 Response 而变化。
4.2. 成功和失败 (Success and Failure)
Success 数据包由认证器在 EAP 认证方法（Type 4 或更大）完成后发送给对等体，以指示对等体已成功向认证器认证。认证器必须 (MUST) 传输 Code 字段设置为 3 (Success) 的 EAP 数据包。如果认证器无法认证对等体（对一个或多个 Requests 的不可接受的 Responses），则在正在进行的 EAP 方法未成功完成后，实现必须 (MUST) 传输 Code 字段设置为 4 (Failure) 的 EAP 数据包。认证器可以 (MAY) 希望在发送 Failure 响应之前发出多个 Requests，以允许人为的输入错误。Success 和 Failure 数据包不得 (MUST NOT) 包含额外的数据。
如果给定方法的规范未明确允许方法在该点完成，则 EAP 认证器不得 (MUST NOT) 发送 Success 和 Failure 数据包。对等体 EAP 实现收到不明确允许发送的 Success 或 Failure 数据包必须 (MUST) 静默丢弃它。默认情况下，EAP 对等体必须 (MUST) 静默丢弃"罐装"Success 数据包（连接后立即发送的 Success 数据包）。这确保了恶意认证器无法通过在 EAP 方法会话结束之前发送 Success 数据包来绕过相互认证。
实现说明：由于 Success 和 Failure 数据包不被确认，它们不会被认证器重传，并且可能会丢失。如本说明中所述，对等体必须 (MUST) 允许这种情况。另请参见第 3.4 节，了解有关处理下层成功和失败指示的指导。
如第 2.1 节所述，EAP 会话中仅允许单个 EAP 认证方法。EAP 方法可以实现结果指示。认证器向对等体发送失败结果指示后，无论对等体的响应如何，它必须 (MUST) 随后发送 Failure 数据包。认证器向对等体发送成功结果指示并从对等体收到成功结果指示后，它必须 (MUST) 随后发送 Success 数据包。
在对等体上，一旦方法未成功完成（即，认证器发送失败结果指示，或对等体决定不想继续会话，可能在发送失败结果指示之后），对等体必须 (MUST) 终止会话并向下层指示失败。对等体必须 (MUST) 静默丢弃 Success 数据包，并且可以 (MAY) 静默丢弃 Failure 数据包。因此，Failure 数据包的丢失不需要导致超时。
在对等体上，在双方交换成功结果指示后，Failure 数据包必须 (MUST) 被静默丢弃。如果未收到 EAP Success，对等体可以 (MAY) 得出 EAP Success 数据包已丢失且认证成功结束的结论。
如果认证器未发送结果指示，并且对等体愿意继续会话，则对等体在方法完成后等待 Success 或 Failure 数据包，并且不得 (MUST NOT) 静默丢弃其中任何一个。如果既未收到 Success 也未收到 Failure 数据包，对等体应该 (SHOULD) 终止会话，以避免在丢失的数据包是 EAP Failure 的情况下冗长的超时。
如果对等体尝试向认证器认证但失败，认证器必须 (MUST) 发送 Failure 数据包，并且不得 (MUST NOT) 通过发送 Success 数据包来授予访问权限。但是，认证器可以 (MAY) 在提供有限访问的情况下（例如访客访问）省略让对等体向其认证。在这种情况下，认证器必须 (MUST) 发送 Success 数据包。
当对等体成功向认证器认证，但认证器未发送结果指示时，如果对等体当前未被授权进行网络访问，认证器可以 (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 (代码)
3 用于 Success 4 用于 Failure
Identifier (标识符)
Identifier 字段为一个八位字节，有助于将回复与 Responses 匹配。Identifier 字段必须 (MUST) 与作为响应发送的 Response 数据包的 Identifier 字段匹配。
Length (长度)
4
4.3. 重传行为 (Retransmission Behavior)
由于认证过程通常涉及用户输入，因此在决定重传策略和认证超时时必须小心。默认情况下，当 EAP 在不可靠的下层上运行时，EAP 重传计时器应该 (SHOULD) 动态估计。建议最多重传 3-5 次。
当在可靠的下层上运行时（例如，EAP over ISAKMP/TCP，如在 [PIC] 中），认证器重传计时器应该 (SHOULD) 设置为无限值，以便在 EAP 层不发生重传。对等体仍可以维护超时值，以避免无限期等待 Request。
当认证过程需要用户输入时，测量的往返时间可能由用户响应性而不是网络特性决定，因此动态 RTO 估计可能没有帮助。相反，重传计时器应该 (SHOULD) 设置为为用户提供足够的响应时间，在某些情况下需要更长的超时，例如涉及令牌卡的情况（参见第 5.6 节）。
为了向 EAP 认证器提供有关适当超时值的指导，后端认证服务器可以向认证器传达提示（例如通过 RADIUS Session-Timeout 属性）。
为了动态估计 EAP 重传计时器，建议 (RECOMMENDED) 使用 [RFC2988] 中描述的 SRTT、RTTVAR 和 RTO 估计算法，包括使用 Karn 算法，但可能进行以下修改：
[a] 为了避免分布式系统中固定计时器可能发生的同步行为，重传计时器通过使用 RTO 值并随机添加在 -RTOmin/2 和 RTOmin/2 之间绘制的值来计算抖动。可以 (MAY) 使用替代计算来创建抖动。这些必须 (MUST) 是伪随机的。有关伪随机数生成的讨论，请参见 [RFC1750]。
[b] 当 EAP 通过单个链路传输时（而不是通过互联网传输），可以 (MAY) 使用较小的 RTOinitial、RTOmin 和 RTOmax 值。建议的值为 RTOinitial=1 秒，RTOmin=200ms，RTOmax=20 秒。
[c] 当 EAP 通过单个链路传输时（而不是通过互联网传输），可以 (MAY) 在每个认证器的基础上进行估计，而不是在每个会话的基础上。这使得重传估计能够最大限度地利用有关链路层行为的信息。
[d] EAP 实现可以 (MAY) 在多次退避计时器后清除 SRTT 和 RTTVAR，因为在这种情况下当前的 SRTT 和 RTTVAR 很可能是错误的。一旦清除了 SRTT 和 RTTVAR，应按照 [RFC2988] 公式 2.2 中所述使用下一个 RTT 样本进行初始化。