Part1.1 - RFC3748 - EAP

写在前面

穷，没有积分，谁能送我802.1X-2004.pdf 和 802.1X-2010.pdf

本文是翻译文档，尽可能保留原文术语。另外可能会添加翻译者的理(曲)解（示意图 和 实例用例、抓包）。计划是阅读RFC3748 和 RFC4137 之后，再阅读 hostapd/wpa_supplicant 中 EAP, EAPOL, 以及 WSC 的实现。

1. EAP RFC3748, RFC4137
2. EAPOL IEEE802.1X
3. RADIUS RFC2865, RFC3579, RFC4072
4. IEEE802.11
5. WSC2.0.2
6. Hostapd framework
7. each facility of Hostapd includes daemon, eloop, socket, eapol_auth, eap, wpa_auth, wps…

摘要

RFC3748 文档定义 EAP, 翻译为可扩展认证协议。 EAP 是一个支持多种认证方法的认证框架。典型地，EAP 直接运行在 data link layer 之上，例如 PPP, IEEE802, 它不依赖 IP .

EAP 自身能处理 消除重复数据封包 和 重发， 然而它 依赖 底层 保证数据封包的次序。
EAP 本身不支持数据包分片，然而有些 EAP methods 可能支持。

1 Introduction

RFC3748 文档定义 EAP, 翻译为可扩展认证协议。 EAP 是一个支持多种认证方法的认证框架。典型地，EAP 直接运行在 data link layer 之上，例如 PPP, IEEE802, 它不依赖 IP . EAP 自身能处理 消除重复数据封包 和 重发， 然而它 依赖 底层 保证数据封包的次序。EAP 本身不支持数据包分片，然而个别EAP methods 可能支持。

EAP 可能用于专用的链路，也用于 switched circuits, 有线链路 和 无线链路。目前，EAP 实现并使用于 (通过 switched circuits 和 使用PPP 拨号线 连接的) 主机 和 routers。EAP 也实现并运用于 switches 和 AP. 在 Ethernet 和 Wireless 上使用 EAP 描述于 IEEE802.1X (技术名称叫做 EAPOL).

EAP 架构 最显著的优势它很灵活。EAP 用来选择一个特定的认证机制。典型地，这个选择动作发生之前，为了决定要使用的特定 authentication method, authentication 会请求更多信息。常规的，为了支持新的authentication method，需要更新authenticator。与此相比，EAP 允许使用 backend authentication server,
     * backend authentication server 实现丰富的authentication methods
     * 其中authenticator 对一些或所有的 methods/peers 实现透传

在本RFC 文档中，不管authenticator 是否操作与 pass-through 模式，都适用authenticator 的要求。这里说的要求被运用于 authenticator 或者 backend authentication server, 根据EAP authentication 在哪里终结，可以使用 术语 “EAP server” 表示.

1.1. Specification of Requirements

介绍 很通用的词： “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”

1.2. Terminology

术语	描述
Authenticator	链路中发起 EAP 认证的一端. 术语 authenticator 用于 IEEE802.1X, 在本文中具有同样的意义。
peer	链路中 对authenticator 做出响应的一端。在 IEEE-802.1X 中, 也叫做 Supplicant
supplicant	在 IEEE802.1X 中，链路中 对 authenticator 做出响应的一端。 在本文档中，被叫做peer
backend authentication server	为 authenticator 提供 认证服务的实体。典型地, 如果有使用，backend authentication server 为 authenticator 执行 EAP methods. IEEE802.1X 中 也使用该术语
AAA	AAA - Authentication, Authorization, and Accounting. 支持EAP 的 AAA protocols 包含 RADIUS [RFC3579] 和Diameter [DIAM-EAP] 本文中，AAA 和 backend authentication server 可以交换使用
EAP server	终结 （与 peer 运行的） EAP authentication method 的 实体。 在没有使用 backend authentication server 的情况下，EAP server 作为authenticator 的组成部分。 在authenticator 操作于pass-through 模式情况下， EAP server 存在于 backend authentication server.
Successful Authentication	在本文档上下文中，successful authentication 是 一系列EAP messages 交换的结果，该结果表现是 authenticator 决定允许peer 接入，peer 决定使用这个接入。 authentication 的决策典型地涉及了认证和授权两个方面；peer 可能成功地完成认证，但是authenticator 可能出于策略原因拒绝 peer 的接入 。
Message Integrity Check (MIC)	一种用于 数据认证 和 完整性保护 的 密码散列函数 (keyed hash function)

1.3. Applicability (适用性）

EAP 被设计用在IP layer 连接不可用的情形中的网络接入认证。不建议 EAP 用于目的, 例如大块数据传输 。

由于 EAP 不需要 IP 连接，它仅 为 认证协议的可靠地传输 而提供足够支持。

EAP 是一种 lock-step (锁定步进式）协议， 在一个时刻只支持单个 packet. 因此 EAP 无法像 TCP 那样 高效的传输大块数据。

EAP 支持重传，它假定 底层提供 次序保证，所以不支持接收乱序packet.

EAP 不支持 分片 和 重组，EAP authentication methods 对所产生的大于 EAP MTU 的 payloads 要提供分片支持。

一些authentication methods （例如 EAP-TLS）支持分片和重组，而 本文档中定义的 EAP methods 不支持。当EAP packet size 超出 链路的 EAP MTU 时，这些不支持分片和重组的 methods 会出现问题。

尽管许多认证协议是由 client （peer) 发起的， EAP 认证是由 Server(authenticator) 发起的。因此，一个认证算法 为了运行在EAP之上，它需要一两个额外的message。

在基于证书认证的案例中，由于certificate chains 需要分片，额外的往返次数会变得非常多。通常情况下，只要有分片，就要多一个往返传输. 例如在 EAP MTU=1496字节的情况下， 一个 14960 字节的 certificate chain 要用 10个往返传输。

如果 EAP 所使用的 lower layer 具有显著的丢包现象，或者 authenticator 和 authentication server 的连接具有显著的丢包现象， 需要大量 往返传输 的 EAP methods 容易出现问题。在这些情况下，建议使用 较少往返的 EAP methods.

2 Extensible Authentication Protocol (EAP)

	EAP 认证 交换过程如下：
[1]	authenticator 向 peer 发送 Request， Request 包含 Type 栏位指明 请求的内容。 例如， Request Types 有 Identity， MD5-challenge 等等。 典型的，authenticator 会首先发起一个 Identity Request.
[2]	peer 针对一个有效的 Request， 回送一个 Response, 其中包含的type 栏位一致。
[3]	authenticator 和 peer 根据需要， Requests/Response 可以持续进行。 EAP is a lock step protocol , 就是说 在 收到一个有效 Response 之前，不能发送一个新的 Request 。 authenticator 负责 重传 和 超时处理
[4]	会话持续，直到 authenticator 无法认证peer — authenticator 发送 EAP- Failure 或者 成功完成认证， ---- authenticator 发送 EAP-Success

Advantages

• EAP protocol 支持多个 认证机制，无需预先协商一个特定的认证机制
• 一个NAS 设备 （例如 switch 或者 AP) 不要求理解每个 authentication method, 它可以作为一个backend authentication server 的 透传代理人。支持透传是个可选项。 一个authenticator 可认证本地 peers, 与此同时，它可以为 （非本地peer 或者 它不支持的authentication methods） 执行透传模式。
• 将authenticator 从 backend authentication server 中分离出来，简化证书管理 和 策略决策执行。

Disadvantages （略）

2.1. Support for Sequences

一个EAP 会话 可能用到一系列的 methods. 一个通用的例子是， 一个 Identity request 后面跟随一个 像MD5-Challenge 单一的EAP authentication method. 然而 在一个EAP 会话中，peer 与 authenticator 必须 并且 仅使用一个 authentication method (type 4 or greater)，在此之后authenticator 必须发送 Success packet 或者 Failure packet.

一旦 peer 发送 了 与 initial Request 具有相同 Type 的 Response, authenticator
     * 一定不能 在 给定method (当前method) 完成之前 发送一个不同Type 的 Request.
     * 一定不能 在当前authentication method 完成之后，发送一个不同Type 的 Request
     * 如果peer 收到这样的 Requests, 它必须当作无效的 并 默默丢弃。因此 不支持 Identity Requery。

peer 在已经 发送了一个 inital non-Nak Response 之后，它一定不能发送 Nak 以回应Request. 由于攻击者可能发送一个 欺骗性的EAP Request packets, authenticator 如果收到一个非预期的 Nak, 应该丢掉它并做记录。

由于具有 中间人攻击的弱点，以及 不兼容于现有的实现，在一个 EAP 会话中，不支持多个 authentication methods,。但是这个禁令不适用于这种情形：使用单个 authentication method（A）， 而其它methods 是作为一个 “tunneled” method运行于A中。

不支持 “tunneled method” 的 peer 可以针对 initial EAP-Request 回复一个 Nak, 于是可以提供向前兼容。（Alpha: 不理解这个）。为了处理安全性弱点问题， "tunneled“ method 必须支持保护以对抗中间人攻击。

2.2. EAP Multiplexing Model

EAP 在概念上 组成部分由：

Lower layer	负责在 peer 和 authenticator 直接 TX/RX EAP frames. lower layer 有 PPP, IEEE802.3, WLAN, UDP, TCP。 Lower layer 的行为在 第3节中介绍
EAP layer	通过 lower layer TX/RX eap packet, 执行重复包检测，负责重发。 把eap packet 分发 给 EAP peer layer 或 EAP authenticator layer. 也从上层收取 eap packets
EAP peer and EAP authenticator layer	基于 code 栏位， 下层的EAP layer 实现解复用 EAP packet 并分发到这一层。 典型地， 在给定主机上的 EAP实现 要么 执行 peer 要么 执行 authenticator。 但是也可能同时执行peer 和 authenticator .
EAP methods layers	执行认证算法

EAP 模型如下： （为什么上传的图片要盖水印…太蠢了）

EAP frame 中的 Code 字段的作用 很像 IP 头中的 protocol number. EAP layer 根据该字段进行解复用。收到的 Code=1(Request), 3(Success), 4(Failure) 的 EAP packets 会从 EAP layer 被分发到EAP peer layer. 收到的 Code=2 (Response) 的 EAP packets 会被分发到 EAP authenticator layer.

EAP frame 中的 Type 字段的作用 很像 UDP/TCP 中的 port number. EAP peer layer 和 EAP authenticator layer 根据这个字段 对收到的 EAP packet 进行解复用，将他们分发到与 Type 对应的 EAP method.

由于 EAP authentication methods 可能希望访问 Identity, 因此实现中 Identity Request 和 Identity Response 应该可以被其它 authentication methods 访问（引用）。Identity Type 在 5.1 小节中讨论。

Notification Response 仅被用来确认peer 有收到 Notification Request, 而不能任务peer 有处理 这个Notification Request 或者 向用户显示消息。不能假定 Notification Request 和 Notification Response 的内容可用于其它method. Notification Type 在 5.2 中讨论。

Nak (Type 3) 或 Expanded Nak (Type 254) 用于 method negotiation 目的。Peer 针对一个无法处理的Type 的 EAP Request 响应一个 Nak Response 或者 Expanded Nak Response. 不能假定 Nak Response 的内用可用于其它method. Nak Type 在5.3中讨论。

EAP-Success 和 EAP-Failure 不含有 Type 字段，也不会被分发到 EAP method. EAP-Success 和 EAP-Failure 在 4.2 中讨论。

基于以上考虑，Success, Failure, Nak Response, Notification Request, Notification Response 一定不能携带用于EAP methods 的数据。

2.3. Pass-Through Behavior

当 authenticator 操作于 pass-through 模式时，它按照 Section4.1 检测 Code, Identifier 和 Len 字段。
若authenticator 收到来自 peer 的、目标为他自己的authenticator layer的 EAP packets， 就将EAP packet 转发给 backend authentication server. 若 authenticator 收到来自 backend authentication server 的、目标为peer 的 EAP packets, 就将它转发给 peer.

一个主机收到一个 EAP packets 只做三件事： act on it, drop it, or forward it. Authenticator 的 “转发决定” 典型地 是基于检测 Code, Idnetifier, Len 字段.

除非 authenticator 本身有实现一种或多种 支持authenticator 角色地 authentication method，authenticator 在做转发决策时不会检查 EAP method layer header 中地字段（Type, Type-Data). 当Authenticator 支持本地authentication methods 时，它可能检查 Type 字段 并决定是否自己处理这个packet 还是 转发。具有兼容性地 passthrough authentication 实现，必须默认转发任何Type 的 EAP packet.

收到具有 Code=1(Request), Code=3(Success) 和 Code=4(Failure) 的 EAP packets 会被 EAP layer 分发到 EAP peer layer. 因此除非主机有实现 EAP peer layer, 否则这些packet 将被丢弃。（同理，只有主机上有实现EAP authenticator layer 才会处理EAP-Response）。这个spec 并没有定义 “pass-through peer” 的行为。

转发模型如下:

在一个authenticator 执行pass-through 模式的会话中，它必须仅通过 backend authentication server 发出的Accept/Reject indication 来决定 认证的结果。一定不能 通过 {随同Accept/Reject indication 的 EAP-packet 的内容} 或者 {这类封装的EAP packet 的缺失} 来决定认证结果。

2.4. Peer-to-Peer Operation

由于EAP 是种端到端的协议， 在反方向也可能有独立的、同时的认证发生。两端可能同时扮演 authenticator 和 peer. 这种情况下，两端都要实现 EAP authenticator layer 和 EAP peer layer. 另外，双方peer 的 EAP method 实现 也都必须支持 authenticator 和 peer 的功能。

尽管EAP 支持 端到端的操作，一些EAP 实现、methods, AAA protocols 和 link layers 可能不支持 端到端操作。一些EAP methods 可能支持 非对称认证（asymmetric authentication）, 针对peer 要求使用一种 证书类型，针对authenticator 要求使用另一种证书类型。使用这种 method 的、支持端到端操作的 主机 需要配置两种类型的证书.

（Alpha: 下面内容都不是很了解细节哎…另外 credential（凭证) 和 certificate(证书) 是同一个意思码?）

例如，EAP-TLS[RFC2716] 是种 C/S 协议，它分别为client 和 server 使用不同的证书配置文件（certificate profiles）. 这意味着支持 EAP-TLS 端到端认证 的主机需要同时执行 EAP peer layer 和 EAP authenticator layer, 在EAP-TLS 实现中要同时支持peer 角色和 authenticator 角色， 以及为各个角色配置适当的证书。

像 RADIUS/EAP[RFC3579] 和 Diameter EAP[DIAMEAP] 这类 AAA protocol 仅支持 ”pass-through authenticator“ 操作。在 [RFC3579] 2.6.2小节提到, 一个RADIUS server 针对（封装有EAP-Request, Success 或者 Failure packet 的 Access-Request）响应一个 Access-Reject. 因此不支持 “pass-through peer” 操作。

即便所使用的 methods 支持 相互认证 和 结果显示，存在以下一些考虑因素，要求 在两个方向上进行EAP authentication。这些考虑因素如下：

[1]	对在底层派生双向会话密钥的支持。像IEEE802.11 这样的底层 可能仅支持临时会话密钥的单向派生和传送. 例如，IEEE802.11 中定义的 group-key handshake 就是单向的，在 802.11 infrastructure mode 中 只有AP 发送多播和广播 。在 IEEE802.11 ad hoc mode 中，双方都可能发送 多播和广播, 需要在两个方向进行 group-key exchanges. 由于设计限制, 这意味在每个方向都需要进行 unicast key derivations 和 EAP method exchanges.
[2]	对在底层在发生断线情况的支持. 像 IEEE802.11 ad hoc 这样的底层不支持"断开连接", 两个相互启动身份验证的主机将只进行一次身份验证. 这意味着 即便 802.11 支持双向的 group-key handshake, 在每个方向上仍然会发生身份认证。
[3]	满足对端的策略. EAP methods 可能支持认证结果显示, peer 能够向EAP server 指示它已成功验证EAP server, 同样server 能够向 peer 指示 它已经成功验证 peer. 然而， 一个 pass-through authenticator 不能意识到 peer 已经接受 EAP server 提供的credentials, 除非有通过AAA protocol 为authenticator 这个信息。authenticator 应将接收到的Accept packet 中的密钥属性解释为peer 已成功验证 server。

transient session key: 临时会话密钥

然而，有可能在初始 EAP 交换中 EAP peer 的接入策略没有被满足，即便发生了互相认证。For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. 所以 peer 可能在相反方向也需要一个额外的身份认证，尽管peer 已经指示 EAP server 已经成功认证了该peer.

3 Lower Layer Behavior

3.1. Lower Layer Requirements

EAP 对 lower layer 有以下假设

[1]	传输不可靠。EAP 对 lower layer 是否可靠不做假设，authenticator 会重发还没有收到 Responses 的Requests. 由于EAP 定义了他自己的重发行为，所以有可能在 lower layer 和 EAP layer 都会发生重发。 注意 EAP-Success 和 EAP-Failure 不会被重发。在没有可靠的 lower layer ， 和如果存在不可忽略的错误率 ， 这些packets 可能丢失并导致发生超时。因此在 4.2 小节中有描述 实现中如何改善这一情况
[2]	错误检测。虽然EAP 对底层可靠性不做假设，它依赖错误检查（e.g. CRC, Checksum, MIC 等等）。 EAP methods 可能不包含MIC, 如果有，也可能MIC 计算不会覆盖所有字段（Code, Identifier, Length, Type ). 所以，如果没有底层的错误检测，未检测到的错误会传导到EAP layer/EAP methods layer 进而导致认证失败。 例如 EAP-TLS[RFC2716] 仅仅对Type-Data 字段进行MIC 计算，MIC 校验失败即为致命错误。如果没有底层的错误检测，像EAP-TLS 这样methods 无法可靠执行。
[3]	底层安全性。EAP 不要求底层提供(such as per-packet confidentiality, authentication, integrity and replay protection)安全服务. 然而，如果可以使用这些安全服务，支持密钥派生的 EAP methods (参考7.2.1) 可以用来提供 dynamic keying material. 这可以将EAP authentication 与后续数据 绑定，进而防止数据修改、欺骗或重播。参考7.1节
[4]	最小 MTU. EAP 能够运行于 提供 大于等于1020 字节 EAP MTU 的 底层。 EAP 不支持 MTU探测， 并且不支持分片和封包重组。本文定义的methods （Identity, Notification, Nak Response, MD5-Challenge…）也不支持封包分片和重组. 典型地，EAP peer 从底层获取 EAP MTU 信息 并设置适当的 EAP frame size. 当authenticator 操作于 pass-through 模式时，authentication server 没有直接探测EAP MTU的方法，因此它依赖authenticator 提供这些信息（例如通过Framed-MTU attribute, 参考RFC3579, 2.4 小节）。 虽然像EAP-TLS 这一的 methods 支持分片和重组， 但是 EAP methods 最初被设计用于 PPP, 在PPP 中，针对control frames 提供1500字节MTU 的保证，并缺乏分片和重组的功能。 如果缺失判断EAP MTU的信息，EAP methods 可以假设一个 1020 字节的最小EAP MTU 。如果payload 可能大于这个 最小EAP MTU, 那么EAP methods 应该支持分片和重组。 EAP 是一个lock-step 协议，这意味着在处理分片和重组时效率不高。 因此，如果底层支持分片和重组(例如EAP 在IP上传输)，倾向于在底层 而不是由EAP 执行分片和重组。这可以通过人为的为EAP 设定一个超大的EAP MTU, 使得分片和重组发生在底层。
[5]	重复封包可能性。如果底层实现可靠传输，那么底层能够为EAP layer 提供非重复packet. 虽然期望底层提供非重复packet，但这是不被要求的。Identifier 字段为peer 和 authenticator 提供了检测重复封包的能力。
[6]	顺序保证。EAP不要求 Identifier 单调递增，它依赖于较低层的顺序保证才能正确操作。EAP 最初被定义于运行在PPP, PPP具有顺序要求。 给定一个优先级，传输EAP 的底层必须维持 源到目的的 顺序传输。（IEEE-802 提供顺序传输保证）。 如果有发生重新排序， 往往会导致EAP 认证失败，并导致EAP 认证重新执行。在一个很可能发现重新排序的环境中，因此，预计EAP身份验证失败将是很常见的。文档建议EAP 仅仅运行于提供顺序保证的 底层；在裸IP 或者UDP 上传输EAP 是不被推荐的。在RADIUS[RFC3579] 中封装EAP 满足顺序要求，因为RADIUS 是一个 按次序发包的lockstep 协议。

3.2. EAP Usage Within PPP

为了建立 point-to-point link 之上地通信，在链路建立阶段，PPP link 地两个端点 首先发送 LCP packets 以配置数据链路。链路建立了之后，PPP在 Network-Layer Protocol 阶段之前 提供了可选地 认证阶段。

默认地，认证不是强制的。如果希望链路认证，在 链路建立阶段，必须指定 Authentication Protocol Configuration Option.

如果在认证阶段建立了 peer identity，那么server 可以在后续的network layer negotiations 中使用这个identity.

当EAP 用于PPP，在PPP Link Control Phase， EEE 并不选择特定认证机制，而是推迟到Authentication Phase. 这使得authenticator 能够在决定特定认证机制之前 请求更多 （对选择有用）的信息。这也使得可以使用真正执行多种机制的 backend server，而PPP authenticator 主要透传这些authentication exchange. PPP Link Establishment，Authentication phases 以及 Authentication Protocol Configuration Option 定义于 PPP RFC1661.

3.3. EAP Usage Within IEEE 802

IEEE802 对 EAP 的封装定义于 IEEE802.1X。封装了EAP 的 IEEE802 并不牵涉 PPP, IEEE802.1X 不支持 链路协商 或 网络层协商。因此，在 IEEE802.1X 中，无法协商 EAP authentication 之外的机制，例如 PAP 或者 CHAP.

3.4. Lower Layer Indications

底层指示的可靠性和安全性取决于底层具体实现。由于EAP 是媒体无关的，EAP 在处理EAP messages过程中并不会考虑 底层是否有执行安全相关操作。

为了提供可靠性，如果peer 收到定义于7.2 的底层成功指示，它可能得出一个成功包已经丢失的结论，并且表现得好像它实际上已经收到了一个EAP-Success。这包括在第4.2节所述的某些情况下选择忽略EAP-Success。

于 PPP, IEEE802 wired networks, 和 IEEE802.11 WLAN 有关的 lower layer indication 的 可靠性和安全性的讨论 可以参考 7.2。

在EAP 认证完成之后，peer 会通过 authenticator 发送和接收数据。期望得到这样的保证：发送数据的实体 于 成功完成EAP 认证的实体 是同一个。为了实现这个，底层有必要提供 per-packet 完整性，认证 和重放攻击保护，有必要将这些per-packet service 与 EAP 认证派生出来的密钥关联起来。否则后续数据流可能会被修改，欺骗或遭受重放攻击。

如果 EAP 自身提供用于lower layer ciphersuite 的密钥材料， 则由lower layer 控制 ciphersuite 协商和 密钥激活。在PPP中，ciphersuites 是在ECP中协商的，因此在ECP完成之前，不可能使用从EAP身份验证派生的密钥。因此最初的 EAP exchange 不能用 PPP ciphersuite保护，虽然EAP re-authentication 可以被保护。

在IEEE 802 媒体中，初始密钥激活典型地 是发生在 EAP 认证完成之后。因此最初地EAP exchange 无法被lower ciphersuite 保护， 即便EAP re-authentication 或者 pre-authentication 交换可以被保护。

4 EAP packet Format (略)

（翻译这节内容没什么意思，比较基础，资料也比较丰富…）

5 Initial EAP Request/Response Types

这节内容定义了用于 Request/Response 交换的 EAP Types 初始集。在未来的文档可能会定义更多的 Types. Type 字段为一个字节，标识了 EAP-Request 或者 EAP-Response 封包的结构。 前面3个 Types 被当做特殊Types； 剩余的Types 定义认证交换。

Nak (Type 3) 和 Expanded Nak (Type 254) 仅用于 Response packets, 一定不能用于Request. 所有的EAP 实现都必须 支持 本文定义的Types 1~4, 并且应该支持Type 254.

	(关注高亮部分)
1	Identity
2	Notification
3	Nak (Response only)
4	MD5-Challenge
5	One Time Password (OTP)
6	Generic Token Card (GTC)
254	Expanded Types
255	Experimental use

5.1 Identity

Description
Identity Type 用于询问 peer 的身份。通常authenticator 会将它作为最初的Request 进行处理。在期望与用户交换的情形中，可选地 可以包含一个可读信息用做提示目的。响应Identity-Request, peer 应该发送一个 Identity-Response.

有些EAP 实现 可能 在 Identity-Request 的 NULL字符后面装载各种选项. 默认的 EAP 实现中不能假设 Identity-Request 或者 Identity-Response 会超过 1020 字节。

文档建议 Identity-Response 主要用于 路由目的 和 选择要用的 EAP method. EAP methods 应该具有 获取identity 的机制，从而methods 不必依赖 Identity-Response. Identity-Request 和 Identity-Response 以明文发送，因此，攻击者可能会窥探身份，甚至修改或欺骗身份交换。为了解决这些威胁，EAP method 最好包括支持每包认证、完整性和重播保护以及机密性的身份交换。对于method, Identity-Response 可能不适合作为身份。Identity-Response 可能已被截断或混淆，以便提供隐私, 或者它被用于路由目的。如果peer 配置为只接受支持受保护的身份交换的认证方法，则peer可以提供缩略形式的Identity-Repsonse。有关身份保护的进一步讨论，请参见第7.3节。

Implementation Note: peer 可能需要通过用户输入以获取 Identity. 建议authenticator 在发生 invalid identity 或者 认证失败时，重试 Identity-Request，以应付用户可能出现的输入错误。建议在终止认证之前，重试Identity-Request 至少3次。在发送新的 Identity-Request 之前，可能会先发送 Notification-Request 用于指示认证尝试无效。(可选的，错误显示也可能包含在 新的Identity-Request 中)。

5.2 Notification

5.3 Nak

5.3.1. Legacy Nak

Description

legacy Nak Type 仅用于EAP-Response. 它被用来回复Request，指示不接受Request 中指定的authentication Type。Response 中含有一个或多个Peer 期望的authentication Types. Peer 使用Type 0 指示它没有其它选择，因此authenticator 在收到 函数有Type 0 的 Nak Response 后 不能再次发送一个Request。

由于legacy Nak Type 仅用于EAP-Responses 并且功能非常有限，它一定不能被用于通用目的的错误指示.

5.3.2. Expanded Nak

Description

Expanded Nak Type 仅用于 EAP-Response。仅用于回复 Type 254 （Expanded Type) 的 Request. Expanded Nak Type 本身使用了 Expanded Type 格式， Response 含有一个或多个 peer 期望的authentication Types.

由于legacy Nak Type 仅用于EAP-Responses 并且功能非常有限，它一定不能被用于通用目的的错误指示.

下面是一个例子，用Expanded Nak Reponse 指示peer 偏向于使用 OTP (Type 5) 与 MIT (Vendor-Id=20) 和 Expanded Type 6。

一个用于指示 没有其它可替换的、期望的 authentication methods 的 Expanded Nak 的格式如下：

5.4 MD5-Challenge

Description

MD5-Challenge Type 类似于 PPP CHAP protocol [RFC1994]. Request 中含有向peer 发起挑战（or质询? challenge）的数据。peer 必须针对Request 回送 一个Response。Response 中的Type 是 4（MD5-Challenge), Nak, Expanded Nak 的一种。Nak 指明 peer 想要的认证类型。EAP peep 和 EAP server 的实现必须支持MD5-Challenge. 仅支持 passthrough 的authenticator 必须允许和一个支持MD5-Challenge 的backend authentication server 通信。然而，如果EAP authenticator 被配置为本地认证 peers, 那么它就要服从上述要求，即必须支持MD5-Challenge.

注意 在MD5-Challenge Type 中的 Identifier 字段的用法 与 RFC1994 描述的不同。EAP 允许重发MD5-Challenge Request 报文， 然而RFC1994 规定 在每次发送 Challenge 相关报文时，Identifier 和 Challenge 字段都必须改变。

注意： RFC1994 将shared secret 当做octet string（这里应该强调的是binary 字节串，而不是text？), 而没有规定它是如何输入到系统的。EAP MD5-Challenge 的实现 可能支持输入 非ASCII 的 passphrases (啊？ 和前面理解冲突了！).

5.7 Expanded Types

Description

由于大量现存 EAP 属于 vendor-specific, Expanded method Type 可用于支持vendor 自己的Expanded Type。

Expanded type 也用于扩展原有的、有限的255种类。当Vendor-Id == 0时，将原有的255 个Type 映射到 （2³² - 1） 个Types 空间。(Type 0 仅用于 Nak Response，作为指示不接受 的另一个选择）

支持Expanded attribute 的实现必须 等同对待 小于256的EAP Type，无论它们是作为单个字节出现，还是作为Expanded Type（其中供应商Id为0）中的32-bit Vendor-Type 出现。不支持Expanded Type 的 Peer 必须发送一个 Nak, 并协商出一个合适的 authentication method.

5.8 Experimental (略)

6 IANA Considerations

7 Security Considerations (略)

8 Acknowledgements