3. Lower Layer Behavior

3.1. 下层要求

EAP 对下层做如下假设：

[1] 不可靠传输。在 EAP 中，认证者重传尚未收到 Response 的 Request，因此 EAP 不假定下层是可靠的。由于 EAP 定义了自己的重传行为，当 EAP 在可靠下层上运行时，在下层和 EAP 层都发生重传是可能的（尽管不可取）。

请注意，EAP Success 和 Failure 包不会被重传。如果没有可靠的下层，并且存在不可忽略的错误率，这些包可能会丢失，从而导致超时。因此，实现如第 4.2 节所述提高其抵御 EAP Success 或 Failure 包丢失的能力是可取的。

[2] 下层错误检测。虽然 EAP 不假定下层是可靠的，但它确实依赖于下层错误检测（例如 CRC、Checksum、MIC 等）。EAP 方法可能不包含 MIC，或者即使包含，也可能不是对 EAP 包中的所有字段（例如 Code、Identifier、Length 或 Type 字段）进行计算。因此，如果没有下层错误检测，未被检测到的错误可能会潜入 EAP 层或 EAP 方法层头字段，从而导致认证失败。

例如，EAP TLS [RFC2716] 仅对 Type-Data 字段计算其 MIC，并将 MIC 验证失败视为致命错误。如果没有下层错误检测，此方法以及类似的方法将无法可靠地运行。

[3] 下层安全。EAP 不要求下层提供诸如逐包机密性、认证、完整性和重放保护等安全服务。但是，在提供这些安全服务的情况下，支持密钥推导（见第 7.2.1 节）的 EAP 方法可用于提供动态密钥材料。这使得可以将 EAP 认证与后续数据绑定，并防止数据被修改、欺骗或重放。详见第 7.1 节。

[4] 最小 MTU。EAP 能够在提供 1020 字节或更大的 EAP MTU 大小的下层上运行。

EAP 不支持路径 MTU 发现，并且分片和重组不受 EAP 支持，本规范中定义的方法也不支持：Identity (1)、Notification (2)、Nak Response (3)、MD5-Challenge (4)、One Time Password (5)、Generic Token Card (6) 和 expanded Nak Response (254) 类型。

通常，EAP 对端从下层获取有关 EAP MTU 的信息，并将 EAP 帧大小设置为适当的值。在认证者以透传模式运行的情况下，认证服务器没有直接方式确定 EAP MTU，因此依赖于认证者通过诸如 Framed-MTU 属性之类的方式向其提供此信息，如 [RFC3579] 第 2.4 节所述。

虽然诸如 EAP-TLS [RFC2716] 之类的方法支持分片和重组，但最初设计用于 PPP 内的 EAP 方法（其中控制帧保证 1500 字节的 MTU，见 [RFC1661] 第 6.1 节）可能缺少分片和重组功能。

在没有其他信息的情况下，EAP 方法可以假定最小 EAP MTU 为 1020 字节。如果 EAP 方法的负载可能大于此最小 EAP MTU，则 SHOULD 包含对分片和重组的支持。

EAP 是一个"锁步"协议，这意味着在处理分片和重组时存在一定的低效率。因此，如果下层支持分片和重组（例如 EAP 通过 IP 传输时），则分片和重组发生在下层而不是 EAP 中可能是更可取的。这可以通过向 EAP 提供一个人为较大的 EAP MTU 来实现，从而使分片和重组在下层内处理。

[5] 可能的重复。在可靠下层的情况下，它将向 EAP 层提供非重复的包流。然而，虽然希望下层提供非重复，但这并不是一项要求。Identifier 字段为对端和认证者都提供了检测重复的能力。

[6] 排序保证。EAP 不要求 Identifier 单调递增，因此依赖于下层的排序保证以正确运行。EAP 最初被定义为在 PPP 上运行，[RFC1661] 第 1 节有一个排序要求：

"点对点协议设计用于在两个对端之间传输包的简单链路。这些链路提供全双工同时双向操作，并假定按序投递包。"

EAP 的下层传输 MUST 在给定优先级级别的源和目的之间保持排序（[IEEE-802] 提供的排序保证）。

如果发生重排序，通常会导致 EAP 认证失败，从而导致 EAP 认证被重新运行。因此，在可能发生重排序的环境中，预计 EAP 认证失败会很常见。建议仅在提供排序保证的下层上运行 EAP；在原始 IP 或 UDP 传输上运行 EAP 是 NOT RECOMMENDED。将 EAP 封装在 RADIUS [RFC3579] 中满足排序要求，因为 RADIUS 是一个按序投递包的"锁步"协议。

3.2. EAP 在 PPP 中的使用

为了在点对点链路上建立通信，PPP 链路的每一端首先发送 LCP 包以在链路建立阶段配置数据链路。在链路建立之后，PPP 在进入网络层协议阶段之前提供一个可选的认证阶段。

默认情况下，认证不是强制性的。如果需要对链路进行认证，实现 MUST 在链路建立阶段指定认证协议配置选项。

如果在认证阶段已确定对端的身份，服务器可以在后续网络层协商的选项选择中使用该身份。

在 PPP 内实现时，EAP 不在 PPP 链路控制阶段选择特定的认证机制，而是将其推迟到认证阶段。这使认证者能够在确定特定认证机制之前请求更多信息。这也允许使用"后端"服务器，该服务器实际实现各种机制，而 PPP 认证者仅仅透传认证交换。PPP 链路建立和认证阶段，以及认证协议配置选项，在点对点协议（PPP）[RFC1661] 中定义。

3.2.1. PPP 配置选项格式

用于协商 EAP 的 PPP 认证协议配置选项格式概要如下。字段从左向右传输。

恰好一个 EAP 包被封装在 PPP 数据链路层帧的 Information 字段中，其中协议字段指示类型 hex C227（PPP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Authentication Protocol

用于可扩展认证协议（EAP）的 C227（十六进制）

3.3. EAP 在 IEEE 802 中的使用

EAP 在 IEEE 802 上的封装在 [IEEE-802.1X] 中定义。IEEE 802 对 EAP 的封装不涉及 PPP，并且 IEEE 802.1X 不包含对链路或网络层协商的支持。因此，在 IEEE 802.1X 内，无法协商非 EAP 认证机制，例如 PAP 或 CHAP [RFC1994]。

3.4. 下层指示

下层指示的可靠性和安全性取决于下层。由于 EAP 与媒体无关，在处理 EAP 消息时不考虑下层安全的存在与否。

为了提高可靠性，如果对端收到如第 7.2 节定义的 lower layer success 指示，它 MAY 得出结论：一个 Success 包已丢失，并表现得好像它实际收到了 Success 包。这包括如第 4.2 节所述在某些情况下选择忽略该 Success。

关于 PPP、IEEE 802 有线网络和 IEEE 802.11 无线局域网中下层指示的一些可靠性和安全性问题的讨论，可在安全考虑，第 7.12 节中找到。

EAP 认证完成后，对端通常将经由认证者收发数据。期望提供保证：正在收发数据的实体与成功完成 EAP 认证的实体是同一个。为了实现这一点，下层有必要提供逐包完整性、认证和重放保护，并将这些逐包服务绑定到 EAP 认证期间推导出的密钥。否则，后续数据流量可能会被修改、欺骗或重放。

在下层密码套件的密钥材料本身由 EAP 提供的情况下，密码套件协商和密钥激活由下层控制。在 PPP 中，密码套件在 ECP 内协商，因此在 ECP 完成之前不可能使用从 EAP 认证推导出的密钥。因此，初始 EAP 交换无法受到 PPP 密码套件的保护，尽管 EAP 重新认证可以受到保护。

在 IEEE 802 媒体中，初始密钥激活通常也在 EAP 认证完成之后发生。因此，初始 EAP 交换通常无法受到下层密码套件的保护，尽管 EAP 重新认证或预认证交换可以受到保护。