跳到主要内容

3. TEAP 协议 (TEAP Protocol)

本节说明协议运行方式, 包括 Phase 1 和 Phase 2. TEAP 消息格式见第 4 节, 密码学计算见第 6 节.

3.1. 版本协商 (Version Negotiation)​

TEAP 数据包在 TLS Flags 字段之后包含一个 3-bit Version 字段. 该字段使未来的 TEAP 实现能够向后兼容协议的早期版本. 本规范记录 TEAP version 1 协议, 本规范的实现 MUST 使用设置为 1 的 Version 字段.

版本协商按如下方式进行:

  1. 在使用 EAP type=TEAP 发送的第一个 EAP-Request 中, EAP 服务器 MUST 将 Version 字段设置为它支持的最高版本.

  2. 如果 EAP 对等方支持该协议版本, 它以 EAP type=TEAP 的 EAP-Response 响应, 并包含 TEAP 服务器提出的版本号.

  3. 如果 TEAP 对等方不支持所提出的版本, 但支持较低版本, 它以 EAP type=TEAP 的 EAP-Response 响应, 并将 Version 字段设置为它支持的最高版本.

  4. 如果 TEAP 对等方只支持高于 TEAP 服务器所提出版本的版本, 则无法使用 TEAP. 在这种情况下, TEAP 对等方返回 EAP-Nak, 用于协商不同的 EAP 类型, 或指示没有其他可用 EAP 类型.

  5. 如果 TEAP 服务器不支持 TEAP 对等方提出的版本号, 它 MUST 以 EAP Failure 终止会话, 或协商新的 EAP 类型.

  6. 如果 TEAP 服务器支持 TEAP 对等方提出的版本, 则会话继续使用 TEAP 对等方提出的版本.

版本协商过程保证 TEAP 对等方和服务器将就双方都支持的最新版本达成一致. 如果版本协商失败, 则无法使用 TEAP. 若要继续认证, 需要协商另一种双方都可接受的 EAP 方法.

TEAP 版本不受 TLS 保护, 因而可能在传输途中被修改. 为检测针对 TEAP 版本的降级攻击 (bid-down attack), 对等方 MUST 使用第 4.2.13 节所述的 Crypto-Binding TLV 交换版本协商期间收到的 TEAP 版本号. Crypto-Binding TLV 的接收方 MUST 验证 Crypto-Binding TLV 中收到的版本与该接收方在 TEAP 版本协商中发送的版本一致.

中间结果通过 Intermediate-Result TLV (第 4.2.11 节) 发出信号. 但是, 在检查任何 Intermediate-Result TLV 或 Result TLV 之前, MUST 验证 Crypto-Binding TLV. 如果 Crypto-Binding TLV 因任何原因验证失败, 则这是致命错误, 并按第 3.9.3 节所述处理.

TEAP 的真实成功或失败由取值为 Success 或 Failure 的 Result TLV 传达. 但是, 由于 EAP 以明文 EAP Success 或 Failure 终止, 对等方也会收到明文 EAP Success 或 Failure. 收到的明文 EAP Success 或 Failure MUST 与 Result TLV 中收到的结果一致. 对等方 SHOULD 静默丢弃那些与受保护 Result TLV 中发送的状态不一致的明文 EAP Success 或 Failure 消息.

3.2. TEAP 认证 Phase 1: 隧道建立​

TEAP 依赖 TLS 握手 [RFC8446] 建立经过认证且受保护的隧道. 对等方和服务器提供的 TLS 版本 MUST 为 TLS version 1.2 [RFC5246] 或更高版本. 该版本的 TEAP 实现 MUST 支持以下 TLS 密码套件 (cipher suites):

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

也可以支持其他密码套件. 实现 MUST 实现 [RFC9325] 第 4.2 节中针对 TLS 1.2 推荐的密码套件, 以及 [RFC8446] 第 9.1 节中针对 TLS 1.3 推荐的密码套件.

仅当 Inner Method 提供相互认证 (mutual authentication), 密钥生成, 以及对路径上攻击和字典攻击的抵抗能力时, REQUIRED 才能使用 TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] 等匿名密码套件. MUST NOT 使用不提供机密性的 TLS 密码套件. 在 TEAP Phase 1 期间, TEAP 端点 MAY 协商 TLS 压缩. 在 TLS 隧道建立期间, MAY 使用 TLS 扩展. 例如, Certificate Status Request 扩展 [RFC6066] 和 Multiple Certificate Status Request 扩展 [RFC6961] 可用于利用证书状态协议, 如 Online Certificate Status Protocol (OCSP) [RFC6960], 来检查服务器证书的有效性. MUST 支持 [RFC5746] 中定义的 TLS 重新协商指示.

NOT RECOMMENDED 使用 TLS-PSK. TEAP 并非为 TLS-PSK 而设计, 也没有相关用例, 安全分析或实现. TLS-PSK 可能能与 TEAP 配合工作, 也可能不能, 这取决于具体实现的状态, 因此部署它并无实际益处.

EAP 服务器用包含 TEAP/Start 数据包的 EAP request 发起 TEAP 会话. 该数据包包含置位的 Start (S) bit, 第 3.1 节规定的 TEAP 版本, 以及 authority identity TLV. 初始数据包中的 TLS payload 为空. authority identity TLV (Authority-ID TLV) 用于向对等方提供服务器身份提示, 该提示可能有助于对等方选择适当的凭据. 假设对等方支持 TEAP, 会话继续进行, 对等方发送 EAP type 为 TEAP 的 EAP-Response 数据包, 其中 Start (S) bit 清零, 版本按第 3.1 节规定设置. 该消息封装一个或多个 TLS handshake 消息. 如果 TEAP 版本协商成功, 则 TEAP 会话继续, 直到 EAP 服务器和 EAP 对等方准备进入 Phase 2. 当执行完整 TLS handshake 时, TEAP Phase 2 的第一个 payload MAY 与 server-finished handshake 消息一起发送, 以减少往返次数.

TEAP 实现 MUST 支持在隧道建立期间使用本节规定的 TLS 密码套件进行对等方相互认证. TEAP 对等方不需要作为 TLS 交换的一部分进行认证, 也可以通过 Phase 2 中执行的附加交换进行认证.

TEAP 隧道保护 Phase 2 中交换的对等方身份信息, 防止其泄露到隧道外. 希望为对等方身份提供身份隐私的实现需要仔细考虑 Phase 2 之前在隧道外披露了哪些信息. TEAP 实现 SHOULD 支持立即重新协商 TLS 会话, 以便在当前密码套件保护下发起新的 handshake 消息交换. 这允许在使用 TLS 客户端认证时保护对等方身份. 使用 TLS 重新协商保护隐私的交换示例见附录 C.

3.3. 服务器证书要求​

服务器证书 MUST 包含 subjectAltName 扩展, 其中 dnsName 属性包含 Fully Qualified Domain Name (FQDN) 字符串. 服务器证书 MAY 还包含 SubjectDN, 其包含单个元素 "CN=", 该元素包含服务器的 FQDN. 但是, TEAP 已弃用这种 SubjectDN 用法, 且 [RFC9525] 第 2 节禁止这种用法.

KeyUsage 扩展 MAY 包含, 但不是必需的.

[RFC5280] 中定义的 Extended Key Usage 扩展 MAY 也可以包含, 但不鼓励使用. 系统 SHOULD 优先为 EAP 使用私有 Certification Authority (CA), 而不是公共 CA. 最常用的公共 CA 以 Web 为中心, 这些证书并不总是适合与 EAP 一起使用. 相比之下, 私有 CA 可以为任何目的而设计, 并可限制于企业或其他组织.

3.4. 服务器证书验证​

作为 TLS 协商的一部分, 服务器通常会向对等方出示证书. 在大多数情况下, 需要验证该证书, 但在若干情况下 EAP 对等方不需要执行证书验证:

  • 对等方已将服务器的 End Entity (EE) 证书固定 (pinned) 或直接加载到其信任锚信息 [RFC4949] 中.

  • 对等方正在请求服务器未认证供应 (server unauthenticated provisioning).

  • 对等方确定它将使用经过认证的 Inner Method.

在某些情况下, 如加入网络 (onboarding, 或 "bootstrapping"), 证书验证可以延后. 但是, 一旦完成 onboarding, 仍然 MUST 执行下述验证步骤.

在所有其他情况下, EAP 对等方 MUST 验证服务器证书. 此验证以与 EAP-TLS 相同的方式进行, 相关讨论见 [RFC9190] 第 5.3 节和 [RFC5216] 第 5.3 节. 有关服务器身份验证的进一步指导见 [RFC9525] 第 6 节.

当 EAP 对等方具有 NAI 时, EAP 对等方 MUST 按 [RFC9525] 第 6 节使用 realm 执行 DNS-ID 验证. realm 既用于构造 [RFC9525] 第 6 节中定义的 reference identifiers 列表, 也用作同一节中的 "source domain" 字段.

执行服务器证书验证时, 实现 MUST 还支持 [RFC5280] 中针对已知 trust anchor 验证证书的规则. 此外, 实现 MUST 支持将对等方 NAI 的 realm 部分与服务器证书中类型为 dnsName 的 SubjectAltName 匹配. 但是, 在某些部署中, 这种比较可能不适用或未启用.

在大多数情况下, EAP 对等方在认证过程中没有网络访问能力. 因此, 它无法像 HTTPS 等其他协议那样, 将 EAP 服务器出示的证书中的服务器身份与主机名相关联. 因此, 如果 EAP 对等方没有预配置的 trust anchor, 它将几乎没有方法验证服务器证书.

3.4.1. Phase 1 中发送的客户端证书​

注意, 由于 TLS 1.2 中 TLS 客户端证书以明文发送, 如果需要身份保护, 则可以在第一次服务器认证之后重新协商 TLS 认证. 为此, 服务器通常不会在 server_hello 中请求证书. 随后, 在发送 server_finished 消息之后且在 TEAP Phase 2 之前, 服务器 MAY 发送 TLS hello_request. 这允许对等方通过发送 client_hello 执行客户端认证, 或向服务器发送 no_renegotiation alert, 表示它希望改为继续 TEAP Phase 2. 假设对等方通过发送 client_hello 允许重新协商, 则服务器将以 server_hello, certificate 和 certificate_request 消息响应. 对等方以 certificate, client_key_exchange 和 certificate_verify 消息回复. 由于此重新协商发生在加密 TLS 信道内, 它不会泄露客户端证书细节. 也可以在 TEAP Phase 2 的 TLS 会话内使用 EAP (例如 EAP-TLS) 执行证书认证, 而不是使用 TLS handshake 重新协商.

当使用 TLS 1.3 或更高版本时, RECOMMENDED 在 Phase 1 中发送客户端证书, 而不是通过 Phase 2 和 EAP-TLS 发送. 这样做会减少往返次数. 关于此问题的进一步讨论见下文第 3.6.5 节.

3.5. 恢复 (Resumption)​

对于恢复, [RFC9190] 第 5.7 节讨论了所有 TLS 版本的 EAP-TLS 恢复, 并通过引用纳入本文. [RFC9427] 第 4 节也通过引用纳入本文, 因为它提供了使用 TLS 1.3 时 TLS-based EAP 方法恢复的通用讨论.

本文档只描述 TLS 1.2 及更早版本中使用恢复时的 TEAP 问题. 它还描述 TLS 1.3 中 TEAP 特有的恢复问题.

如果服务器同意恢复会话, 则完全绕过 Phase 2. 如果服务器不同意恢复会话, 则服务器按 [RFC9190] 第 5.7 节拒绝恢复. 随后继续执行完整 handshake. 完整 TLS handshake 完成后, EAP 服务器和对等方 MUST 进入 Phase 2.

所有 TEAP 实现 MUST 支持恢复. 使用恢复可以显著提升认证系统的可扩展性和稳定性. 例如, 在大学等环境中, 用户可能每天多次重新认证, 甚至每小时重新认证. 不实现恢复会使用户数据库负载增加数个数量级, 从而造成不必要的成本.

以下各节说明如何基于服务器端状态或客户端状态恢复 TEAP 会话.

3.5.1. 使用服务器状态的 TLS 会话恢复​

TEAP 会话恢复以 TLS 实现会话恢复的相同方式实现. 为支持会话恢复, 服务器和对等方缓存 Session ID, master secret 和 cipher suite. 对等方通过在其 ClientHello 消息中包含来自先前 TLS handshake 的有效 Session ID 来尝试恢复会话. 如果服务器找到匹配的 Session ID, 且愿意使用指定的会话状态建立新连接, 则服务器将以相同的 Session ID 响应, 并基于 TLS abbreviated handshake 继续进行 TEAP Phase 1 隧道建立.

3.5.2. 使用客户端状态的 TLS 会话恢复​

TEAP 支持基于客户端侧存储状态的会话恢复, 使用 [RFC5077] 和 [RFC9190] 中描述的 TLS SessionTicket 扩展技术.

3.6. TEAP 认证 Phase 2: 隧道内认证​

TEAP 认证的第二部分在 Phase 1 成功完成后立即发生. 即使对等方和认证器都已在 Phase 1 TLS 协商中完成认证, Phase 2 仍会发生. 如果 Phase 1 TLS handshake 失败, Phase 2 MUST NOT 发生, 因为隧道没有成功建立, 这样会破坏安全性. Phase 2 由封装在第 4.2 节定义的 TLV 对象中的一系列请求和响应组成. Phase 2 MUST 始终以第 4.2.13 节所述的 Crypto-Binding TLV 交换和第 3.6.6 节所述的受保护终止交换结束.

如果对等方未在 Phase 1 中认证, TEAP 对等方 SHOULD 在 TLS 连接建立后尽快发送一个或多个 Identity-Hint TLV (第 4.2.20 节). 此信息使 TEAP 服务器能够选择适合该身份的认证类型. 当 TEAP 对等方不提供 Identity-Hint TLV 时, TEAP 服务器不知道对等方支持哪种 Inner Method. 它必须选择一个 Inner Method 并向对等方提出, 而对等方可能拒绝该 Inner Method. 结果是, 对等方认证失败并无法获得网络访问.

TLV 交换包括在受保护隧道内执行零个或多个 inner methods, 如第 3.6.2 节和第 3.6.3 节所述. 如果服务器不希望请求对等方进一步认证, MAY 直接进入受保护终止交换, 而不执行任何内部认证. 服务器 MAY 在受保护隧道内请求一次或多次认证. 每个 Inner Method 完成后, 服务器决定是否开始另一个 Inner Method, 或发送 Result TLV.

实现 MUST 至少支持两个顺序执行的 Inner Methods, 以允许同时执行机器认证和用户认证. 实现 SHOULD 也限制顺序内部认证的数量, 因为没有理由在一次 TEAP 会话中执行大量内部认证.

希望使用自有专有认证方法的实现可以用 EAP-Payload 或 Basic-Password-Auth-Req TLV 替代 Vendor-Specific TLV, 后者承载另一种认证方法. 任何供应商特定认证方法 MUST 支持 Crypto-Binding TLV 的计算, 并 MUST 像其他认证方法一样使用 Intermediate-Result TLV 和 Result TLV.

3.6.1. Inner Method 顺序​

由于第 5 节指出的问题, Inner Methods 的顺序会影响安全性和互操作性.

当认证预计使用多个 Inner Methods 时, 实现 SHOULD 对方法排序, 使派生 Extended Master Session Key (EMSK) 的方法先于任何其他方法使用. 这种顺序有助于将 Inner Method 安全绑定到 TLS 会话, 因而可以防止攻击.

实现 SHOULD 支持 EAP 和基本密码认证作为 inner methods. 支持多种 Inner Method 类型 (User 和 Machine) 的实现 MUST 支持这些方法的任意顺序或组合. 也就是说, 明确允许 "mix and match" Inner Methods.

例如, 服务器可以向对等方请求用户认证, 而对等方返回机器认证 (反之亦然). 如果服务器配置为接受机器认证, 它 MUST 接受该响应. 如果认证成功, 则根据本地策略, 服务器 SHOULD 继续再次请求用户认证.

类似地, 配置为支持多种 Inner Method 类型 (User 和 Machine) 的对等方可以返回与服务器请求不同的方法. 对等方通常这样做是为了以更高安全性排序 Inner Methods. 关于此问题的进一步讨论见第 6.2.3 节.

但是, 对等方和服务器 MUST NOT 假定任一方会跳过 Inner Methods 或其他 TLV 交换, 因为另一方可能具有不同的安全策略. 对等方可能漫游到一个要求符合不同认证策略的网络, 或者对等方可能通过使用第 4.2.9 节定义的 Request-Action TLV 请求服务器执行附加操作 (例如 channel binding).

每个 Inner Method 的完成通过 Intermediate-Result TLV 发出信号. 当 Intermediate-Result TLV 指示失败时, SHOULD 还使用尽可能具体的错误代码包含 Error TLV. Intermediate-Result TLV 可以伴随另一个 TLV, 表示服务器希望执行后续认证. 当所有 Inner Methods 完成后, 服务器 MUST 发送指示成功或失败的 Result TLV, 而不是发送承载 Inner Method 的 TLV.

3.6.2. 内部 EAP 认证​

EAP [RFC3748] 禁止在单个 EAP 会话中使用多个认证方法, 以限制路径上攻击的漏洞. TEAP 通过支持内部 EAP 交换的密码学保护, 以及将内部 EAP 方法绑定到受保护隧道的密码学绑定, 来应对路径上攻击. Inner Methods 按序列串行执行. 本版本 TEAP 不支持同时并行发起多个 Inner Methods. Inner Methods 不需要彼此不同. 例如, EAP-TLS ([RFC5216] 和 [RFC9190]) 可以作为内部方法运行两次, 第一次使用机器凭据, 随后第二次使用用户凭据.

当 EAP 用作 Inner Method 时, EAP 消息承载在第 4.2.10 节定义的 EAP-Payload TLV 中. 注意, 在此用例中, TEAP 只是 EAP 的承载者, 很像 RADIUS 是 EAP 的承载者. 完整 EAP 状态机照常运行, 并通过 EAP-Payload TLV 承载. 每个不同的 EAP 认证 MUST 作为独立 EAP 状态机管理.

因此, TEAP 服务器 MUST 以 EAP-Request/Identity (承载于 EAP-Payload TLV 中) 开始 EAP 认证. 但是, TEAP 服务器 MUST NOT 以 EAP Success 或 EAP Failure 数据包结束 EAP 会话. 它改用 Intermediate-Result TLV.

隧道中的每个 EAP 认证完成后, 服务器 MUST 发送 Intermediate-Result TLV 指示该认证结果. 当结果指示成功时, 它 MUST 伴随 Crypto-Binding TLV. 对等方 MUST 响应 Intermediate-Result TLV 以指示自己的结果. 类似地, 成功时对等方 MUST 让该 TLV 伴随自己的 Crypto-Binding TLV. Crypto-Binding TLV 在第 4.2.13 节和第 6.3 节进一步讨论. Intermediate-Result TLV 可以与指示后续认证的其他 TLV 一起包含, 或与受保护终止交换中使用的 Result TLV 一起包含.

如果对等方和服务器都指示成功, 则认证被视为成功. 如果任一方指示失败, 则认证被视为失败. 一个 EAP 认证失败并不总是意味着整体认证失败. 如果一个 Inner Method 失败, 服务器可以尝试使用不同方法 (EAP 或密码) 认证对等方.

3.6.3. 内部密码认证​

认证服务器 (AS) 通过发送第 4.2.14 节定义的 Basic-Password-Auth-Req TLV 发起密码认证. 如果对等方希望参与密码认证, 则以 Basic-Password-Auth-Resp TLV 响应, 其中包含第 4.2.15 节定义的用户名和密码. 如果它不希望执行密码认证, 则以 Negative Acknowledgment (NAK) TLV 响应, 表示拒绝 Basic-Password-Auth-Req TLV.

这里定义的基本密码认证在功能上类似于 EAP-TTLS [RFC5281] 使用的内部密码认证. 它共享类似的安全性和风险分析.

MAY 使用多轮密码认证请求和响应, 以支持某些 "housekeeping" 功能, 例如在用户被视为已认证之前更改密码或 PIN. MAY 也使用多轮来分别传送用户密码和一次性密码, 如 Time-Based One-Time Passwords (TOTPs) [RFC6238].

实现 MUST 限制密码认证的往返次数. 使用一到两次往返是合理的. 更多往返很可能产生问题, SHOULD 避免.

会话中收到的第一个 Basic-Password-Auth-Req TLV MUST 包含 prompt, 对等方将其显示给用户. 后续认证轮次 SHOULD 包含 prompt, 但并不总是必要.

当对等方第一次收到 Basic-Password-Auth-Req TLV 时, 它应允许用户同时输入用户名和密码, 然后将其放入 Basic-Password-Auth-Resp TLV. 如果对等方在同一认证会话中收到后续 Basic-Password-Auth-Req TLV, 它 MUST NOT 提示输入用户名, 而 MUST 只允许用户输入密码. 对等方 MUST 将第一个 Basic-Password-Auth-Resp TLV 中使用的用户名复制到所有后续 Basic-Password-Auth-Resp TLV.

服务器 MUST 在多轮密码过程中跟踪用户名, 并在身份从一个 Basic-Password-Auth-Resp TLV 到下一个发生变化时拒绝认证. 用户 (或机器) 没有理由在认证中途改变身份.

在隧道内收到 Basic-Password-Auth-Resp TLV 后, 服务器 MUST 发送 Intermediate-Result TLV 指示结果. 对等方 MUST 响应 Intermediate-Result TLV 以指示其结果. 如果结果指示成功, Intermediate-Result TLV MUST 伴随 Crypto-Binding TLV. Crypto-Binding TLV 在第 4.2.13 节和第 6.3 节进一步讨论.

Intermediate-Result TLV 可以与指示后续认证的其他 TLV 一起包含, 或与受保护终止交换中使用的 Result TLV 一起包含.

NOT RECOMMENDED 在 TEAPv1 中使用 [RFC5421] 定义的 EAP-FAST-GTC, 因为 EAP-FAST-GTC 不符合 [RFC3748] 中定义的 EAP-GTC. 实现应改用本规范定义的密码认证 TLV.

3.6.4. EAP-MSCHAPv2​

如果将 EAP-MSCHAPv2 [KAMATH] 用作内部 EAP 方法, 则 MUST 使用 [RFC5422] 第 3.2.3 节定义的 EAP-FAST-MSCHAPv2 变体, 而不是 [MSCHAP] 中定义的派生方式.

EAP-MSCHAPv2 与 EAP-FAST-MSCHAPv2 的区别在于, 当 EAP-MSCHAPv2 Master Session Key (MSK) 用作 TEAP 的 Inner Method Session Keys (IMSKs) 时, 其第一个和第二个 16 octets 会互换.

3.6.5. Inner Methods 的限制​

实现 SHOULD 将允许的内部 EAP 方法限制为小集合, 如 EAP-TLS 和 EAP-MSCHAPv2 的 EAP-FAST-MSCHAPv2 变体. 这些 EAP 方法是 TEAP 中最常支持的内部方法, 且已知可在多个实现之间互操作.

其他 EAP 方法, 如 EAP-pwd, EAP-SIM, EAP-AKA 或 EAP-AKA', 可以在 TEAP 隧道内使用. 任何同时派生 MSK 和 EMSK 的 EAP 方法都很可能可作为 TEAP 的 Inner Method 工作, 因为 EAP-TLS 具有这种行为且能够工作. 只派生 MSK 的 EAP 方法也应能工作, 因为 EAP-FAST-MSCHAPv2 具有这种行为且能够工作. 其他 EAP 方法未经测试, 可能能工作也可能不能.

MUST NOT 将 PEAP [PEAP], EAP-TTLS [RFC5281] 和 EAP-FAST [RFC4851] 等隧道化 EAP 方法用于内部 EAP 认证. 没有理由为了保护密码交换而拥有多层 TLS.

[RFC3748] 第 5 节定义的 EAP 方法, 如 MD5-Challenge, One-Time Password (OTP) 和 Generic Token Card (GTC), 不派生 MSK 或 EMSK, 并且易受路径上攻击. OTP 和 GTC 方法的构造使这种攻击相关性较低, 因为发送的信息通常是一次性令牌. 但是, EAP-OTP 和 EAP-GTC 相比第 3.6.3 节定义的基本密码认证没有优势, 后者同样不会执行 Inner Method 到 TLS 会话的 crypto-binding. 因此, 这些 EAP 方法不适合作为 TEAP 内的 Phase 2 方法.

其他 EAP 方法使用范围较小, 且极有可能无法作为 TEAP 的内部 EAP 方法工作.

为防御路径上攻击, TEAP 实现 MUST NOT 允许使用未执行 Inner Method 到 TLS 会话 crypto-binding 的内部 EAP 方法.

实现 MUST NOT 允许 EAP-TLS 等内部 EAP 方法执行恢复. 如果需要认证用户或机器, 它应使用提供完整认证的方法. 如果用户或机器需要执行恢复, 它可以先执行一次完整认证, 然后依赖外层 TLS 会话进行恢复. 此限制也适用于所有能够隧道化其他 EAP 方法的 TLS-based EAP 方法. 因此, 本文档更新 [RFC9427].

通常, 在 TEAP 等 TLS-based EAP 方法内部使用非 TLS-based EAP 方法的原因是隐私. 许多旧 EAP 方法可能泄露用户身份信息, 在受保护 TLS 隧道内运行该方法可防止这些泄露.

Phase 2 中允许 EAP-TLS 有两个用例. 第一个用例是使用 TLS 1.2 时, 因为客户端证书不像 TLS 1.3 那样受到保护. 因此, 当外层 TEAP 交换使用 TLS 1.3 时, RECOMMENDED 在 Phase 1 中发送客户端证书, 而不是在 Phase 2 中执行 EAP-TLS. 这种行为会简化认证交换, 且比在 TEAP 内执行 EAP-TLS 使用更少往返.

Phase 2 中 EAP-TLS 的第二个用例是用户和机器都使用客户端证书进行认证. 由于 TLS 只允许出示一个客户端证书, Phase 1 只能使用一个证书. 第二个证书随后通过 Phase 2 中的 EAP-TLS 出示.

对于基本密码认证, RECOMMENDED 此方法仅用于交换一次性密码. EAP-pwd ([RFC5931] 和 [RFC8146]) 等基于密码的 EAP 方法的存在, 使大多数明文密码交换不再必要. [RFC8146] 对 EAP-pwd 的更新允许它与以 "salted" 形式存储密码的数据库一起使用, 这极大提高了安全性.

当没有 Inner Method 提供 EMSK 时, Crypto-Binding TLV 提供的保护很少, 因为它无法通过 TLS-PRF 将内部 EMSK 绑定到 TLS 会话. 因此, TEAP 会话将易受路径上主动攻击. 实现和部署 SHOULD 采用 [RFC7029] 第 3.2 节中描述的各种缓解策略. 实现还需要实现第 6.1 节中描述的 Inner Method 排序, 以完全防止路径上攻击.

3.6.6. 受保护终止和确认式结果指示​

成功的 TEAP Phase 2 会话 MUST 始终以成功的 Crypto-Binding TLV 和 Result TLV 交换结束. TEAP 服务器可以在 TEAP Phase 2 中不发起任何 Inner Methods 的情况下发起 Crypto-Binding TLV 和 Result TLV 交换. 最终 Result TLV 交换后, TLS 隧道终止, 服务器发送明文 EAP Success 或 EAP Failure. 实现 TEAP 的对等方 MUST NOT 在对等方和服务器达到同步的受保护结果指示之前接受明文 EAP Success 或 Failure 数据包.

Crypto-Binding TLV 交换用于证明对等方和服务器都参与了隧道建立和认证序列. 它还提供对 TEAP 类型, 协商版本, 以及 TLS 隧道建立之前交换的 Outer TLVs 的验证. 除下文所述情况外, 无论是否存在 Inner Method, Crypto-Binding TLV MUST 在最终 Result TLV 交换之前交换并验证. 在一个或多个 Inner Methods 的序列中, 每次成功认证之后 MUST 包含 Crypto-Binding TLV 和 Intermediate-Result TLV 以执行密码学绑定. 服务器可以将最终 Result TLV 与 Intermediate-Result TLV 和 Crypto-Binding TLV 一起发送, 以表示其结束会话的意图. 如果对等方不再需要服务器执行任何操作, 它将以指示成功的 Result TLV 响应, 并在必要时伴随 Crypto-Binding TLV 和 Intermediate-Result TLV. 然后服务器拆除隧道并发送明文 EAP Success 或 EAP Failure.

如果对等方从服务器收到指示成功的 Result TLV, 但其认证策略未得到满足 (例如, 它要求运行某个特定认证机制), 它可以使用 Request-Action TLV 请求服务器执行进一步操作. Request-Action TLV 与 Status 字段一起发送, Status 字段指示如果所请求的操作未获准, 对等方预期的 EAP Success/Failure 结果. Action 字段的值指示对等方希望下一步执行什么. Request-Action TLV 的格式和值在第 4.2.9 节定义.

服务器收到 Request-Action TLV 后, 可以根据其策略处理该请求或忽略它. 如果服务器忽略该请求, 它继续终止隧道, 并基于对等方 Request-Action TLV 的 Status 字段发送明文 EAP Success 或 Failure 消息. 如果服务器接受并处理该请求, 它继续执行所请求的操作. 会话以 Result TLV 交换完成. Result TLV 可以与完成所请求操作的 TLV 一起包含.

Phase 2 的错误处理见第 3.9.3 节.

3.7. 确定 Peer-Id 和 Server-Id​

Peer-Id 和 Server-Id [RFC5247] 可以基于 TEAP 隧道创建或认证期间使用的凭据类型确定. 在多次对等方认证的情况下, 需要导出所有已认证对等方身份及其对应身份类型 (第 4.2.3 节). 在多次服务器认证的情况下, 需要导出所有已认证服务器身份.

当 X.509 证书用于对等方认证时, Peer-Id 由对等方证书中的 subject 和 subjectAltName 字段确定. 如 [RFC5280] 所述:

subject 字段标识与 subject public key 字段中存储的公钥关联的实体. subject name MAY 承载于 subject 字段和/或 subjectAltName 扩展中. ... 如果 subject 命名信息只存在于 subjectAltName 扩展中 (例如, 只绑定到 email 地址或 URI 的密钥), 则 subject name MUST 为空序列, 且 subjectAltName 扩展 MUST 为 critical.

当 subject 字段非空时, 它 MUST 包含 X.500 distinguished name (DN).

如果运行内部 EAP 认证方法, 则 Peer-Id 从该内部 EAP 认证方法获得.

当服务器使用 X.509 证书建立 TLS 隧道时, Server-Id 以与上述 Peer-Id 类似的方式确定, 例如服务器证书中的 subject 和 subjectAltName 字段定义 Server-Id.

3.8. TEAP 会话标识符​

对于 TLS 1.2 及更早版本, EAP 会话标识符 [RFC5247] 使用 Phase 2 开始时来自 Phase 1 外层隧道的 tls-unique 构造, 如 [RFC5929] 第 3.1 节所定义. Session-Id 定义如下:

Session-Id = teap_type | tls-unique

其中:

  • | 表示串接.

  • teap_type 是分配给 TEAP 的 EAP Type.

  • tls-unique = Phase 2 开始时来自 Phase 1 外层隧道的 tls-unique, 如 [RFC5929] 第 3.1 节所定义.

TLS 1.3 的 Session-Id 派生见 [RFC9427] 第 2.1 节.

3.9. 错误处理​

TEAP 使用以下概括的错误处理规则:

  1. 外层 EAP 数据包层中的错误按第 3.9.1 节定义处理.

  2. TLS 层中的错误通过 TEAP 两个阶段中的 TLS alert 消息传达.

  3. Intermediate-Result TLV 承载 TEAP Phase 2 中各个 Inner Methods 的成功或失败指示. Phase 2 中 EAP 会话内部的错误预期由各个 EAP 认证方法处理.

  4. Inner TLV 规则违规使用 Result TLV 与 Error TLV 一起处理.

  5. tunnel-compromised 错误 (由 Crypto-Binding 失败或缺失导致的错误) 使用 Result TLV 和 Error TLV 处理.

3.9.1. 外层错误​

TEAP 外层数据包层上的错误按以下方式处理:

  1. 如果 Outer TLVs 无效或包含未知值, 则忽略它们.

  2. 如果其他字段 (version, length, flags 等) 与本规范不一致, 则忽略整个 TEAP 数据包.

3.9.2. TLS 层错误​

如果 TEAP 服务器在 TLS handshake 或 TLS 层的任何位置检测到错误, 服务器 SHOULD 发送一个 TEAP request, 其中封装包含适当 TLS alert 消息的 TLS record, 而不是立即终止 TEAP 交换, 以便允许对等方向用户告知失败原因. TEAP 对等方 MUST 对 alert 消息发送 TEAP response. 对等方发送的 EAP-Response 数据包 SHOULD 包含一个零长度消息的 TEAP response. 无论客户端说什么, 服务器 MUST 以 EAP Failure 数据包终止 TEAP 交换.

如果 TEAP 对等方在 TLS 层的任何位置检测到错误, TEAP 对等方 SHOULD 发送一个 TEAP response, 其中封装包含适当 TLS alert 消息的 TLS record, 该 response 包含零长度消息. 随后服务器 MUST 如前一段所述以 EAP failure 终止会话.

虽然 TLS 1.3 [RFC8446] 允许重新启动 TLS 会话, 但尚不清楚这在 TEAP 中何时有用 (或会被使用). 致命 TLS 错误会导致 TLS 会话失败. 非致命 TLS 错误很可能可以完全忽略. 因此, TEAP 实现 MUST NOT 允许 TLS 重启.

3.9.3. Phase 2 错误​

Phase 2 处理期间可能出现大量错误情况. 本节描述这些错误以及推荐的处理方式.

当服务器从对等方收到带有 fatal Error TLV 的 Result TLV 时, 它 MUST 终止 TLS 隧道并以 EAP Failure 回复.

当对等方从服务器收到带有 fatal Error TLV 的 Result TLV 时, 它 MUST 以指示失败的 Result TLV 响应. 服务器 MUST 丢弃从对等方收到的任何数据并以 EAP Failure 回复. 对等方的最终消息是 EAP 状态机所要求的, 其唯一作用是允许服务器以 EAP Failure 回复对等方.

以下项目更详细地描述具体错误和处理:

Fatal Error processing a TLV: : 在 Phase 2 TLV 处理期间, 对等方或服务器只要在 TLS 层之外发现致命错误, 就 MUST 发送失败的 Result TLV 和 Error TLV, 并使用尽可能具体的错误代码.

Fatal Error during TLV Exchanges: : 对于涉及交换序列处理的错误, 如违反 TLV 规则 (例如多个 EAP-Payload TLV), 错误代码为 Unexpected TLVs Exchanged.

Fatal Error due to tunnel compromise: : 对于涉及隧道受损的错误, 如 Crypto-Binding TLV 验证失败, 错误代码为 Tunnel Compromise Error.

Non-Fatal Error due to Inner Method: : 如果运行 Inner Method 时出现非致命错误, 接收方 SHOULD NOT 静默丢弃 Inner Method 交换. 相反, 它 SHOULD 以 Error TLV 回复, 并使用尽可能具体的错误代码.

如果没有匹配特定问题的错误代码, 则 SHOULD 使用值 Inner Method Error (1001). 此响应明确指示当前 Inner Method 处理期间发生错误. 收到非致命 Error TLV 的一方 MAY 决定改为启动一个新的不同 Inner Method, 或发回 Result TLV 以终止 TEAP 认证会话.

3.10. 分片 (Fragmentation)​

EAP 数据包分片见 [RFC5216] 第 2.1.5 节. TEAP 对分片没有特殊处理.

3.11. 对等方请求的服务​

若干 TEAP 操作, 包括服务器未认证供应, 证书供应和 channel binding, 依赖对等方信任 TEAP 服务器. 如果对等方信任所提供的服务器证书, 则服务器已认证.

通常, 此认证过程涉及对等方通过验证出示证书的服务器持有私钥, 并确认该证书命名的实体是预期服务器, 从而将证书验证到 trust anchor. 当使用第 3.2 节中的过程恢复一个对等方和服务器先前已相互认证的会话时, 也会发生服务器认证. 或者, 如果内部 EAP 方法提供相互认证以及 MSK 和/或 EMSK, 则服务器被视为已认证. Inner Method MUST 还通过 Compound Message Authentication Code (MAC) 提供密码学绑定, 如第 4.2.13 节所述. 此问题在第 3.11.3 节进一步描述.

TEAP 对等方 MUST 跟踪是否已发生服务器认证. 当无法认证服务器时, 对等方 MUST NOT 向其请求任何服务, 如证书供应 (第 3.11.1 节).

除非对等方请求服务器未认证供应, 否则它 MUST 认证服务器并使当前认证会话失败. 如果无法认证服务器, 则认证会话失败.

当 Inner Method 认证多个参与方时会出现额外复杂性, 例如同时向 EAP 服务器认证对等方机器和对等方用户. 根据认证方式不同, 可能只有部分参与方对此认证有信心. 例如, 如果使用强共享秘密来相互认证用户和 EAP 服务器, 而机器不能信任用户不会向攻击者泄露共享秘密, 则机器可能无法确信 EAP 服务器就是已认证的一方. 在这些情况下, 评估对等方是否应请求这些服务或服务器是否应提供这些服务时, 需要考虑参与认证的各方.

服务器 MUST 也在提供这些服务之前认证对等方. 否则会向未经认证且可能恶意的对等方发送供应数据, 这可能对安全产生负面影响.

当设备通过 TEAP 供应时, 任何后续授权 MUST 基于已认证凭据执行. 也就是说, Phase 1 中可能没有凭据 (或只有匿名凭据), 但 Phase 2 中将传递或供应凭据. 如果后续授权基于 Phase 1 身份执行, 设备可能获得错误授权. 如果改为基于已认证凭据执行授权, 设备将获得正确类型的网络访问.

正确授权也必须应用于任何恢复, 如 [RFC9190] 第 5.7 节所述. 但是, 由于 TEAP 中凭据可能发生变化, 新凭据 MUST 与 session ticket 关联. 如果无法建立此关联, 则服务器 MUST 使当前会话的任何 session tickets 失效. 此失效将强制任何后续连接进行完整重新认证, 届时正确授权将与任何 session ticket 关联.

注意, 重新供应设备的行为本质上与任何初始供应无法区分. 设备通过标准供应机制进行认证并获得新凭据. 唯一需要注意的是, 除非已知旧凭据已过期, 或新凭据已验证可用, 否则设备 SHOULD NOT 丢弃旧凭据.

3.11.1. 隧道内证书供应​

TEAP 通过使用 PKCS#10 和 PKCS#7 TLV 分别执行 [RFC5272] 中的 Simple PKI Request/Response 来支持对等方证书供应. 对等方使用 PKCS#10 CertificationRequest [RFC2986] 发送 Simple PKI Request, 该请求编码到 PKCS#10 TLV 的主体中 (见第 4.2.17 节). TEAP 服务器只在 Inner Method 已运行并在证书签发前提供了对等方身份证明之后, 才使用 PKCS#7 [RFC2315] unsigned (即 degenerate) "Certificates Only" 消息发送 Simple PKI Response, 该消息编码到 PKCS#7 TLV 的主体中 (见第 4.2.16 节).

为通过在签名证书请求中包含当前已认证 TLS 会话特有的信息来提供身份关联和持有证明 (proof-of-possession), 生成请求的对等方 SHOULD 从 TLS 子系统获取 "Channel Bindings for TLS" [RFC5929] 中定义的 tls-unique 值. TEAP 对等方从获取 tls-unique 值, 到生成包含当前 tls-unique 值的 Certification Signing Request (CSR), 再到 TEAP 服务器随后验证该值之间的操作, 是 "Channel Bindings for TLS" ([RFC5929] 第 3.1 节) 中互操作性说明所述同步互操作机制保护的 "application protocol phases during which application-layer authentication occurs". 执行重新协商时, MUST 使用 TLS "secure_renegotiation" [RFC5746].

tls-unique 值按 [RFC4648] 第 4 节规定进行 base-64 编码, 生成的字符串放入 certification request challengePassword 字段 ([RFC2985] 第 5.4.1 节). challengePassword 字段限制为 255 octets ([RFC5246] 第 7.4.9 节指出没有现有密码套件会因该限制产生问题). 如果证书请求中未嵌入 tls-unique 信息, 则 challengePassword 字段 MUST 为空, 以指示对等方未包含可选 channel-binding 信息 (提交的任何值都会由服务器作为 tls-unique 信息验证).

服务器 SHOULD 验证 tls-unique 信息. 这确保签名证书请求由已认证且持有私钥的 TEAP 对等方出示.

[RFC5272] 的 Simple PKI Request/Response 生成和处理规则 SHALL 适用于 TEAP, 错误条件除外. 出错时, TEAP 服务器 SHOULD 使用尽可能具体的错误代码以 Error TLV 响应. 它 MAY 忽略生成错误的 PKCS#10 请求.

3.11.2. 证书内容和用途​

仅验证对等方向认证器提供的 CSR 来自已认证用户是不够的. 认证器或 CA 在签发任何证书之前还应检查 CSR 本身.

CSR 的格式复杂且包含大量信息. 这些信息可能不正确, 例如用户声称错误的物理地址, email 地址等. RECOMMENDED 供应这些证书的系统验证 CSR 包含预期数据, 且不包含非预期数据. 例如, 如果 CSR 包含未知字段, 或已知字段包含非预期或无效值, CA 可以拒绝签发证书. CA 可以出于任何原因修改或拒绝特定 CSR, 包括本地站点策略. 我们注意到, "CA" 中的 "A" 表示 "Authority", 而 "CSR" 中的 "R" 表示 "Request". 并没有要求 CA 签署提交给它的所有 CSR.

一旦 EAP 对等方收到已签名证书, 该对等方可能会在 TEAP 之外的 TLS 上下文中被使用或滥用. 例如, 证书可以与 EAP-TLS 一起使用, 甚至与 HTTPS 一起使用. NOT RECOMMENDED 将通过 TEAP 供应的证书用于任何非 TEAP 用途. 强制执行此限制的一种方法是使用不同 CA (或不同 intermediate CA) 为不同用途签发证书. 例如, TLS-based EAP 方法可以共享一个 CA, 甚至为不同 TLS-based EAP 方法使用不同 intermediate CA. HTTPS 服务器可以使用完全不同的 CA. 随后可配置不同协议, 使其只验证来自其首选 CA 的客户端证书, 这将防止对等方在预期用例之外使用证书.

限制证书用途的另一种方法是为其供应 Extended Key Purpose 字段 [RFC7299] 的适当值. 例如, 可以使用 id-kp-eapOverLAN [RFC4334] 值指示该证书仅用于 EAP.

很难给出比上述内容更详细的建议. 每个 CA 或组织都可能有自己的本地策略, 规定证书中允许或禁止什么. 本文档能做的是强调这些问题, 并让读者意识到必须处理这些问题.

3.11.3. 服务器未认证供应模式​

在 Server Unauthenticated Provisioning Mode 中, Phase 1 建立未经认证的隧道, 对等方和服务器在 Phase 2 中协商一个或多个 Inner Method. 该 Inner Method MUST 支持相互认证, 提供密钥派生, 并能抵抗路径上攻击和字典攻击等攻击. 在大多数情况下, 该 Inner Method 将是 EAP 认证方法. 满足这些条件的 Inner Methods 示例包括 EAP-pwd [RFC5931] 和 EAP-EKE [RFC6124], 但不包括 EAP-FAST-MSCHAPv2.

该供应模式允许在对等方 Phase 1 期间无法认证服务器时引导对等方. 这包括两种情况: 协商的密码套件不提供认证, 以及协商的密码套件提供认证但对等方由于某种原因无法验证服务器身份.

Phase 2 中 Inner Method 成功完成后, 对等方和服务器交换 Crypto-Binding TLV, 以将 Inner Method 与外层隧道绑定, 并确保未发生路径上攻击尝试.

支持 Server Unauthenticated Provisioning Mode 是可选的. 使用 Server Unauthenticated Provisioning Mode 时 RECOMMENDED 使用密码套件 TLS_DH_anon_WITH_AES_128_CBC_SHA, 但 MAY 支持其他匿名密码套件, 只要 TLS pre-master secret 由两个对等方共同贡献生成.

当 Server Unauthenticated Provisioning Mode 未使用强 Inner Method 时, 攻击者可能执行路径上攻击. 实际上, Server Unauthenticated Provisioning Mode 的安全问题类似于在没有 TLS 保护的明文环境中运行 Inner Method. 隧道中的所有信息都应假定可被攻击者看到并修改.

实现 SHOULD 在 Server Unauthenticated Provisioning Mode 中交换最少数据. 它们应改用该模式建立安全/已认证隧道, 然后使用该隧道执行任何所需数据交换.

RECOMMENDED 客户端实现和部署在任何可能情况下认证 TEAP 服务器. 认证服务器意味着客户端可以安全供应, 攻击者没有机会窃听连接.

注意, 服务器未认证供应只能在 TLS 1.2 及更早版本中使用匿名密码套件. 这些密码套件已在 TLS 1.3 中弃用 ([RFC8446] 附录 C.5). 对于 TLS 1.3, 服务器 MUST 提供证书, 对等方通过不验证证书链或其任何内容来执行服务器未认证供应.

3.11.4. Channel Binding​

[RFC6677] 定义了用于 EAP 的 channel bindings, 用于解决 "lying NAS" 和 "lying provider" 问题. 该过程让 EAP 对等方在 EAP 认证方法保护下, 向 Authentication, Authorization, and Accounting (AAA) server 提供认证器所提供服务的特征信息. 这允许服务器验证认证器向对等方提供的信息是否与从该认证器收到的信息以及存储的关于该认证器的信息一致.

TEAP 使用第 4.2.7 节定义的 Channel-Binding TLV 支持 EAP channel binding. 如果 TEAP 服务器希望向对等方请求 channel-binding 信息, 它发送空的 Channel-Binding TLV 来指示请求. 对等方通过发送包含 [RFC6677] 定义的 channel-binding 消息的 Channel-Binding TLV 来响应该请求. 服务器验证 channel-binding 消息, 并发回带有结果代码的 Channel-Binding TLV. 如果服务器没有发起 channel-binding 请求, 而对等方仍希望向服务器发送 channel-binding 信息, 则可以将 Request-Action TLV 与 Channel-Binding TLV 一起使用. 对等方 MUST 只在成功认证服务器并建立受保护隧道后发送 channel-binding 信息.

最后于 更新