7. 安全考虑事项
7. 安全考虑事项
本节定义了通用威胁模型以及缓解这些威胁的 EAP 方法安全声明。
预期通用威胁模型和相应的安全声明将用于定义在特定环境中使用的 EAP 方法要求。[IEEE-802.11i-req] 中提供了此类需求分析的示例。EAP 方法规范中需要安全声明部分，以便可以根据要求评估 EAP 方法。
7.1. 威胁模型 (Threat Model)
EAP 最初是为与 PPP [RFC1661] 一起使用而开发的，后来在 [IEEE-802.1X] 中适配用于有线 IEEE 802 网络 [IEEE-802]。随后，EAP 被提议用于无线 LAN 网络和互联网。在所有这些情况下，攻击者都有可能访问传输 EAP 数据包的链路。
能够访问链路的攻击者可能会进行多种攻击，包括：
[1] 攻击者可能会尝试通过窥探认证流量来发现用户身份。
[2] 攻击者可能会尝试修改或欺骗 EAP 数据包。
[3] 攻击者可能会通过欺骗下层指示或 Success/Failure 数据包、重放 EAP 数据包或生成具有重叠标识符的数据包来发起拒绝服务攻击。
[4] 攻击者可能会尝试通过发起离线字典攻击来恢复密码短语。
[5] 攻击者可能会尝试通过发起中间人攻击来说服对等体连接到不受信任的网络。
[6] 攻击者可能会尝试破坏 EAP 协商以导致选择弱认证方法。
[7] 攻击者可能会尝试利用 EAP 方法中使用的弱密钥派生技术来恢复密钥。
[8] 攻击者可能会尝试利用 EAP 会话完成后随后使用的弱密码套件。
[9] 攻击者可能会尝试对下层密码套件协商执行降级攻击，以确保在 EAP 认证后使用较弱的密码套件。
[10] 充当认证器的攻击者可能会通过带外机制（例如通过 AAA 或下层协议）向 EAP 对等体和/或服务器提供不正确的信息。
7.2. 安全声明 (Security Claims)
为了清楚地阐明 EAP 方法提供的安全性，EAP 方法规范必须 (MUST) 包括安全声明部分，包括以下声明：
[a] 机制。这是对认证技术的声明：证书、预共享密钥、密码、令牌卡等。
[b] 安全声明。这是对方法声称的安全属性的声明，使用第 7.2.1 节中定义的术语：双向认证、完整性保护、重放保护、机密性、密钥派生、字典攻击抵抗、快速重新连接、加密绑定。
[c] 密钥强度。如果方法派生密钥，则必须 (MUST) 估计有效密钥强度。
[d] 密钥层次结构描述。派生密钥的 EAP 方法必须 (MUST) 提供对密钥层次结构规范的引用，或描述如何派生主会话密钥 (MSK) 和扩展主会话密钥 (EMSK)。
[e] 漏洞指示。除了所做的安全声明之外，规范必须 (MUST) 指示第 7.2.1 节中详述的哪些安全声明未被提出。
7.2.1. EAP 方法的安全声明术语
这些术语用于描述 EAP 方法的安全属性：
受保护的密码套件协商 (Protected ciphersuite negotiation)
这是指 EAP 方法协商用于保护 EAP 会话的密码套件以及完整性保护协商的能力。
双向认证 (Mutual authentication)
这是指在互锁交换中，认证器认证对等体并且对等体认证认证器的 EAP 方法。
完整性保护 (Integrity protection)
这是指为 EAP 数据包提供数据源认证和防止信息未授权修改的保护。
重放保护 (Replay protection)
这是指针对 EAP 方法或其消息的重放保护，包括成功和失败结果指示。
机密性 (Confidentiality)
这是指 EAP 消息的加密，包括 EAP Request 和 Response，以及成功和失败结果指示。
密钥派生 (Key derivation)
这是指 EAP 方法派生可导出密钥材料的能力，例如主会话密钥 (MSK) 和扩展主会话密钥 (EMSK)。
密钥强度 (Key strength)
如果有效密钥强度为 N 位，则当前已知的恢复密钥的最佳方法（具有不可忽略的概率）平均需要相当于典型分组密码的 2^(N-1) 次操作的努力。
字典攻击抵抗 (Dictionary attack resistance)
当使用密码认证时，如果当使用密码作为秘密时，该方法不允许基于攻击者字典中密码数量的工作因子的离线攻击，则可以说该方法提供针对字典攻击的保护。
快速重新连接 (Fast reconnect)
在先前已建立安全关联的情况下，更有效地或用更少的往返次数创建新的或刷新的安全关联的能力。
加密绑定 (Cryptographic binding)
EAP 对等体向 EAP 服务器证明单个实体已充当隧道方法内执行的所有方法的 EAP 对等体。
会话独立性 (Session independence)
证明被动攻击（例如捕获 EAP 会话）或主动攻击（包括 MSK 或 EMSK 的泄露）不会导致后续或先前的 MSK 或 EMSK 的泄露。
分片 (Fragmentation)
这是指 EAP 方法是否支持分片和重组。
通道绑定 (Channel binding)
在 EAP 方法内通信完整性保护的通道属性，例如端点标识符，可以与通过带外机制通信的值进行比较。
7.3. 身份保护 (Identity Protection)
身份交换在 EAP 会话中是可选的。因此，可以完全省略身份交换，或者在建立受保护通道后使用方法特定的身份交换。
然而，在支持如 [RFC2607] 所述的漫游的情况下，可能需要在认证会话继续之前定位适当的后端认证服务器。Network Access Identifier (NAI, 网络访问标识符) [RFC2486] 的域部分通常包含在 EAP-Response/Identity 中，以使认证交换能够路由到适当的后端认证服务器。因此，虽然在存在代理或中继的情况下，NAI 的对等体名称部分可以在 EAP-Response/Identity 中省略，但可能需要域部分。
身份响应中的身份可能与 EAP 方法认证的身份不同。在身份隐私的情况下，这可能是有意的。EAP 方法应该 (SHOULD) 在做出访问控制决策时使用经过认证的身份。
7.4. 中间人攻击 (Man-in-the-Middle Attacks)
当 EAP 在省略对等体认证的另一个协议内隧道传输时，存在中间人攻击的潜在漏洞。详细信息请参见 [BINDING] 和 [MITM]。
如第 2.1 节所述，EAP 不允许未隧道化的认证方法序列。如果允许 EAP 认证方法序列，对等体可能无法证明单个实体已作为序列中所有 EAP 方法的认证器。例如，认证器可能终止一个 EAP 方法，然后在对等体不知情或未同意的情况下将序列中的下一个方法转发给另一方。类似地，认证器可能无法证明单个实体已作为序列中所有 EAP 方法的对等体。
在另一个协议内隧道传输 EAP 使得恶意 EAP 认证器能够将 EAP 隧道传输到合法服务器进行攻击。如果隧道协议用于密钥建立但不需要对等体认证，则说服合法对等体连接到它的攻击者将能够将 EAP 数据包隧道传输到合法服务器，成功认证并获得密钥。这允许攻击者成功地将自己建立为中间人，获得对网络的访问权限，以及解密合法对等体和服务器之间数据流量的能力。
此攻击可以通过以下措施缓解：
[a] 在 EAP 隧道机制内要求双向认证。
[b] 要求 EAP 隧道协议和隧道化 EAP 方法之间的加密绑定。在支持加密绑定的情况下，还需要一种机制来防止绕过它的降级攻击。有关加密绑定的更多详细信息，请参见 [BINDING]。
[c] 根据对等体和认证器策略，限制授权在没有保护的情况下使用的 EAP 方法。
[d] 当可以使用单一强方法时，避免使用隧道。
7.5. 数据包修改攻击 (Packet Modification Attacks)
虽然 EAP 方法可能支持每数据包数据源认证、完整性和重放保护，但 EAP 层内不提供支持。
由于标识符 (Identifier) 只有单个八位字节，因此很容易猜测，允许攻击者成功注入或重放 EAP 数据包。攻击者还可以在 EAP 数据包中修改 EAP 头部 (Code、Identifier、Length、Type)，这些头部未受保护。这可能导致数据包被不当丢弃或误解释。
为了保护 EAP 数据包免受修改、欺骗或重放，建议使用支持受保护密码套件协商、双向认证和密钥派生，以及完整性和重放保护的方法。有关这些安全声明的定义，请参见第 7.2.1 节。
方法特定的 MIC 可用于提供保护。如果在 EAP 方法内使用每数据包 MIC，则对等体、认证服务器和不以透传模式运行的认证器必须 (MUST) 验证 MIC。应该 (SHOULD) 记录 MIC 验证失败。MIC 验证失败是否被视为致命错误由 EAP 方法规范确定。
建议 (RECOMMENDED) 提供 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 数据包的消息完整性检查 (MIC)。例如，EAP-TLS [RFC2716] 在 TLS 记录上定义了可以拆分为多个片段的 MIC；在 FINISHED 消息中，MIC 是在先前的消息上计算的。当 MIC 覆盖多个 EAP 数据包时，MIC 验证失败通常被视为致命错误。
在 EAP-TLS [RFC2716] 中，MIC 验证失败被视为致命错误，因为这是 TLS [RFC2246] 中指定的。但是，也可以开发支持每数据包 MIC 的 EAP 方法，并通过静默丢弃违规数据包来响应验证失败。
在本文档中，对 EAP 消息处理的描述假设每数据包 MIC 验证（如果发生）实际上是在发送任何响应或更改接收数据包的主机状态之前执行的。
7.6. 字典攻击 (Dictionary Attacks)
已知 EAP-MD5、MS-CHAPv1 [RFC2433] 和 Kerberos V [RFC1510] 等密码认证算法容易受到字典攻击。MS-CHAPv1 漏洞记录在 [PPTPv1] 中；MS-CHAPv2 漏洞记录在 [PPTPv2] 中；Kerberos 漏洞在 [KRBATTACK]、[KRBLIM] 和 [KERB4WEAK] 中描述。
为了防止字典攻击，建议使用抵抗字典攻击的认证方法（如第 7.2.1 节中定义）。
如果使用已知容易受到字典攻击的认证算法，则可以在受保护的通道内隧道传输会话以提供额外的保护。但是，如第 7.4 节所述，EAP 隧道可能会导致中间人漏洞，因此首选抵抗字典攻击的方法。
7.7. 连接到不受信任的网络 (Connection to an Untrusted Network)
对于支持单向认证的 EAP 方法（例如 EAP-MD5），对等体不认证认证器，使对等体容易受到恶意认证器的攻击。支持双向认证的方法（如第 7.2.1 节中定义）解决了此漏洞。
在 EAP 中，不要求认证是全双工的，也不要求在两个方向上使用相同的协议。在每个方向上使用不同的协议是完全可以接受的。当然，这将取决于所协商的特定协议。但是，通常，完成单个统一的双向认证优于两个单向认证，每个方向一个。这是因为未加密绑定以证明它们是同一会话的一部分的单独认证容易受到中间人攻击，如第 7.4 节所讨论的。
7.8. 协商攻击 (Negotiation Attacks)
在协商攻击中，攻击者试图说服对等体和认证器协商不太安全的 EAP 方法。EAP 不为 Nak Response 数据包提供保护，尽管方法可以在方法特定的 MIC 内包括对 Nak Response 的覆盖。
在每个认证器内或与其关联的，不预期特定命名的对等体将支持多种方法的选择。这将使对等体容易受到协商集合中最不安全方法的攻击。相反，对于每个命名的对等体，应该 (SHOULD) 有一个指示，说明用于认证该对等体名称的确切一个方法。如果对等体需要在不同情况下使用不同的认证方法，则应该 (SHOULD) 使用不同的身份，每个身份标识确切一个认证方法。
7.9. 实现特性 (Implementation Idiosyncrasies)
EAP 与 PPP 和 IEEE 802 等下层的交互高度依赖于实现。
例如，在认证失败时，一些 PPP 实现不会终止链路，而是将网络层协议中的流量限制为过滤的子集，这反过来允许对等体有机会更新秘密或向网络管理员发送邮件指示问题。类似地，虽然认证失败将导致 [IEEE-802.1X] 中受控端口的访问被拒绝，但可能允许在不受控端口上进行有限的流量。
在 EAP 中，没有重试失败认证的规定。但是，在 PPP 中，LCP 状态机可以随时重新协商认证协议，从而允许新的尝试。类似地，在 IEEE 802.1X 中，Supplicant 或 Authenticator 可以随时重新认证。建议用于认证失败的任何计数器在成功认证或随后终止失败链路之前不要重置。
7.10. 密钥派生 (Key Derivation)
对等体和 EAP 服务器可以相互认证并派生密钥。为了提供在随后协商的密码套件中使用的密钥材料，支持密钥派生的 EAP 方法必须 (MUST) 导出至少 64 个八位字节的主会话密钥 (MSK) 和至少 64 个八位字节的扩展主会话密钥 (EMSK)。派生密钥的 EAP 方法必须 (MUST) 在 EAP 对等体和 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 位的随机数，用于 MSK 和 EMSK 的派生。
EAP 方法导出 MSK 和 EMSK，但不导出瞬时会话密钥，以允许 EAP 方法独立于密码套件和介质。EAP 方法导出的密钥材料必须 (MUST) 独立于协商用于保护数据的密码套件。
根据下层，EAP 方法可能在密码套件协商之前或之后运行，因此 EAP 方法可能不知道所选的密码套件。通过提供可用于任何密码套件的密钥材料，EAP 方法可以与广泛的密码套件和介质一起使用。
为了保持算法独立性，派生密钥的 EAP 方法应该 (SHOULD) 支持（并记录）用于保护对等体和服务器之间 EAP 会话的密码套件的受保护协商。这与对等体和认证器之间协商的用于保护数据的密码套件不同。
用于保护数据的瞬时会话密钥 (TSK) 的强度最终取决于 EAP 方法生成的密钥强度。如果 EAP 方法无法产生足够强度的密钥材料，则 TSK 可能会受到暴力攻击。为了使需要强密钥的部署成为可能，支持密钥派生的 EAP 方法应该 (SHOULD) 能够生成有效密钥强度至少为 128 位的 MSK 和 EMSK。
支持密钥派生的方法必须 (MUST) 证明 EAP 密钥层次结构的 MSK 和 EMSK 分支之间的加密分离。在不违反基本加密假设（例如单向函数的不可逆性）的情况下，恢复 MSK 或 EMSK 的攻击者不得 (MUST NOT) 能够以低于暴力的努力水平恢复另一个量。
MSK 的非重叠子串必须 (MUST) 彼此加密分离，如第 7.2.1 节中定义。也就是说，一个子串的知识不得 (MUST NOT) 有助于在不破坏某些硬加密假设的情况下恢复其他子串。这是必需的，因为某些现有密码套件只需将 AAA-Key 拆分为适当长度的片段即可形成 TSK。类似地，EMSK 的非重叠子串必须 (MUST) 彼此加密分离，并且与 MSK 的子串加密分离。
EMSK 保留供将来使用，并且必须 (MUST) 保留在派生它的 EAP 对等体和 EAP 服务器上；不得 (MUST NOT) 将其传输到其他方或与其共享，也不得用于派生任何其他密钥。（此限制将在指定如何使用 EMSK 的未来文档中放宽。）
由于 EAP 不提供显式密钥生命周期协商，EAP 对等体、认证器和认证服务器必须 (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. 弱密码套件 (Weak Ciphersuites)
如果在初始 EAP 认证后，在没有每数据包认证、完整性和重放保护的情况下发送数据包，能够访问介质的攻击者可以注入数据包、翻转现有数据包中的位、重放数据包，甚至完全劫持会话。如果没有每数据包机密性，则可以窥探数据包。
为了防止数据修改、欺骗或窥探，建议使用支持双向认证和密钥派生（如第 7.2.1 节所定义）的 EAP 方法，以及提供每数据包机密性、认证、完整性和重放保护的下层。
此外，如果下层执行密码套件协商，应该理解 EAP 本身不提供该协商的完整性保护。因此，为了避免导致使用较弱密码套件的降级攻击，实现下层密码套件协商的客户端应该 (SHOULD) 防止协商降级。
这可以通过使用户能够配置哪些密码套件作为安全策略是可接受的，或者密码套件协商可以 (MAY) 使用从 EAP 认证派生的密钥材料和下层对等体事先商定的 MIC 算法进行认证。
7.12. 链路层 (Link Layer)
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. 认证器和后端认证服务器的分离
EAP 对等体和 EAP 服务器可以相互认证并为用于保护后续数据流量的密码套件派生 AAA-Key。这在对等体上不会出现问题，因为对等体和 EAP 客户端驻留在同一台机器上；所需要的只是客户端从 EAP 方法导出的 MSK 和 EMSK 派生 AAA-Key，然后将瞬时会话密钥 (TSK) 传递给密码套件模块。
但是，在认证器和认证服务器驻留在不同机器上的情况下，安全性有几个含义。
[a] 认证将发生在对等体和认证服务器之间，而不是在对等体和认证器之间。这意味着对等体无法仅使用 EAP 来验证其正在与之通信的认证器的身份。
[b] 如 [RFC3579] 中所讨论的，认证器依赖 AAA 协议来了解认证会话的结果，并且不查看封装的 EAP 数据包（如果存在）来确定结果。实际上，这意味着认证器和认证服务器之间使用的 AAA 协议必须 (MUST) 支持每数据包认证、完整性和重放保护。
[c] 在 EAP 会话完成后，如果将启用下层安全服务（例如每数据包机密性、认证、完整性和重放保护），则应该 (SHOULD) 在对等体和认证器之间运行安全关联协议，以便在对等体和认证器之间提供双向认证，保证瞬时会话密钥的活跃性，为后续数据提供受保护的密码套件和能力协商，以及同步密钥使用。
[d] 从对等体和认证服务器之间协商的 MSK 和/或 EMSK 派生的 AAA-Key 可以 (MAY) 传输到认证器。因此，需要提供一种机制将 AAA-Key 从认证服务器传输到需要它的认证器。AAA-Key 派生、传输和包装机制的规范不在本文档的范围内。有关 AAA-Key 派生的更多详细信息在 [KEYFRAME] 中提供。
7.14. 明文密码 (Cleartext Passwords)
本规范不定义明文密码认证机制。这一省略是有意的。使用明文密码将允许能够访问传输 EAP 数据包的链路的攻击者捕获密码。
由于封装 EAP 的协议（例如 RADIUS [RFC3579]）可能不提供机密性，EAP 数据包可能随后被封装以通过互联网传输，在那里它们可能被攻击者捕获。
因此，明文密码不能在 EAP 内安全使用，除非封装在具有服务器认证的受保护隧道内。一些相同的风险也适用于没有字典攻击抵抗的 EAP 方法，如第 7.2.1 节中定义。详见第 7.6 节。
7.15. 通道绑定 (Channel Binding)
受损或实现不佳的 EAP 认证器可能会向 EAP 对等体和/或服务器传达不正确的信息。这可能使认证器冒充另一个认证器或通过带外机制传达不正确的信息（例如通过 AAA 或下层协议）。
当 EAP 以透传模式使用时，EAP 对等体通常不验证透传认证器的身份，它只验证透传认证器是否受 EAP 服务器信任。这会产生潜在的安全漏洞。
[RFC3579] 的第 4.3.7 节描述了如果 EAP 透传认证器作为 AAA 客户端试图冒充另一个认证器（例如通过 AAA 协议发送不正确的 NAS-Identifier [RFC2865]、NAS-IP-Address [RFC2865] 或 NAS-IPv6-Address [RFC3162] 属性）如何检测。但是，透传认证器作为 AAA 客户端可以向 AAA 服务器提供正确的信息，同时通过下层协议向 EAP 对等体传达误导性信息。
例如，受损的认证器可能在通过下层协议与 EAP 对等体通信时使用另一个认证器的 Called-Station-Id 或 NAS-Identifier，或者透传认证器作为 AAA 客户端可能通过 AAA 协议向 AAA 服务器提供不正确的对等体 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]。
使用这种受保护的交换，可以将认证器通过带外机制提供的通道属性与 EAP 方法内交换的通道属性进行匹配。如果发现差异，应该 (SHOULD) 记录这些差异；还可以 (MAY) 采取其他行动，例如拒绝访问。
7.16. 受保护的结果指示 (Protected Result Indications)
在 EAP 中，Success 和 Failure 数据包既不被确认也不被完整性保护。当 EAP 在不支持重传或认证状态同步的下层上运行时，结果指示提高了对 Success 和 Failure 数据包丢失的弹性。在诸如 IEEE 802.11 之类的介质中，它提供重传以及通过 [IEEE-802.11i] 中定义的 4 路握手进行认证状态同步，额外的弹性通常只有边际益处。
根据方法和情况，结果指示可能被攻击者欺骗。如果方法支持结果指示，以及"完整性保护"和"重放保护"声明，则称该方法提供受保护的结果指示。支持受保护结果指示的方法必须 (MUST) 指示哪些结果指示受保护，哪些不受保护。
受保护的结果指示不需要防止恶意认证器。在双向认证方法中，要求服务器在对等体接受 Success 数据包之前向对等体进行认证可防止攻击者充当恶意认证器。
但是，攻击者可能在服务器已向对等体进行认证但对等体尚未向服务器进行认证之后伪造 Success 数据包。如果对等体接受伪造的 Success 数据包并尝试在尚未成功向服务器进行认证时访问网络，则可能对对等体发起拒绝服务攻击。在这种攻击之后，如果下层支持失败指示，认证器可以通过提供下层失败指示来与对等体同步状态。详见第 7.12 节。
如果服务器在确定对等体是否已认证认证器之前认证对等体并发送 Success 数据包，则如果认证器未被对等体认证，则可能发生空闲超时。在下层支持的情况下，感知到对等体不存在的认证器可以释放资源。
在支持结果指示的方法中，已认证服务器的对等体在收到服务器成功认证它的指示之前不认为认证成功。类似地，已成功认证对等体的服务器在收到对等体已认证服务器的指示之前不认为认证成功。
为了避免同步问题，在发送成功结果指示之前，发送方希望验证是否存在足够的授权以授予访问权限，尽管如下所述，这并不总是可能的。
虽然结果指示可以实现对等体和服务器之间认证结果的同步，但这并不能保证对等体和认证器将在其授权方面同步或不会发生超时。例如，EAP 服务器可能不知道 AAA 代理做出的授权决定；AAA 服务器可能仅在认证成功完成后检查授权，发现无法授予授权，或者 AAA 服务器可能授予访问权限，但认证器可能由于临时缺乏资源而无法提供它。在这些情况下，只能通过下层结果指示实现同步。
成功指示可以是显式的或隐式的。例如，在方法支持错误消息的情况下，隐式成功指示可以定义为接收特定消息而没有先前的错误消息。失败通常是显式指示的。如第 4.2 节所述，对等体静默丢弃在方法未明确允许发送的点接收的 Failure 数据包。例如，提供自己的错误消息的方法可能要求对等体在接受 Failure 数据包之前接收错误消息。
结果指示的每数据包认证、完整性和重放保护防止欺骗。由于受保护的结果指示需要使用密钥进行每数据包认证和完整性保护，支持受保护结果指示的方法还必须 (MUST) 支持"密钥派生"、"双向认证"、"完整性保护"和"重放保护"声明。
受保护的结果指示解决了一些由于 Success 和 Failure 数据包欺骗而导致的拒绝服务漏洞，但不是全部。EAP 方法通常只能在某些情况下提供受保护的结果指示。例如，错误可能在密钥派生之前发生，因此可能无法保护所有失败指示。也可能在两个方向上不支持结果指示，或者在所有操作模式下都无法实现同步。
例如，在 EAP-TLS [RFC2716] 中，在客户端认证握手中，服务器认证对等体，但不接收对等体是否已认证它的受保护指示。相反，对等体认证服务器并知道服务器是否已认证它。在会话恢复握手中，对等体认证服务器，但不接收服务器是否已认证它的受保护指示。在此模式下，服务器认证对等体并知道对等体是否已认证它。