跳到主要内容

7. Security Considerations

7. Security Considerations​

本节定义了通用的威胁模型，以及缓解这些威胁的 EAP 方法安全声明。

预计通用威胁模型和相应的安全声明将用于定义特定环境中使用的 EAP 方法要求。此类要求分析的一个示例在 [IEEE-802.11i-req] 中提供。EAP 方法规范中要求包含安全声明部分，以便可以根据要求对 EAP 方法进行评估。

7.1. 威胁模型​

EAP 是为与 PPP [RFC1661] 一起使用而开发的，后来在 [IEEE-802.1X] 中被改编用于有线 IEEE 802 网络 [IEEE-802]。随后，EAP 被提议用于无线 LAN 网络和 Internet。在所有这些情况下，攻击者都有可能访问传输 EAP 数据包的链路。例如，[DECEPTION] 中记录了对电话基础设施的攻击。

拥有链路访问权的攻击者可以发起多种攻击，包括：

[1] 攻击者可能试图通过窃听认证流量来发现用户身份。

[2] 攻击者可能试图修改或欺骗 EAP 数据包。

[3] 攻击者可能通过欺骗较低层指示或 Success/Failure 数据包、重放 EAP 数据包，或生成具有重叠 Identifier 的数据包来发起拒绝服务攻击。

[4] 攻击者可能试图通过发起离线字典攻击来恢复口令短语。

[5] 攻击者可能试图通过发起中间人攻击来说服 peer 连接到不受信任的网络。

[6] 攻击者可能试图破坏 EAP 协商，以导致选择较弱的认证方法。

[7] 攻击者可能试图利用 EAP 方法内使用的弱密钥派生技术来恢复密钥。

[8] 攻击者可能试图利用 EAP 会话完成后随后使用的弱密码套件。

[9] 攻击者可能试图对较低层密码套件协商进行降级攻击，以确保随后在 EAP 认证之后使用较弱的密码套件。

[10] 充当 authenticator 的攻击者可能通过带外机制（例如通过 AAA 或较低层协议）向 EAP peer 和/或服务器提供不正确的信息。这包括冒充另一个 authenticator，或向 peer 和 EAP 服务器提供不一致的信息。

根据较低层的不同，这些攻击可以在不需要物理邻近的情况下进行。当 EAP 用于无线网络时，EAP 数据包可能由 authenticator（例如预认证）转发，因此攻击者不需要在 authenticator 的覆盖范围内即可对其进行攻击或其 peer。当 EAP 用于 Internet 时，可以在更远的距离上发起攻击。

7.2. 安全声明​

为了清楚地阐明 EAP 方法提供的安全性，EAP 方法规范 MUST 包含一个安全声明部分，包括以下声明：

[a] 机制。这是对认证技术的陈述：证书、预共享密钥、口令、令牌卡等。

[b] 安全声明。这是对方法所声明的安全属性的陈述，使用第 7.2.1 节中定义的术语：互认证、完整性保护、重放保护、机密性、密钥派生、字典攻击抵抗、快速重连、加密绑定。EAP 方法规范的安全声明部分 SHOULD 为所做出的声明提供理由。这可以通过在附录中包含证明，或包含对证明的引用来实现。

[c] 密钥强度。如果方法派生密钥，则 MUST 估计有效密钥强度。此估计旨在供方法的潜在用户确定所产生的密钥是否足够强以用于预期应用。

有效密钥强度应表示为比特数，定义如下：如果有效密钥强度为 N 比特，则目前已知的最佳密钥恢复方法（具有不可忽略的概率）平均需要相当于 2^(N-1) 次典型分组密码操作的努力。该陈述应附带简要理由，解释该数字是如何得出的。该解释应包括基于当前算法知识达到所述密钥强度所需的参数。

（注意：尽管很难精确定义"相当的努力"和"典型分组密码"的含义，但合理的近似值在此已足够。有关更多讨论，请参见例如 [SILVERMAN]。）

密钥强度取决于用于派生密钥的方法。例如，如果密钥是从共享密钥（例如口令或长期密钥）以及可能的某些公开信息（例如 nonce）派生的，则有效密钥强度受长期密钥强度的限制（假设派生过程在计算上很简单）。再举一个例子，当使用公钥算法时，对称密钥的强度取决于所用公钥的强度。

[d] 密钥层次结构描述。派生密钥的 EAP 方法 MUST 提供对密钥层次结构规范的引用，或描述应如何派生主会话密钥（MSK）和扩展主会话密钥（EMSK）。

[e] 漏洞指示。除所做出的安全声明外，规范 MUST 指示第 7.2.1 节中详述的哪些安全声明未被做出。

7.2.1. EAP 方法的安全声明术语​

这些术语用于描述 EAP 方法的安全属性：

受保护的密码套件协商

这是指 EAP 方法协商用于保护 EAP 会话的密码套件，以及对协商进行完整性保护的能力。它不指代协商用于保护数据的密码套件的能力。

互认证

这是指在一个互锁交换中，authenticator 认证 peer 且 peer 认证 authenticator 的 EAP 方法。两个独立运行的单向方法，在相反方向上运行，不提供此处定义的互认证。

完整性保护

这是指提供数据源认证以及对 EAP 数据包（包括 EAP Request 和 Response）信息的未授权修改的保护。做出此声明时，方法规范 MUST 描述受保护的 EAP 数据包和 EAP 数据包内的字段。

重放保护

这是指针对 EAP 方法或其消息（包括成功和失败结果指示）的重放保护。

机密性

这是指对 EAP 消息（包括 EAP Request 和 Response，以及成功和失败结果指示）的加密。做出此声明的方法 MUST 支持身份保护（见第 7.3 节）。

密钥派生

这是指 EAP 方法派生可导出密钥材料（例如主会话密钥（MSK）和扩展主会话密钥（EMSK））的能力。MSK 仅用于进一步的密钥派生，不直接用于保护 EAP 会话或后续数据。EMSK 的使用被保留。

密钥强度

如果有效密钥强度为 N 比特，则目前已知的最佳密钥恢复方法（具有不可忽略的概率）平均需要相当于 2^(N-1) 次典型分组密码操作的努力。

字典攻击抵抗

在使用口令认证的情况下，口令通常从小集合（与 N 比特密钥集合相比）中选择，这引发了关于字典攻击的担忧。如果方法在使用口令作为密钥时，不允许基于攻击者字典中口令数量的、具有工作因子的离线攻击，则可以称该方法提供针对字典攻击的保护。

快速重连

在先前已建立安全关联的情况下，以更高效或更少往返次数创建新的或刷新的安全关联的能力。

加密绑定

EAP peer 向 EAP 服务器证明单个实体已作为隧道方法内执行的所有方法的 EAP peer 的能力。绑定也可以暗示 EAP 服务器向 peer 证明单个实体已作为隧道方法内执行的所有方法的 EAP 服务器。如果正确执行，绑定有助于缓解中间人漏洞。

会话独立性

证明被动攻击（例如捕获 EAP 会话）或主动攻击（包括 MSK 或 EMSK 的泄露）不会危及后续或先前的 MSK 或 EMSK。

分片

这是指 EAP 方法是否支持分片和重组。如第 3.1 节所述，如果 EAP 数据包可能超过 1020 个八位组的最小 MTU，EAP 方法应支持分片和重组。

信道绑定

在 EAP 方法内通信完整性保护的信道属性（例如端点标识符），这些属性可以与通过带外机制（例如通过 AAA 或较低层协议）通信的值进行比较。

注意：此安全声明列表并非详尽无遗。其他属性（例如额外的拒绝服务保护）也可能相关。

7.3. 身份保护​

身份交换在 EAP 会话中是可选的。因此，可以完全省略身份交换，或者在建立受保护信道后使用特定于方法的身份交换。

但是，在支持如 [RFC2607] 所述的漫游的情况下，可能需要在认证会话可以继续之前定位适当的后端认证服务器。网络访问标识符（NAI）[RFC2486] 的域部分通常包含在 EAP-Response/Identity 中，以便使认证交换能够路由到适当的后端认证服务器。因此，虽然 NAI 的 peer 名称部分在存在代理或中继的情况下可以在 EAP-Response/Identity 中省略，但域部分可能是必需的。

身份响应中的身份有可能不同于 EAP 方法认证的身份。在身份隐私的情况下，这可能是有意的。EAP 方法在做出访问控制决策时 SHOULD 使用已认证的身份。

7.4. 中间人攻击​

在 EAP 被隧道封装在省略 peer 认证的另一协议中时，存在对中间人攻击的潜在漏洞。有关详细信息，请参见 [BINDING] 和 [MITM]。

如第 2.1 节所述，EAP 不允许未经隧道处理的认证方法序列。如果允许 EAP 认证方法序列，则 peer 可能没有证据证明单个实体已作为该序列中所有 EAP 方法的 authenticator。例如，authenticator 可能终止一个 EAP 方法，然后在 peer 不知情或不同意的情况下将序列中的下一个方法转发给另一方。类似地，authenticator 可能没有证据证明单个实体已作为该序列中所有 EAP 方法的 peer。

在另一协议内对 EAP 进行隧道封装使得恶意 EAP authenticator 将 EAP 隧道传输到合法服务器的攻击成为可能。在隧道协议用于密钥建立但不要求 peer 认证的情况下，说服合法 peer 连接到它的攻击者将能够将 EAP 数据包隧道传输到合法服务器，成功认证并获取密钥。这使得攻击者能够成功地将自己确立为中间人，获得对网络的访问权限，以及对合法 peer 和服务器之间数据流量进行解密的能力。

可以通过以下措施缓解此攻击：

[a] 在 EAP 隧道机制内要求互认证。

[b] 要求 EAP 隧道协议与隧道内 EAP 方法之间的加密绑定。在支持加密绑定的情况下，还需要一种机制来防止会绕过它的降级攻击。有关加密绑定的更多详细信息，请参见 [BINDING]。

[c] 基于 peer 和 authenticator 策略，限制被授权在无保护情况下使用的 EAP 方法。

[d] 在单一强方法可用时避免使用隧道。

7.5. 数据包修改攻击​

虽然 EAP 方法可能支持每包数据源认证、完整性和重放保护，但 EAP 层内不提供支持。

由于 Identifier 仅为单个八位组，因此很容易被猜出，从而允许攻击者成功地注入或重放 EAP 数据包。攻击者还可以修改 EAP 数据包中不受保护的 EAP 头（Code、Identifier、Length、Type）。这可能导致数据包被不当地丢弃或误解。

为了保护 EAP 数据包免受修改、欺骗或重放，建议使用支持受保护密码套件协商、互认证、密钥派生以及完整性和重放保护的方法。有关这些安全声明的定义，请参见第 7.2.1 节。

可以使用特定于方法的 MIC 来提供保护。如果在 EAP 方法内采用每包 MIC，则不在直通模式下运行的 peer、认证服务器和 authenticator MUST 验证该 MIC。MIC 验证失败 SHOULD 被记录。MIC 验证失败是否被视为致命错误由 EAP 方法规范决定。

建议提供 EAP 数据包完整性保护的方法包含对所有 EAP 头字段（包括 Code、Identifier、Length、Type 和 Type-Data 字段）的覆盖。

由于 Identity、Notification 和 Nak 类型的 EAP 消息不包含其自身的 MIC，因此可能希望 EAP 方法 MIC 覆盖这些消息中包含的信息，以及每个 EAP 消息的头。

为了提供保护，EAP 也可以封装在由 ISAKMP [RFC2408] 等协议创建的受保护信道内，如 [IKEv2] 中所做的那样，或在 TLS [RFC2246] 内。但是，如第 7.4 节所述，EAP 隧道可能导致中间人漏洞。

现有的 EAP 方法定义了覆盖多个 EAP 数据包的 message integrity check（MIC）。例如，EAP-TLS [RFC2716] 定义了针对可能拆分为多个分片的 TLS 记录的 MIC；在 FINISHED 消息内，MIC 是在先前的消息上计算的。在 MIC 覆盖多个 EAP 数据包的情况下，MIC 验证失败通常被视为致命错误。

在 EAP-TLS [RFC2716] 中，MIC 验证失败被视为致命错误，因为 TLS [RFC2246] 中规定了这一点。但是，也可以开发支持每包 MIC 的 EAP 方法，并通过静默丢弃违规数据包来响应验证失败。

在本文档中，对 EAP 消息处理的描述假设，发生每包 MIC 验证的地方，其有效地执行方式如同在发送任何响应或改变接收该数据包的主机状态之前执行一样。

7.6. 字典攻击​

已知 EAP-MD5、MS-CHAPv1 [RFC2433] 和 Kerberos V [RFC1510] 等口令认证算法易受字典攻击。[PPTPv1] 中记录了 MS-CHAPv1 漏洞；[PPTPv2] 中记录了 MS-CHAPv2 漏洞；[KRBATTACK]、[KRBLIM] 和 [KERB4WEAK] 中描述了 Kerberos 漏洞。

为了防止字典攻击，建议使用抵抗字典攻击的认证方法（如第 7.2.1 节所定义）。

如果使用了已知易受字典攻击的认证算法，则可以将会话隧道封装在受保护信道内以提供额外的保护。但是，如第 7.4 节所述，EAP 隧道可能导致中间人漏洞，因此优选抵抗字典攻击的方法。

7.7. 连接到不受信任的网络​

对于支持单向认证的 EAP 方法（例如 EAP-MD5），peer 不认证 authenticator，使 peer 容易受到恶意 authenticator 的攻击。支持互认证的方法（如第 7.2.1 节所定义）解决了此漏洞。

在 EAP 中，不要求认证是全双工的，也不要求两个方向使用相同的协议。在每个方向使用不同的协议是完全可以接受的。当然，这将取决于协商的具体协议。但是，一般而言，完成单个统一的互认证优于两个单向认证（每个方向一个）。这是因为未以加密方式绑定以证明它们是同一会话一部分的单独认证容易受到第 7.4 节中讨论的中间人攻击。

7.8. 协商攻击​

在协商攻击中，攻击者试图说服 peer 和 authenticator 协商安全性较低的 EAP 方法。EAP 不为 Nak Response 数据包提供保护，尽管方法可以在特定于方法的 MIC 内包含对 Nak Response 的覆盖。

在每个 authenticator 内或与之关联，预计特定命名的 peer 不会支持多种方法的选择。这将使 peer 容易受到从一组方法中协商最不安全方法的攻击。相反，对于每个命名的 peer，SHOULD 有一个指示，确切地指明用于认证该 peer 名称的单一方法。如果 peer 需要在不同情况下使用不同的认证方法，则 SHOULD 采用不同的身份，每个身份确切地标识一种认证方法。

7.9. 实现特性​

EAP 与 PPP 和 IEEE 802 等较低层的交互高度依赖于实现。

例如，在认证失败时，某些 PPP 实现不会终止链路，而是将网络层协议中的流量限制为经过过滤的子集，这反过来使 peer 有机会更新密钥或向网络管理员发送邮件以指示问题。类似地，虽然在 [IEEE-802.1X] 中认证失败将导致受控端口被拒绝访问，但非受控端口上可能允许有限的流量。

在 EAP 中，没有针对失败认证的重试规定。但是，在 PPP 中，LCP 状态机可以随时重新协商认证协议，从而允许新的尝试。类似地，在 IEEE 802.1X 中，请求方或 authenticator 可以随时重新认证。建议任何用于认证失败的计数器在成功认证之后或失败链路的后续终止之前不要重置。

7.10. 密钥派生​

peer 和 EAP 服务器有可能相互认证并派生密钥。为了为随后协商的密码套件提供密钥材料，支持密钥派生的 EAP 方法 MUST 导出至少 64 个八位组的主会话密钥（MSK）和至少 64 个八位组的扩展主会话密钥（EMSK）。派生密钥的 EAP 方法 MUST 提供 EAP peer 和 EAP 服务器之间的互认证。

MSK 和 EMSK MUST NOT 直接用于保护数据；但是，它们的大小足以派生随后用于从所选密码套件派生临时会话密钥（TSK）的 AAA-Key。每个密码套件负责指定如何从 AAA-Key 派生 TSK。

AAA-Key 是从 EAP 方法导出的密钥材料（MSK 和 EMSK）派生的。此派生发生在 AAA 服务器上。在许多使用 EAP 的现有协议中，AAA-Key 和 MSK 是等价的，但可能存在更复杂的机制（详见 [KEYFRAME]）。

EAP 方法 SHOULD 确保 MSK 和 EMSK 的新鲜性，即使在某一方可能没有高质量随机数生成器的情况下。建议的方法是每一方提供至少 128 比特的 nonce，用于 MSK 和 EMSK 的派生。

EAP 方法导出 MSK 和 EMSK，但不导出临时会话密钥，以使 EAP 方法能够独立于密码套件和媒体。EAP 方法导出的密钥材料 MUST 独立于为保护数据而协商的密码套件。

根据较低层的不同，EAP 方法可能在密码套件协商之前或之后运行，因此所选密码套件可能对 EAP 方法未知。通过提供可用于任何密码套件的密钥材料，EAP 方法可以与各种密码套件和媒体一起使用。

为了保持算法独立性，派生密钥的 EAP 方法 SHOULD 支持（并记录）peer 和服务器之间用于保护 EAP 会话的密码套件的受保护协商。这不同于 peer 和 authenticator 之间协商的、用于保护数据的密码套件。

用于保护数据的临时会话密钥（TSK）的强度最终取决于 EAP 方法生成的密钥的强度。如果 EAP 方法无法产生足够强度的密钥材料，则 TSK 可能遭受暴力攻击。为了支持需要强密钥的部署，支持密钥派生的 EAP 方法 SHOULD 能够生成 MSK 和 EMSK，每个都具有至少 128 比特的有效密钥强度。

支持密钥派生的方法 MUST 证明 EAP 密钥层次结构中 MSK 和 EMSK 分支之间的加密分离。在不违反基本加密假设（例如单向函数的不可逆性）的情况下，恢复 MSK 或 EMSK 的攻击者 MUST NOT 能够以低于暴力攻击的努力水平恢复另一数量。

如第 7.2.1 节所定义，MSK 的非重叠子字符串彼此之间 MUST 具有加密分离。即，在不破坏某些困难加密假设的情况下，知道一个子字符串 MUST NOT 有助于恢复某些其他子字符串。这是必需的，因为某些现有密码套件通过简单地将 AAA-Key 拆分为适当长度的片段来形成 TSK。同样，EMSK 的非重叠子字符串彼此之间以及相对于 MSK 的子字符串 MUST 具有加密分离。

EMSK 保留供将来使用，MUST 保留在派生它的 EAP peer 和 EAP 服务器上；MUST NOT 被传输给或共享给额外的参与方，或用于派生任何其他密钥。（在规定了 EMSK 使用方式的未来文档中，此限制将被放宽。）

由于 EAP 不提供显式的密钥生命周期协商，EAP peer、authenticator 和认证服务器 MUST 为一方丢弃在另一方上仍然有效的密钥状态的情况做好准备。

本规范未提供关于 EAP 方法如何派生 MSK 和 EMSK、如何从 MSK 和/或 EMSK 派生 AAA-Key，或如何从 AAA-Key 派生 TSK 的详细指南。

密钥派生算法的开发和验证很困难，因此 EAP 方法 SHOULD 重用完善且经过分析的密钥派生机制（例如 IKE [RFC2409] 或 TLS [RFC2246] 中指定的机制），而不是发明新的机制。EAP 方法 SHOULD 也应利用完善且经过分析的 MSK 和 EMSK 派生机制。有关 EAP 密钥派生的更多详细信息在 [KEYFRAME] 中提供。

7.11. 弱密码套件​

如果在初始 EAP 认证之后，发送的数据包没有每包认证、完整性和重放保护，则拥有媒体访问权的攻击者可以注入数据包、在现有数据包内"翻转比特"、重放数据包，甚至完全劫持会话。没有每包机密性，就有可能窃听数据包。

为了防止数据修改、欺骗或窃听，建议使用支持互认证和密钥派生（如第 7.2.1 节所定义）的 EAP 方法，以及提供每包机密性、认证、完整性和重放保护的较低层。

此外，如果较低层执行密码套件协商，则应理解 EAP 本身不提供对该协商的完整性保护。因此，为了避免导致使用较弱密码套件的降级攻击，实现较低层密码套件协商的客户端 SHOULD 防止协商降级。

这可以通过允许用户将哪些密码套件作为安全策略可接受进行配置来实现，或者密码套件协商 MAY 使用从 EAP 认证派生的密钥材料和较低层 peer 预先约定的 MIC 算法进行认证。

PPP、IEEE 802 LAN 和 IEEE 802.11 无线 LAN 中的链路层指示存在可靠性和安全性问题：

[a] PPP。在 PPP 中，LCP-Terminate（链路失败指示）和 NCP（链路成功指示）等链路层指示未经认证或完整性保护。因此，拥有链路访问权的攻击者可以欺骗它们。

[b] IEEE 802。IEEE 802.1X EAPOL-Start 和 EAPOL-Logoff 帧未经认证或完整性保护。因此，拥有链路访问权的攻击者可以欺骗它们。

[c] IEEE 802.11。在 IEEE 802.11 中，链路层指示包括 Disassociate 和 Deauthenticate 帧（链路失败指示），以及 4 次握手的第一条消息（链路成功指示）。这些消息未经认证或完整性保护，并且虽然不可转发，但在范围内的攻击者可以欺骗它们。

在 IEEE 802.11 中，IEEE 802.1X 数据帧可以作为 Class 3 单播数据帧发送，因此是可转发的。这意味着虽然 EAPOL-Start 和 EAPOL-Logoff 消息可以经过认证和完整性保护，但当启用"预认证"时，远离目标的已认证攻击者可以欺骗它们。

在 IEEE 802.11 中，"链路断开"指示是链路失败的不可靠指示，因为无线信号强度可能出现并消失，并且可能受到攻击者产生的射频干扰的影响。为了避免不必要的重置，建议对这些指示进行阻尼，而不是直接将其传递给 EAP。由于 EAP 支持重传，它对瞬时连接丢失具有鲁棒性。

7.13. Authenticator 与后端认证服务器的分离​

EAP peer 和 EAP 服务器有可能相互认证并为用于保护后续数据流量的密码套件派生 AAA-Key。这在 peer 上不会出现问题，因为 peer 和 EAP 客户端驻留在同一台机器上；所需要的只是客户端从 EAP 方法导出的 MSK 和 EMSK 派生 AAA-Key，然后向密码套件模块传递临时会话密钥（TSK）。

但是，在 authenticator 和认证服务器驻留在不同机器上的情况下，对安全性有几个影响：

[a] 认证将在 peer 和认证服务器之间进行，而不是在 peer 和 authenticator 之间进行。这意味着仅使用 EAP，peer 不可能验证其正在与之通话的 authenticator 的身份。

[b] 如 [RFC3579] 中所述，authenticator 依赖于 AAA 协议以了解认证会话的结果，并且不查看封装的 EAP 数据包（如果存在）来确定结果。实际上，这意味着 authenticator 和认证服务器之间使用的 AAA 协议 MUST 支持每包认证、完整性和重放保护。

[c] EAP 会话完成后，将启用较低层安全服务（如每包机密性、认证、完整性和重放保护），SHOULD 在 peer 和 authenticator 之间运行安全关联协议，以提供 peer 和 authenticator 之间的互认证，保证临时会话密钥的活性，为后续数据提供受保护的密码套件和能力协商，并同步密钥使用。

[d] 从 peer 和认证服务器之间协商的 MSK 和/或 EMSK 派生的 AAA-Key MAY 被传输到 authenticator。因此，需要提供一种机制，将 AAA-Key 从认证服务器传输到需要它的 authenticator。AAA-Key 派生、传输和封装机制的规范不在本文档的范围内。有关 AAA-Key 派生的更多详细信息在 [KEYFRAME] 中提供。

7.14. 明文口令​

本规范未定义明文口令认证机制。此省略是有意的。使用明文口令将允许拥有传输 EAP 数据包的链路访问权的攻击者捕获口令。

由于封装 EAP 的协议（例如 RADIUS [RFC3579]）可能不提供机密性，EAP 数据包可能随后被封装以在 Internet 上传输，在那里它们可能被攻击者捕获。

因此，明文口令不能在 EAP 内安全使用，除非封装在具有服务器认证的受保护隧道内。第 7.2.1 节定义的某些相同风险也适用于没有字典攻击抵抗的 EAP 方法。有关详细信息，请参见第 7.6 节。

7.15. 信道绑定​

受损或实现不佳的 EAP authenticator 有可能向 EAP peer 和/或服务器通信不正确的信息。这可能使 authenticator 能够冒充另一个 authenticator，或通过带外机制（例如通过 AAA 或较低层协议）通信不正确的信息。

在直通模式下使用 EAP 时，EAP peer 通常不验证直通 authenticator 的身份，它仅验证直通 authenticator 受 EAP 服务器信任。这造成潜在的安全漏洞。

[RFC3579] 的第 4.3.7 节描述了如何检测充当 AAA 客户端的 EAP 直通 authenticator，如果它试图冒充另一个 authenticator（例如通过 AAA 协议发送不正确的 NAS-Identifier [RFC2865]、NAS-IP-Address [RFC2865] 或 NAS-IPv6-Address [RFC3162] 属性）。但是，充当 AAA 客户端的直通 authenticator 有可能向 AAA 服务器提供正确信息，同时通过较低层协议向 EAP peer 通信误导信息。

例如，受损的 authenticator 有可能在通过较低层协议与 EAP peer 通信时利用另一个 authenticator 的 Called-Station-Id 或 NAS-Identifier，或者充当 AAA 客户端的直通 authenticator 有可能通过 AAA 协议向 AAA 服务器提供不正确的 peer Calling-Station-Id [RFC2865][RFC3580]。

为了解决此漏洞，EAP 方法可以支持信道属性（例如端点标识符）的受保护交换，包括但不限于：Called-Station-Id [RFC2865][RFC3580]、Calling-Station-Id [RFC2865][RFC3580]、NAS-Identifier [RFC2865]、NAS-IP-Address [RFC2865] 和 NAS-IPv6-Address [RFC3162]。

使用这种受保护交换，可以将 authenticator 通过带外机制提供的信道属性与 EAP 方法内交换的属性进行匹配。当发现差异时，SHOULD 记录这些差异；MAY 也可以采取其他行动，例如拒绝访问。

7.16. 受保护的结果指示​

在 EAP 中，Success 和 Failure 数据包既不被确认，也不受完整性保护。当 EAP 在较低层上运行且较低层不支持重传或认证状态同步时，结果指示提高了对 Success 和 Failure 数据包丢失的弹性。在提供重传以及通过 [IEEE-802.11i] 中定义的 4 次握手同步认证状态的媒体（例如 IEEE 802.11）中，额外的弹性通常好处有限。

根据方法和情况的不同，结果指示可能被攻击者欺骗。如果方法支持结果指示以及"完整性保护"和"重放保护"声明，则称该方法提供受保护的结果指示。支持受保护结果指示的方法 MUST 指示哪些结果指示受保护，哪些不受保护。

受保护的结果指示不要求防止恶意 authenticator。在互认证方法内，要求服务器在 peer 接受 Success 数据包之前向 peer 认证，可以防止攻击者充当恶意 authenticator。

但是，在服务器已向 peer 认证之后、但在 peer 已向服务器认证之前，攻击者有可能伪造 Success 数据包。如果 peer 接受伪造的 Success 数据包并尝试在其尚未成功向服务器认证时访问网络，则可能对 peer 发起拒绝服务攻击。在此类攻击之后，如果较低层支持失败指示，authenticator 可以通过提供较低层失败指示来与 peer 同步状态。详见第 7.12 节。

如果服务器在确定 peer 是否已认证 authenticator 之前认证 peer 并发送 Success 数据包，则如果 authenticator 未被 peer 认证，则可能发生空闲超时。在较低层支持的情况下，感知到 peer 缺失的 authenticator 可以释放资源。

在支持结果指示的方法中，已认证服务器的 peer 在收到服务器已成功认证它的指示之前，不认为认证成功。类似地，已成功认证 peer 的服务器在收到 peer 已认证服务器的指示之前，不认为认证成功。

为了避免同步问题，在发送成功结果指示之前，发送方最好验证是否存在授予访问权限的足够授权，但如下所述，这并非总是可能的。

虽然结果指示可能实现 peer 和服务器之间认证结果的同步，但这并不保证 peer 和 authenticator 在授权方面将同步，也不保证不会发生超时。例如，EAP 服务器可能不知道 AAA 代理做出的授权决策；AAA 服务器可能仅在认证成功完成后检查授权，才发现无法授予授权，或者 AAA 服务器可能授予访问权限，但 authenticator 由于临时资源不足而无法提供。在这些情况下，同步只能通过在较低层结果指示来实现。

成功指示可以是显式的或隐式的。例如，在方法支持错误消息的情况下，隐式成功指示可以定义为在没有前置错误消息的情况下接收特定消息。失败通常显式指示。如第 4.2 节所述，peer 在方法未明确允许发送该数据包的点静默丢弃 Failure 数据包。例如，提供自身错误消息的方法可能要求 peer 在接受 Failure 数据包之前接收错误消息。

结果指示的每包认证、完整性和重放保护可防止欺骗。由于受保护的结果指示需要使用密钥进行每包认证和完整性保护，因此支持受保护结果指示的方法 MUST 也支持"密钥派生"、"互认证"、"完整性保护"和"重放保护"声明。

受保护的结果指示解决了由于欺骗 Success 和 Failure 数据包而导致的一些拒绝服务漏洞，尽管不是全部。EAP 方法通常只能在某些情况下提供受保护的结果指示。例如，错误可能在密钥派生之前发生，因此可能无法保护所有失败指示。也有可能结果指示在两个方向上都不受支持，或者并非在所有操作模式下都能实现同步。

例如，在 EAP-TLS [RFC2716] 中，在客户端认证握手中，服务器认证 peer，但不接收 peer 已认证它的受保护指示。相反，peer 认证服务器并知道服务器是否已认证它。在会话恢复握手中，peer 认证服务器，但不接收服务器已认证它的受保护指示。在此模式下，服务器认证 peer 并知道 peer 是否已认证它。