跳到主要内容

8. 安全考虑事项 (Security Considerations)

TEAP 的设计重点面向无线介质, 而无线介质本身天然适合被窃听. 在有线介质中, 攻击者必须获得对有线介质的物理访问权. 而无线介质允许任何人在信息通过空中传输时捕获这些信息, 从而发起被动攻击. 因此, 不能假定存在物理安全性, 安全漏洞的风险也大得多. 用于 TEAP 安全评估的威胁模型定义在 EAP [RFC3748] 中.

8.1. 相互认证和完整性保护 (Mutual Authentication and Integrity Protection)​

总体而言, TEAP 通过建立安全隧道来保护内部方法 (Inner Method), 从而提供消息保护和完整性保护. 机密性和完整性保护由 TLS 定义, 并提供与 TLS 使用强熵共享主密钥时相同的安全强度. 在 TEAP 隧道内执行的密钥生成型内部方法的完整性通过计算 Crypto-Binding TLV 来验证. 这确保隧道端点与内部方法端点相同.

在执行服务器未认证的预配 (server unauthenticated provisioning) 时, TEAP 要求内部预配方法同时提供对等方和服务器认证.

8.2. 方法协商 (Method Negotiation)​

与任何经过协商的 EAP 一样, 用于建议备用 EAP 认证方法的 EAP NAK 消息是在未受保护的状态下发送的, 因此容易遭受伪造. 在未受保护的 EAP 方法协商期间, 攻击者可以把 NAK 数据包注入为主动攻击, 以便降级到较弱的认证形式, 例如 EAP-MD5, 后者只提供单向认证且不派生密钥. 对等方和服务器都应当具有方法选择策略, 以防止协商降级到较弱的方法. 内部方法协商能够抵抗攻击, 因为它受到已建立且经过相互认证的 TLS 隧道保护. 选择 TEAP 作为认证方法并不会限制可能使用的内部方法, 因此在可用时应当选择 TEAP.

攻击者无法轻易确定所使用的内部方法, 也许只能通过流量分析做到这一点. 同样重要的是, 对等方实现需要限制凭据与未经认证或未经授权的服务器一起使用.

8.3. Phase 1 服务器和 Phase 2 服务器的分离 (Separation of Phase 1 and Phase 2 Servers)​

不推荐 (NOT RECOMMENDED) 将 TEAP Phase 1 与 Phase 2 会话分离. 如果允许 Phase 1 会话在不同于 Phase 2 会话的服务器上终止, 而这两个服务器之间又缺少适当的信任关系以及对其间协议的保护, 就可能引入漏洞. 一些漏洞包括:

  • 身份保护丧失

  • 离线字典攻击

  • 缺少策略执行

  • 路径上主动攻击 (如 [RFC7029] 所述)

在某些情况下, Phase 1 服务器和 Phase 2 服务器之间可能存在信任关系, 例如在校园内, 或同一公司两个办公室之间. 在这些情况下, 向两个服务器之间的实体暴露对等方的内部身份和凭据并不会造成危险. 此时可以 (MAY) 使用不提供 TEAP 端到端保护的代理解决方案. TEAP 加密/解密网关至少必须 (MUST) 支持 IPsec, TLS 或类似保护, 以便为网关与 EAP 服务器之间的会话部分提供机密性. 此外, 将 TEAP 服务器与内部服务器分离, 会使基于内部方法 MSK 的密码绑定可能被挫败, 如 [RFC7029] 所述. 如果内部方法派生 EMSK, 则此威胁会得到缓解, 因为如上文第 6 节所述, TEAP 使用 Crypto-Binding TLV 通过 TLS-PRF 将内部 EMSK 绑定到 TLS 会话.

另一方面, 如果内部方法不派生 EMSK, 例如使用密码认证或未认证预配时, 此威胁仍然存在. 因此, 实现需要按照上文第 3.6.5 节的讨论限制内部方法的使用.

8.4. 已知漏洞和协议缺陷的缓解 (Mitigation of Known Vulnerabilities and Protocol Deficiencies)​

TEAP 解决了一些 EAP 认证方法中的已知缺陷和弱点. 通过使用对等方和服务器之间的共享秘密建立安全隧道, TEAP 支持:

  • 每个数据包的机密性和完整性保护

  • 用户身份保护

  • 对通知消息的更好支持

  • 受保护的内部方法协商, 包括 EAP 方法

  • 内部方法的排序, 包括 EAP 方法

  • 强相互派生 MSK

  • 已确认的成功/失败指示

  • 通过会话恢复实现更快的重新认证

  • 缓解离线字典攻击

  • 缓解路径上攻击

  • 缓解某些拒绝服务攻击

应当注意, 在 TEAP 中, 与许多其他认证协议一样, 对手可以发送错误流量来扰乱协议, 从而发起拒绝服务攻击. 这是许多认证或密钥协商协议中的问题, 因此在 TEAP 中也需要指出.

TEAP 的设计重点是保护通常依赖弱凭据的内部方法, 例如基于密码的秘密. 在这个意义上, TEAP 认证通过保护基于弱凭据的内部方法, 缓解了若干漏洞, 例如离线字典攻击. 这种保护基于 TLS 中的强密码算法, 用于提供消息机密性和完整性. 用于保护的派生密钥依赖对等方和服务器提供的强随机挑战, 以及具有强熵的已建立密钥. 实现在生成随机数时应当遵循 [RFC4086] 中的建议.

8.4.1. 用户身份保护和验证 (User Identity Protection and Verification)​

初始身份请求/响应交换以明文发送, 不受 TEAP 保护. 通常, 身份响应中的 NAI [RFC7542] 只对用于把认证请求路由到正确 EAP 服务器的信息域有用. 这意味着身份响应可以包含匿名身份, 并且只包含域信息. 在其他情况下, 如果存在其他方式来建立请求的目标域, 则可以完全省略身份交换. 在任何情况下, 中介都不应信任身份响应中的任何身份信息, 因为该信息未经认证, 并且可能与已认证身份没有任何关联. TEAP 实现不应尝试比较初始明文 EAP Identity 响应数据包中披露的任何身份与 Phase 2 中认证的身份.

当服务器已认证时, 在 TEAP 隧道建立之后发送的身份请求/响应交换会受到保护, 可防止攻击者修改和窃听. 对于服务器未认证的预配, 外部 TLS 会话提供的安全性很少, 因而预配方法必须改为提供此类保护.

当客户端证书在 Phase 1 中于 TLS 隧道外发送时, 对等方必须 (MUST) 将 Identity-Type 作为 Outer TLV 包含在内, 以表示该客户端证书对应的身份类型. 此外, 当客户端证书在 TLS 隧道外发送时, 服务器必须 (MUST) 继续执行 Phase 2. 如果没有 Phase 2 数据, 则 EAP 服务器必须 (MUST) 拒绝该会话.

与客户端证书机密性有关的问题已在上文第 3.4.1 节讨论.

注意, Phase 2 数据可以只是值为 Success 的 Result TLV, 以及一个 Crypto-Binding TLV. 如 [RFC9190] 第 2.1.1 节所述, 此 Phase 2 数据充当受保护的成功指示.

8.5. 字典攻击抵抗 (Dictionary Attack Resistance)​

TEAP 的设计重点是保护通常依赖弱凭据的内部方法, 例如基于密码的秘密. TEAP 通过允许建立相互认证的加密 TLS 隧道来缓解离线字典攻击, 该隧道提供机密性和完整性, 用于保护基于弱凭据的内部方法.

TEAP 允许使用不易遭受字典攻击的内部方法, 例如 EAP-pwd, 从而缓解字典攻击.

TEAP 实现可以通过限制特定身份的认证失败次数, 缓解在线 "brute force" 字典尝试.

8.5.1. 防范路径上攻击 (Protection Against On-Path Attacks)​

TEAP 通过几种方式防范路径上攻击:

  1. 在 TEAP 认证 Phase 1 建立安全 TLS 隧道期间, 使用证书或会话票据对对等方和服务器进行相互认证.

  2. 当 TLS 隧道未被保护时, 在密码绑定交换中以及在第 6 节所述由内部方法导出的密钥材料生成中, 使用内部方法生成的密钥, 前提是内部方法是密钥生成型方法.

如果客户端允许连接到不受信任的服务器, 例如客户端没有正确验证服务器证书, 则 TEAP 密码绑定并不保证防范路径上攻击. 如果 TLS 密码套件仅从会话一方贡献的秘密数据派生主密钥, 例如基于 RSA 密钥传输的密码套件, 则即使在隧道内执行了强内部方法, 能够诱使客户端连接并参与认证的攻击者也可以向另一台服务器冒充该客户端. 如果 TLS 密码套件从会话双方贡献的秘密派生主密钥, 例如基于 Diffie-Hellman 的密码套件, 则在使用强内部方法时, 密码绑定可以检测会话中的攻击者.

当客户端不验证服务器且内部方法不生成 EMSK 时, TEAP 密码绑定并不保证防范路径上攻击. 关闭此漏洞的唯一方式是定义 TEAPv2, 它将使用不同的密码绑定派生.

8.6. 防范伪造的明文 EAP 数据包 (Protecting Against Forged Cleartext EAP Packets)​

通常, EAP Success 和 EAP Failure 数据包以明文发送, 攻击者可以伪造这些数据包而不被检测到. 伪造的 EAP Failure 数据包可用于试图诱使 EAP 对等方断开连接. 伪造的 EAP Success 数据包可用于试图让对等方相信认证已经成功, 即使认证器尚未向对等方认证自身.

通过提供消息机密性和完整性, TEAP 可以防范这些攻击. 一旦对等方和认证服务器 (Authentication Server, AS) 启动 TEAP 认证 Phase 2, 符合规范的 TEAP 实现必须 (MUST) 静默丢弃所有明文 EAP 消息, 除非 TEAP 对等方和服务器都已经使用受保护机制指示成功或失败. 受保护机制包括 TLS alert 机制以及第 3.6.6 节所述的受保护终止机制.

TEAP 隧道内的成功/失败决策表示 TEAP 认证会话的最终决策. 在受保护机制已经指示成功/失败结果之后, TEAP 对等方可以处理未受保护的 EAP Success 和 EAP Failure 消息. 但是, 如果未受保护的 EAP Success 或 Failure 消息中的结果与受保护机制的结果不匹配, 对等方必须 (MUST) 忽略该消息.

为遵守 [RFC3748], 服务器会发送明文 EAP Success 或 EAP Failure 数据包来终止 EAP 会话. 但是, 由于 EAP Success 和 EAP Failure 数据包不会重传, 最后一个数据包可能丢失. 尽管受 TEAP 保护的 EAP Success 或 EAP Failure 数据包不应当是 TEAP 会话中的最后一个数据包, 但基于上述条件, 这种情况仍可能发生. 因此, EAP 对等方不应依赖未受保护的 EAP Success 和 Failure 消息.

8.7. 明文密码的使用 (Use of Cleartext Passwords)​

TEAP 可以在 Basic-Password-Auth-Resp TLV 中承载明文密码. 实现应当谨慎保护这些数据. 例如, 通常不应记录密码, 并且当不再需要密码数据时, 应当从内存中安全擦除这些数据.

8.8. 意外或非预期行为 (Accidental or Unintended Behavior)​

由于 TEAP 很复杂, 并且从 [RFC7170] 到出现任何实质性实现之间间隔很长, 协议中存在许多意外或非预期行为.

第一个问题是使用了 EAP-FAST-MSCHAPv2 而不是 EAP-MSCHAPv2. 虽然 [RFC7170] 定义 TEAP 使用 EAP-MSCHAPv2, 但一个或多个早期实现者改用了 EAP-FAST-MSCHAPv2. 本文档面临的选择是定义一个使用 EAP-MSCHAPv2 的新版 TEAP, 或者记录已实现的行为. 这里选择的是记录正在运行的代码.

第 6.2.5 节讨论的问题可能具有安全影响, 但尚未执行分析. 第 6.2 节中选择使用特殊的 "all zero" IMSK 是为了简化, 但也可能具有负面安全影响.

Crypto-Binding TLV 的定义意味着最终 Crypto-Binding TLV 值可能不依赖 MSK 和 EMSK 的所有先前值. 这一限制可能具有负面安全影响, 但同样尚未执行分析.

我们建议将 TEAP 修订为 TEAP version 2, 以便解决这些问题. 目前已有提议希望更好地派生各种密钥材料和密码绑定派生. 但是, 为了记录正在运行的代码, 我们发布本文档, 同时承认仍有改进空间.

8.9. 隐式挑战 (Implicit Challenge)​

某些使用挑战/响应机制的认证协议依赖并非由认证服务器生成的挑战材料, 因此这些材料可能需要特殊处理. 对于 EAP-TTLS, 这些挑战定义在 [RFC5281] 第 11.1 节.

在 EAP-MSCHAPv2 中, 认证器向请求方 (supplicant) 发出挑战. 然后, 请求方将该挑战与密码进行哈希运算, 并把响应转发给认证器. 响应还包括一个 Peer-Challenge, 它由请求方创建. 由于该挑战是随机的, 它并不与 TLS 隧道相关联, 因而协议可能容易遭受重放攻击.

Crypto-Binding TLV 提供对中介的防护, 但不提供对重放攻击的防护. 我们建议任何 TEAPv2 规范都修正此问题.

8.10. 安全声明 (Security Claims)​

本节提供 EAP [RFC3748] 所需的安全声明要求.

声明 (Claim)值 (Value)
Auth. mechanism基于证书, 基于共享秘密, 以及各种隧道化认证机制.
Cipher Suite negotiationYes
Mutual authenticationYes
Integrity protectionYes. 在 TEAP 隧道内执行的任何方法都受到完整性保护. 隧道外的明文 EAP 头部不受完整性保护. 服务器未认证预配提供自身的保护机制.
Replay protectionYes
ConfidentialityYes
Key derivationYes
Key strength见下文 Note 1.
Dictionary attack prot.见下文 Note 2.
Fast reconnectYes
Cryptographic bindingYes
Session independenceYes
FragmentationYes
Key HierarchyYes
Channel bindingYes

Notes:

  • Note 1. [BCP86] 就适当的密钥长度提供建议. 美国国家标准与技术研究院 (National Institute for Standards and Technology, NIST) 也在 [NIST-SP-800-57] 中就适当的密钥长度提供建议. [RFC3766] 第 6 节建议, 对于给定的以比特为单位的攻击抵抗级别, 使用以下必需 RSA 或 Diffie-Hellman (DH) 模数长度以及数字签名算法 (Digital Signature Algorithm, DSA) 子群长度, 单位为比特. 根据下表, 为提供 112-bit 等效密钥强度, 需要 2048-bit RSA 密钥:

    攻击抵抗 (bits)RSA 或 DH 模数长度 (bits)DSA 子群长度 (bits)
    70947129
    801228148
    901553167
    1001926186
    1504575284
    2008719383
    25014596482

    Table 8

  • Note 2. 当使用安全内部方法时, TEAP 防范离线字典攻击. TEAP 通过限制特定身份的认证失败次数来防范在线字典攻击.

最后于 更新