跳到主要内容

5. 初始 EAP 请求/响应类型

5. 初始 EAP 请求/响应类型​

本节定义了在请求/响应交换中使用的初始 EAP 类型集。将来的文档中可能会定义更多类型。Type 字段为一个八位字节，标识 EAP Request 或 Response 数据包的结构。前 3 种类型被视为特殊情况类型。

其余类型定义认证交换。Nak (Type 3) 或 Expanded Nak (Type 254) 仅对 Response 数据包有效，它们不得 (MUST NOT) 在 Request 中发送。

所有 EAP 实现必须 (MUST) 支持本文档中定义的类型 1-4，并且应该 (SHOULD) 支持类型 254。实现可以 (MAY) 支持此处或未来 RFC 中定义的其他类型。

1 Identity 2 Notification 3 Nak (仅响应) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 实验性使用

EAP 方法可以 (MAY) 支持基于共享密钥的认证。如果共享密钥是用户输入的密码短语，实现可以 (MAY) 支持输入带有非 ASCII 字符的密码短语。在这种情况下，应使用适当的 stringprep [RFC3454] 配置文件处理输入，并使用 UTF-8 编码 [RFC2279] 编码为八位字节。[SASLPREP] 中描述了可能的 stringprep 配置文件的初步版本。

5.1. 身份 (Identity)​

描述

Identity Type 用于查询对等体的身份。通常，认证器会将此作为初始 Request 发出。可以 (MAY) 包含可选的可显示消息，以便在期望与用户交互的情况下提示对等体。应该 (SHOULD) 发送 Type 1 (Identity) 的 Response 来响应 Type 1 (Identity) 的 Request。

某些 EAP 实现在 NUL 字符之后将各种选项搭载到 Identity Request 中。默认情况下，EAP 实现不应该 (SHOULD NOT) 假定 Identity Request 或 Response 可以大于 1020 个八位字节。

建议 (RECOMMENDED) Identity Response 主要用于路由目的和选择要使用的 EAP 方法。EAP 方法应该 (SHOULD) 包含用于获取身份的特定于方法的机制，以便它们不必依赖 Identity Response。Identity Request 和 Response 以明文发送，因此攻击者可能窥探身份，甚至修改或欺骗身份交换。为了解决这些威胁，EAP 方法最好包括支持每数据包认证、完整性和重放保护以及机密性的身份交换。Identity Response 可能不是该方法的适当身份；它可能已被截断或混淆以提供隐私，或者可能已被装饰用于路由目的。当对等体配置为仅接受支持受保护身份交换的认证方法时，对等体可以 (MAY) 提供缩写的 Identity Response（例如省略 NAI [RFC2486] 的对等体名称部分）。有关身份保护的进一步讨论，请参见第 7.3 节。

实现说明：对等体可以 (MAY) 通过用户输入获取 Identity。建议认证器在无效 Identity 或认证失败的情况下重试 Identity Request，以允许用户可能的输入错误。建议在终止认证之前至少重试 Identity Request 3 次。Notification Request 可以 (MAY) 用于在传输新的 Identity Request 之前指示无效的认证尝试（可选地，失败可以 (MAY) 在新 Identity Request 本身的消息中指示）。

Type

1

Type-Data

此字段可以 (MAY) 在 Request 中包含可显示消息，包含 UTF-8 编码的 ISO 10646 字符 [RFC2279]。当 Request 包含空值时，仅显示空值之前的字段部分。如果 Identity 未知，则 Identity Response 字段的长度应为零字节。Identity Response 字段不得 (MUST NOT) 以空值终止。在所有情况下，Type-Data 字段的长度都是从 Request/Response 数据包的 Length 字段派生的。

安全声明（参见第 7.2 节）：

认证机制：无 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：不适用 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.2. 通知 (Notification)​

描述

Notification Type 可选地用于从认证器向对等体传达可显示消息。认证器可以 (MAY) 在 EAP 认证方法完成之前，在没有未完成的 Request 时随时向对等体发送 Notification Request。对等体必须 (MUST) 使用 Notification Response 响应 Notification Request，除非 EAP 认证方法规范禁止使用 Notification 消息。在任何情况下，不得 (MUST NOT) 发送 Nak Response 来响应 Notification Request。请注意，Notification Request 的默认最大长度为 1020 个八位字节。默认情况下，这为人类可读消息最多留下 1015 个八位字节。

EAP 方法可以 (MAY) 在其规范中指示在该方法期间不得发送 Notification 消息。在这种情况下，对等体必须 (MUST) 从使用相同 Type 的 Response 回答该 Type 的初始 Request 的点开始静默丢弃 Notification Request。

对等体应该 (SHOULD) 向用户显示此消息，或者如果无法显示则记录它。Notification Type 旨在提供某种必要性质的已确认通知，但它不是错误指示，因此不会改变对等体的状态。示例包括即将到期的密码、接近 0 的 OTP 序列整数、认证失败警告等。在大多数情况下，不应需要 Notification。

Type

2

Type-Data

Request 中的 Type-Data 字段包含长度大于零个八位字节的可显示消息，包含 UTF-8 编码的 ISO 10646 字符 [RFC2279]。消息的长度由 Request 数据包的 Length 字段确定。消息不得 (MUST NOT) 以空值终止。必须 (MUST) 发送 Response 来回复 Type 字段为 2 (Notification) 的 Request。Response 的 Type-Data 字段长度为零个八位字节。Response 应立即发送（与消息的显示或记录方式无关）。

安全声明（参见第 7.2 节）：

认证机制：无 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：不适用 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.3. Nak​

5.3.1. 传统 Nak (Legacy Nak)​

描述

传统 Nak Type 仅在 Response 消息中有效。它作为对所需认证 Type 不可接受的 Request 的回复发送。认证类型编号为 4 及以上。Response 包含对等体所需的一个或多个认证类型。类型零 (0) 用于指示发送方没有可行的替代方案，因此认证器不应该 (SHOULD NOT) 在收到包含零值的 Nak Response 后发送另一个 Request。

由于传统 Nak Type 仅在 Responses 中有效并且功能非常有限，因此不得 (MUST NOT) 将其用作通用错误指示，例如用于错误消息通信或特定于特定 EAP 方法的参数协商。

Code

2 用于 Response。

Identifier

Identifier 字段为一个八位字节，有助于将 Responses 与 Requests 匹配。传统 Nak Response 的 Identifier 字段必须 (MUST) 与作为响应发送的 Request 数据包的 Identifier 字段匹配。

Length

=6

Type

3

Type-Data

当对等体收到不可接受的认证 Type (4-253,255) 的 Request，或者缺少对 Expanded Types 支持的对等体收到 Type 254 的 Request 时，必须 (MUST) 发送 Nak Response (Type 3)。Nak Response (Type 3) 的 Type-Data 字段必须 (MUST) 包含一个或多个八位字节，指示所需的认证类型，每种类型一个八位字节，或者值零 (0) 表示没有建议的替代方案。支持 Expanded Types 并收到不可接受的认证 Type (4-253,255) 的 Request 的对等体可以 (MAY) 在 Nak Response (Type 3) 中包含值 254，以表示对 Expanded 认证 Type 的需求。如果认证器可以满足此偏好，它将使用 Expanded Type Request (Type 254) 响应。

安全声明（参见第 7.2 节）：

认证机制：无 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：不适用 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.3.2. 扩展 Nak (Expanded Nak)​

描述

Expanded Nak Type 仅在 Response 消息中有效。它必须 (MUST) 仅作为对认证 Type 不可接受的 Type 254 (Expanded Type) 的 Request 的回复发送。Expanded Nak Type 本身使用 Expanded Type 格式，Response 包含对等体所需的一个或多个认证类型，全部采用 Expanded Type 格式。类型零 (0) 用于指示发送方没有可行的替代方案。第 5.7 节描述了 Expanded Type 的一般格式。

由于 Expanded Nak Type 仅在 Responses 中有效并且功能非常有限，因此不得 (MUST NOT) 将其用作通用错误指示，例如用于错误消息通信或特定于特定 EAP 方法的参数协商。

Code

2 用于 Response。

Identifier

Identifier 字段为一个八位字节，有助于将 Responses 与 Requests 匹配。Expanded Nak Response 的 Identifier 字段必须 (MUST) 与作为响应发送的 Request 数据包的 Identifier 字段匹配。

Length

=20

Type

254

Vendor-Id

0 (IETF)

Vendor-Type

3 (Nak)

Vendor-Data

Expanded Nak Type 仅在 Request 包含第 5.7 节中定义的 Expanded Type (254) 时发送。Nak Response 的 Vendor-Data 字段必须 (MUST) 包含一个或多个认证类型（4 或更大），全部采用扩展格式，每种类型 8 个八位字节，或者值零 (0)，也采用 Expanded Type 格式，以表示没有建议的替代方案。所需的认证类型可能包括供应商特定和 IETF 类型的混合。例如，指示对 OTP (Type 5) 和 MIT (Vendor-Id=20) Expanded Type 6 的偏好的 Expanded Nak 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

指示没有所需替代方案的 Expanded Nak 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

安全声明（参见第 7.2 节）：

认证机制：无 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：不适用 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.4. MD5-Challenge​

描述

MD5-Challenge Type 类似于 PPP CHAP 协议 [RFC1994]（以 MD5 作为指定算法）。Request 包含对对等体的"挑战"消息。必须 (MUST) 发送 Response 来回复 Request。Response 可以 (MAY) 是 Type 4 (MD5-Challenge)、Nak (Type 3) 或 Expanded Nak (Type 254)。Nak 回复指示对等体所需的认证类型。EAP 对等体和 EAP 服务器实现必须 (MUST) 支持 MD5-Challenge 机制。仅支持透传的认证器必须 (MUST) 允许与能够支持 MD5-Challenge 的后端认证服务器通信，尽管 EAP 认证器实现本身不需要支持 MD5-Challenge。但是，如果 EAP 认证器可以配置为在本地认证对等体（例如，不以透传方式运行），则支持 MD5-Challenge 机制的要求适用。

请注意，MD5-Challenge Type 中 Identifier 字段的使用与 [RFC1994] 中描述的不同。EAP 允许重传 MD5-Challenge Request 数据包，而 [RFC1994] 规定每次发送 Challenge（MD5-Challenge Request 数据包的 CHAP 等价物）时，Identifier 和 Challenge 字段都必须 (MUST) 更改。

注意：[RFC1994] 将共享密钥视为八位字节字符串，并且没有指定如何将其输入系统（或者用户是否处理它）。EAP MD5-Challenge 实现可以 (MAY) 支持输入带有非 ASCII 字符的密码短语。有关应如何处理输入并编码为八位字节的说明，请参见第 5 节。

Type

4

Type-Data

Type-Data 字段的内容总结如下。有关这些字段的使用参考，请参见 PPP Challenge Handshake Authentication Protocol [RFC1994]。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

安全声明（参见第 7.2 节）：

认证机制：密码或预共享密钥 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：否 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.5. 一次性密码 (One-Time Password, OTP)​

描述

一次性密码系统在"一次性密码系统"[RFC2289] 和"OTP 扩展响应"[RFC2243] 中定义。Request 包含 [RFC2289] 中描述的格式的 OTP 挑战。必须 (MUST) 发送 Response 来回复 Request。Response 必须 (MUST) 是 Type 5 (OTP)、Nak (Type 3) 或 Expanded Nak (Type 254)。Nak Response 指示对等体所需的认证类型。EAP OTP 方法仅用于一次性密码系统，不得 (MUST NOT) 用于提供对明文密码的支持。

Type

5

Type-Data

Type-Data 字段在 Request 中包含 OTP"挑战"作为可显示消息。在 Response 中，此字段用于 OTP 字典 [RFC2289] 中的 6 个单词。消息不得 (MUST NOT) 以空值终止。字段的长度从 Request/Reply 数据包的 Length 字段派生。

注意：[RFC2289] 没有指定用户如何输入密钥密码短语，或者如何将密码短语转换为八位字节。EAP OTP 实现可以 (MAY) 支持输入带有非 ASCII 字符的密码短语。有关应如何处理输入并编码为八位字节的说明，请参见第 5 节。

安全声明（参见第 7.2 节）：

认证机制：一次性密码 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：是 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：否 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.6. 通用令牌卡 (Generic Token Card, GTC)​

描述

定义 Generic Token Card Type 用于需要用户输入的各种令牌卡实现。Request 包含可显示消息，Response 包含认证所需的令牌卡信息。通常，这将是用户从令牌卡设备读取并作为 ASCII 文本输入的信息。必须 (MUST) 发送 Response 来回复 Request。Response 必须 (MUST) 是 Type 6 (GTC)、Nak (Type 3) 或 Expanded Nak (Type 254)。Nak Response 指示对等体所需的认证类型。EAP GTC 方法用于支持挑战/响应认证的令牌卡，在没有具有服务器认证的受保护隧道的情况下，不得 (MUST NOT) 用于提供对明文密码的支持。

Type

6

Type-Data

Request 中的 Type-Data 字段包含长度大于零个八位字节的可显示消息。消息的长度由 Request 数据包的 Length 字段确定。消息不得 (MUST NOT) 以空值终止。必须 (MUST) 发送 Response 来回复 Type 字段为 6 (Generic Token Card) 的 Request。Response 包含认证所需的令牌卡数据。数据的长度由 Response 数据包的 Length 字段确定。

EAP GTC 实现可以 (MAY) 支持输入带有非 ASCII 字符的响应。有关应如何处理输入并编码为八位字节的说明，请参见第 5 节。

安全声明（参见第 7.2 节）：

认证机制：硬件令牌 密码套件协商：否 双向认证：否 完整性保护：否 重放保护：否 机密性：否 密钥派生：否 密钥强度：不适用 字典攻击保护：否 快速重新连接：否 加密绑定：不适用 会话独立性：不适用 分片：否 通道绑定：否

5.7. 扩展类型 (Expanded Types)​

描述

由于 EAP 的许多现有用途是供应商特定的，因此 Expanded 方法 Type 可用于允许供应商支持不适合一般用途的自己的 Expanded Types。

Expanded Type 还用于将全局方法 Type 空间扩展到原始 255 个值之外。Vendor-Id 为 0 将原始 255 个可能的 Types 映射到 2^32-1 个可能的 Types 空间。（Type 0 仅在 Nak Response 中用于指示没有可接受的替代方案）。

支持 Expanded 属性的实现必须 (MUST) 等效地对待小于 256 的 EAP Types，无论它们是作为单个八位字节出现，还是作为 Vendor-Id 为 0 的 Expanded Type 中的 32 位 Vendor-Type 出现。未配备解释 Expanded Type 的对等体必须 (MUST) 按照第 5.3.1 节所述发送 Nak，并协商更合适的认证方法。

Expanded Type 格式的摘要如下所示。字段从左到右传输。

    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

254 用于 Expanded Type

Vendor-Id

Vendor-Id 为 3 个八位字节，表示供应商的 SMI 网络管理私有企业代码（按网络字节顺序），由 IANA 分配。Vendor-Id 为零保留供 IETF 用于提供扩展的全局 EAP Type 空间。

Vendor-Type

Vendor-Type 字段为四个八位字节，表示供应商特定的方法 Type。

如果 Vendor-Id 为零，则 Vendor-Type 字段是现有 EAP Types 命名空间的扩展和超集。前 256 个 Types 保留用于与已分配或将来可能分配的单八位字节 EAP Types 的兼容性。因此，0 到 255 的 EAP Types 在语义上是相同的，无论它们是作为单八位字节 EAP Types 出现，还是当 Vendor-Id 为零时作为 Vendor-Types 出现。此规则有一个例外：Expanded Nak 和 Legacy Nak 数据包共享相同的 Type，但由于它们具有不同的格式，因此必须区别对待。

Vendor-Data

Vendor-Data 字段由供应商定义。当存在 Vendor-Id 为零时，Vendor-Data 字段将用于传输 IETF 定义的 Types 的 EAP 方法的内容。

5.8. 实验性 (Experimental)​

描述

Experimental Type 没有固定的格式或内容。它旨在在试验新的 EAP Types 时使用。此 Type 用于实验和测试目的。如 [RFC3692] 中所述，不保证使用此 Type 的对等体之间的互操作性。

Type

255

Type-Data

未定义

最后于 更新