跳到主要内容

5. Initial EAP Request/Response Types

5. Initial EAP Request/Response Types​

为确定使用的认证方法，在认证开始时会发送 EAP Request/Response 包。本规范定义了对所有 EAP 实现都通用的初始类型：Identity、Notification、Nak、MD5-Challenge、One-Time Password、Generic Token Card 和 Expanded Nak。其余的 EAP 类型在 EAP 方法文档中定义。所有 EAP 实现 MUST 支持 Identity、Nak、MD5-Challenge、One-Time Password、Generic Token Card 和 Expanded Nak。

EAP 方法文档中 SHOULD 指明方法是否支持分片（fragmentation）、密钥推导（key derivation）、相互认证（mutual authentication）和结果指示（result indication）。这些属性在第 7.5 节中有更详细的描述。

5.1. Identity​

5.1.1. 概述​

Description

认证开始时，认证者 MAY 向对端发送 EAP-Request 包的 Identity，要求对端发送对 EAP-Request Identity 的 Response。除非对端已经通过其他方式（例如，拨号用户的呼叫者 ID）知晓其标识，否则对端 SHOULD 以包含对端网络访问标识符（NAI）[RFC2486] 的 EAP-Response Identity 包作为回应。在某些环境中，认证者 MAY 使用 NAI 的域部分来路由认证请求（例如，在 RADIUS 代理 [RFC2865] 中）。NAI 的其他用途在 [RFC2486] 中进行了讨论。

如果认证者没有通过发送 EAP-Request Identity 来启动认证，对端 MAY 在收到首个 EAP-Request 后发送包含其对 NAI 的响应的 EAP-Response Identity。如果在认证开始时需要立即认证对端，且对端身份并不重要，则认证者 MAY 绕过 EAP-Request Identity，直接发送另一种类型的 EAP-Request（例如 MD5-Challenge）。

Type

1

Type-Data

Type-Data 字段 MAY 包含一个由显示给用户、提示其输入的文本组成的数据块。该文本 MUST 以 UTF-8 编码的 ISO 10646 字符 [ISO.10646] 表示。认证者 SHOULD 在接收到来自对端的 EAP-Response 后立即发送下一个 EAP-Request；类型 1 的 EAP-Response 包 SHOULD NOT 导致重复发送 EAP-Request Identity。

在实现中，对端和认证者实现 SHOULD 使 Identity Request/Response 对认证方法可见，以便方法在需要时能够获取身份（例如，用于 tunneled 方法）。

5.1.2. 身份管理​

在某些环境中，对端身份信息的不可用或错误的呈现（例如，使用 NAI 的格式，但未包含足够的信息以在两个对等方之间唯一标识用户）可能导致认证失败。在 EAP 部署中，身份管理问题包括身份选择和身份保护。

身份选择

在链路建立时，对端不知道认证者的能力，并且在发起认证时 MAY 使用默认身份。在基于证书的方法中，所使用的证书通常会揭示对端的身份。在 EAP-TLS [RFC2716]、EAP-TTLS [EAP-TTLS] 和 PEAP [PEAP] 等方法中，所使用的证书、用户名或匿名身份 MAY 在每次认证尝试中不同。一旦认证者在对端进行认证，它 MAY 提供关于对端应使用的用户名或证书的指导（例如，在隧道内）。这可以用作在初始身份协商失败后的第二次认证尝试中使用的身份。

身份保护

在 EAP 认证完成之前，对端身份 MAY 被暴露给第三方。为了防止这种暴露，EAP 方法 MAY 支持身份保护（例如，通过加密或匿名标识）。在 EAP-TLS [RFC2716] 中，在隧道内可以提供身份，从而保护其免受被动窃听。在 EAP-TTLS [EAP-TTLS] 和 PEAP [PEAP] 中，使用匿名身份进行初始握手，并且真实身份在隧道内提供。

5.2. Notification​

Description

一个 EAP-Request 或 EAP-Response 包，其值类型为 Notification，用于 convey 一个人类可读的消息。对端 MAY 显示此消息给用户，或者 MAY 将其记录并/或将其呈现给管理员。认证者 MAY 发送通知以通知用户相关内容（例如，"您即将被断开连接"）。对端 SHOULD 以 EAP-Response 包回应，其值为 Notification，并且 MAY 选择不显示该消息（或仅显示其中的一部分）。然而，该消息 SHOULD 以 UTF-8 编码的 ISO 10646 字符 [ISO.10646] 提供。

如果 Notification 请求在认证完成之前发送，则对端 SHOULD 发送一个 Notification 响应，即使它选择不显示该消息。在 EAP 认证过程完成之后发送的通知 MAY 被对端忽略，并且绝对 MUST NOT 被用于承载数据 destined 给另一个 EAP 方法。

Type

2

Type-Data

用于显示给用户的文本消息，采用 UTF-8 编码的 ISO 10646 字符 [ISO.10646]。

5.3. Nak​

5.3.1. Legacy Nak​

Description

对端发送一个值为 Nak 的 EAP-Response 包，以向认证者指示对最初的 EAP-Request 不赞成。NAK 仅在应答一个 EAP-Request 且已发送的初始响应不是 Nak 时发送，并且 SHOULD 仅出现在认证开始附近。通常，Nak 仅在认证者请求对端不支持的认证类型时发送，但也可能在认证者请求对端支持的认证类型但某些配置细节不可接受时发送（例如，对端支持该方法，但 NAS 无法提供该方法所需的服务质量）。在收到 Nak 时，认证者 MAY 通过发送对端在 Nak 中建议的认证类型，或发送另一个 EAP-Request 来响应。EAP 方法文档 MAY 指明方法是否可以协商（通过 Nak）或它是否为强制性的（即在认证开始时必须实现）。

请注意，Nak 是 EAP 的一种 legacy 特性，其扩展能力有限。新的认证方法 SHOULD 使用 Expanded Nak（第 5.3.2 节），因为 Nak 不能用于表示对 Expanded Type（第 5.3.2 节）的反对。此外，某些 EAP 方法被设计为协商而不是使用 Nak（例如，在 tunneled 方法内）。因此，建议在可行的情况下使用 Expanded Nak。

Type

3

Type-Data

在传统的 Nak 中，Type-Data 字段是一个或多个八位组，指示对端愿意在其初始 Response 中使用的认证类型。例如，如果对端接收到 MD5-Challenge（Type 4）请求但支持 One-Time Password（Type 5）和 Generic Token Card（Type 6），它会以包含值为 5 和 6 的 Type-Data 字段的 Nak 作为回应。

5.3.2. Expanded Nak​

Description

Expanded Nak 用于协商 EAP 方法类型。它类似于 Nak，但使用 Expanded Type 格式（见第 5.3.2 节）。Expanded Nak 可以表示对传统类型和 Expanded 类型的反対。

Type

254

Type-Data

对于 Expanded Nak，Type-Data 字段以 Vendor-Id 和 Vendor-Type 开始（见第 5.3.2 节）。由于 Expanded Nak 用于协商，因此 Vendor-Type 字段用于指示对端愿意使用的认证方法类型（传统或 Expanded）。Vendor-Id 字段用于指示厂商。例如，如果请求了一个 Expanded Type，但对端更愿意使用另一种方法，则 Expanded Nak 的 Vendor-Id 和 Vendor-Type 应指示对端首选的方法。

5.4. MD5-Challenge​

5.4.1. 概述​

Description

MD5-Challenge 类型对应于 PPP CHAP 协议 [RFC1994]，并在 EAP 中提供类似于 CHAP 的认证。MD5-Challenge 使用带有共享密钥的 MD5 哈希函数 [MD5] 进行认证。MD5-Challenge 是最广泛部署的 EAP 方法，并且在许多现有的无线接入点中实现。MD5-Challenge 提供了在所共享密钥上的相互认证，但不支持密钥推导或隧道。MD5-Challenge 不提供身份保护。MD5-Challenge 容易受到字典攻击。

MD5-Challenge 的具体实现见 [RFC1994] 第 5 节。在 EAP 中，MD5-Challenge 包的计算方式与 CHAP 类似，主要区别在于 Value-Size 和 Response 字段的编码。在 EAP 中，Value-Size 作为 Value 字段的一部分传输，而不是作为单独的字段。

Type

4

Type-Data

对于 EAP MD5-Challenge，Type-Data 字段包含 Value-Size、Value 和 Name 字段，格式如下。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Value-Size   |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value-Size

一个字节，用于指示 Value 字段的长度（以八位组为单位）。

Value

该字段包含哈希值或挑战值，长度由 Value-Size 字段指示。

Name

该字段包含发送方的主机名或用户名。该字段 MUST 包含 UTF-8 编码的 ISO 10646 字符 [ISO.10646]。

5.4.2. 实现笔记​

MD5-Challenge 包的计算方式如下：

[1] 认证者向对端发送 EAP-Request 包，其中 Type 字段设为 4（MD5-Challenge），并且 Type-Data 字段包含一个挑战值。

[2] 在对端，计算 MD5 哈希值，使用共享密钥、对端 Identifier、挑战值以及 Name 字段作为输入。对端以包含哈希值的 EAP-Response 包回应。

[3] 认证者验证哈希值，如果哈希值匹配，则认证者对端成功。

5.5. 一次性密码 (OTP)​

Description

One Time Password 类型对应于在 [RFC2289] 中定义的一次性密码系统。OTP 类型允许使用一次性密码进行认证，其中每个密码仅使用一次。这种方法提供了针对重放攻击的保护，因为每次认证尝试都使用不同的密码。OTP 不提供相互认证或密钥推导。

Type

5

Type-Data

对于 OTP 类型，Type-Data 字段包含由显示给用户、提示其输入的文本组成的数据块，后跟一个空格，然后是一次性密码。该文本 SHOULD 以 UTF-8 编码的 ISO 10646 字符 [ISO.10646] 表示。该字段的具体格式在 [RFC2289] 中描述。

5.6. 通用令牌卡 (GTC)​

Description

Generic Token Card 类型用于支持各种令牌卡实现。GTC 类型允许认证者向对端发送一个挑战，然后由对端使用其令牌卡计算响应。GTC 不指定令牌卡实现的细节；相反，它支持将来自外部认证服务器的挑战/响应传递给对端。GTC 不提供相互认证或密钥推导。

Type

6

Type-Data

对于 GTC 类型，Type-Data 字段包含由显示给用户、提示其输入的文本组成的数据块，后跟一个空格，然后是由令牌卡生成的值。该文本 SHOULD 以 UTF-8 编码的 ISO 10646 字符 [ISO.10646] 表示。

5.7. 扩展类型（Expanded Types）​

描述

由于 EAP 现有的许多用途都是特定于厂商的，扩展方法类型（Expanded Type）可用于允许厂商支持其自身不适合通用用途的扩展类型。

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

支持扩展属性的实现 MUST 将小于 256 的 EAP 类型同等对待，无论它们是作为单个八位组出现，还是作为 Vendor-Id 为 0 的扩展类型中的 32 位 Vendor-Type 出现。不具备解释扩展类型能力的对等方 MUST 按照第 5.3.1 节发送 Nak，并协商更合适的认证方法。

扩展类型格式的摘要如下所示。字段从左到右传输。

    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      |   Vendor-Id (cont)            | Vendor-Type...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor-Type (cont)                 |  Vendor-Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

254，表示扩展类型（Expanded Type）

Vendor-Id

Vendor-Id 为 3 个八位组，表示由 IANA 分配的厂商的 SMI 网络管理私有企业代码（SMI Network Management Private Enterprise Code），以网络字节序表示。Vendor-Id 为零保留供 IETF 使用，以提供扩展的全局 EAP 类型空间。

Vendor-Type

Vendor-Type 字段为四个八位组，表示厂商特定的方法类型。

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

Vendor-Data

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

5.8. 实验性（Experimental）​

描述

实验性类型（Experimental Type）没有固定的格式或内容。它旨在用于试验新的 EAP 类型。该类型用于实验和测试目的。如 [RFC3692] 所述，对于使用该类型的对等方之间的互操作性不作任何保证。

Type

255

Type-Data

未定义（Undefined）