跳到主要内容

6. 密码学计算 (Cryptographic Calculations)

本节给出的定义已知可与所有实现配合工作, 但如上文第 5 节所述, 这只适用于少数内部方法 (Inner Method). 为了避免在一个已经复杂的过程中引入额外复杂性, 这些定义按其适用于所有可能的 Inner Methods 来给出.

我们注意到, 已有一些互操作实现基于这些定义编写, 并且支持 EAP-MSCHAPv2 和 EAP-TLS 以外的 Inner Methods. 因此, 尽管存在已知问题, 完整记录 TEAPv1 的操作仍然有用. 我们只是提醒实现者, 上文第 5 节未列出的 Inner Methods 可能只适用于现有 TEAPv1 实现的一个子集.

对于密钥派生 (key derivation) 和密码绑定 (crypto-binding), TEAP 使用底层 TLS 会话中协商出的伪随机函数 (Pseudorandom Function, PRF) 和 MAC 算法. 由于这些算法取决于 TLS 版本和密码套件 (cipher suite), TEAP 实现需要一种机制来确定特定会话正在使用的版本和密码套件. 随后, 实现可以使用这些信息确定要使用哪个 PRF 和 MAC 算法.

6.1. TEAP 认证阶段 1: 密钥派生​

在 TEAPv1 中, TLS master secret 按 TLS 中规定的方式生成. 如果使用会话恢复, 则 master secret 按 [RFC5077] 中的说明获得.

TEAPv1 使用 [RFC5705] 中定义的 TLS Keying Material Exporters 来派生 session_key_seed, 如下所示:

session_key_seed = TLS-Exporter(
                   "EXPORTER: teap session key seed",, 40)

导出过程中不使用上下文数据.

TEAP 认证阶段 2 对话使用 session_key_seed, 既将 Inner Method(s) 以密码学方式绑定到隧道, 也生成最终的 TEAP 会话密钥. 其他 TLS 密钥材料按 [RFC8446] 中的定义派生和使用.

6.2. 中间复合密钥派生​

由于 TEAP 可以运行多个 Inner Methods, 因此需要一种方式将每个 Inner Method 以密码学方式绑定到 TLS 隧道, 并将每个方法以密码学方式绑定到前一个方法. 这种绑定通过派生若干中间密钥, 并在 Crypto-Binding TLV 中交换该信息来完成.

多个因素使密钥派生变得复杂. 内部方法可以派生 MSK, 也可以像基本密码那样不派生 MSK. Inner Method 可以派生 EMSK, 也可能不派生 EMSK, 或者某些 EAP 类型可能为对等方和服务器派生不同的 EMSK. 必须考虑所有这些情况, 并给出对等方和服务器如何实现互操作的建议.

TEAP 使用若干中间密钥来计算最终的 MSK 和 EMSK. 为了阐明下文给出的详细定义和派生, 这里先给出简要概述. 由于每个 Inner Method 可能派生 MSK 或不派生 MSK, 也可能派生 EMSK 或不派生 EMSK, 因此需要分别为 MSK 和 EMSK 计算中间密钥. 在本概述中, 我们只从高层描述这些派生, 并说明 MSK/EMSK 问题会在下文更详细的文本中处理.

对于每个 Inner Method, 我们派生一个 IMSK. 该密钥取决于内部密钥 (MSK 或 EMSK). 随后, 该 IMSK 通过 TLS-PRF 与 TLS 会话关联, 以派生内部方法复合密钥 (Inner Method Compound Key, IMCK). IMCK 用于生成复合 MAC 密钥 (Compound MAC key, CMK). CMK 与 TEAP 协商中的各种数据混合, 以创建 Crypto-Binding 属性中的 Compound MAC 字段. 该 TLV 将 Inner Method 以密码学方式绑定到受保护隧道, 并绑定到已协商的其他字段. 密码绑定可防止路径上攻击 (on-path attacks).

随后, 该 Inner Method 的 IMCK 与来自先前 Inner Methods 的密钥混合, 从上文派生出的 TEAP 阶段 2 session_key_seed 开始, 为本轮生成安全 IMCK (Secure IMCK, S-IMCK). 最后一轮的 S-IMCK 随后用于为 TEAP 派生 MSK 和 EMSK.

我们通过从 0 开始计数 Inner Methods 来区分各 Inner Methods 的密钥, 并使用索引 "j" 表示任意内部方法. 例如, IMCK[0] 是第一个, 即 "0" Inner Method 的 IMCK. 虽然 TEAPv1 目前限制为一个或两个 Inner Methods (j=0 或 j=0,1), 后续更新可以允许更多 Inner Method 交换.

6.2.1. 生成内部方法会话密钥​

每个 Inner Method 都生成一个 IMSK, 它取决于 EMSK (优先) 或 MSK (如果存在), 否则全为零. 我们将 Inner Method "j" 的 IMSK 称为 IMSK[j].

如果 Inner Method 支持导出 EMSK, 则 IMSK 应当从 EMSK 派生, EMSK 在 [RFC5295] 中定义. 派生过程中不使用可选数据参数.

上述派生并非一项要求, 因为已知某些 TEAP 对等方实现也不会从 EMSK 派生 IMSK, 而只从 MSK 派生 IMSK. 为了兼容这些实现, 此处不强制要求使用 EMSK.

某些 EAP 方法还可能让对等方和服务器派生不同的 EMSK. 在这种情况下强制基于 EMSK 进行派生会阻止互操作, 因为依赖 EMSK 的 Crypto-Binding TLV 内容随后无法由任一方验证. 除非该方法有办法协商 EMSK 的派生方式, 并有办法发出信号表明对等方和服务器已派生相同的 EMSK, 否则这些方法不应从 EMSK 派生 IMSK.

对于这些 EAP 方法, 推荐实现采用更简单的方法: 忽略 EMSK, 始终从 MSK 派生 IMSK. 这种方法安全性较低, 因为 IMSK 不再将 Inner Method 以密码学方式绑定到 TLS 隧道. 更好的解决方案是建议 TEAP 部署应当避免这类方法.

从第 j 个 EMSK 派生 IMSK[j] 的方式如下:

IMSK[j] = First 32 octets of TLS-PRF(
       EMSK[j],
       "[email protected]",
       0x00 | 0x00 | 0x40)

其中:

  • "|" 表示拼接.

  • TLS-PRF 在 [RFC5246] 中定义如下:

PRF(secret, label, seed) = P_<hash>(secret, label | seed)
  • secret 是来自第 j 个 Inner Method 的 EMSK, 使用的 usage label 是 "[email protected]", 由标签 "[email protected]" 的 ASCII 值组成 (不含引号), seed 由 "\0" 空分隔符 (0x00) 和 [RFC5295] 中规定的网络字节序 2-octet 无符号整数长度 64 octets (0x00 | 0x40) 组成.

如果 Inner Method 不支持导出 EMSK 但会导出 MSK, 则 IMSK 从该 Inner Method 的 MSK 复制. 如果 MSK 长于 32 octets, 则 IMSK 从前 32 octets 复制, MSK 的其余部分被忽略. 如果 MSK 短于 32 octets, 则 IMSK 从 MSK 复制, IMSK 中剩余数据用零填充到 32 octets 长度. IMSK[j] 随后就是该派生值.

如果 Inner Method 不提供 MSK 或 EMSK, 例如使用基本密码认证时, 或者没有运行任何 Inner Method 时, 则 MSK 和 IMSK[j] 都设为全零 (即 IMSK[j] = MSK = 32 octets of 0x00s).

请注意, 使用全零 MSK 会使 TEAP 面临第 8.3 节讨论的路径上攻击. 因此, 不推荐使用无法生成 MSK 或 EMSK 的 Inner Methods. 这些方法只应与另一个能够生成 MSK 或 EMSK 的 Inner Method 结合使用.

还推荐 TEAP 对等方对 Inner Methods 进行排序, 使生成 EMSK 的方法先于不生成 EMSK 的方法执行. 以这种方式排序 Inner Methods 可确保第一个 Inner Method 检测任何路径上攻击者, 因而后续使用的任何 Inner Method 都是安全的.

例如, 阶段 2 可以同时执行使用 EAP-TLS 的机器认证, 随后通过 Basic Password Authentication TLVs 执行用户认证. 在这种情况下, 使用 EAP-TLS 可在发送用户密码之前检测到攻击者.

不过, 对等方和服务器两端可能不具备相同的 EMSK 导出能力. 为了在防止降级攻击的同时保持最大灵活性, 使用以下机制.

6.2.2. 生成 S-IMCK​

一旦确定 IMSK[j], 它会通过 TLS-PRF 与上一轮的密钥 S-IMCK[j-1] 混合. 该混合会派生新的密钥 IMCK[j]. 随后, 该密钥用于派生本轮的 S-IMCK[j] 和本轮的 CMK[j].

S-IMCK 的派生如下:

S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
     IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
          "Inner Methods Compound Keys",
          IMSK[j])
     S-IMCK[j] = first 40 octets of IMCK[j]
     CMK[j] = last 20 octets of IMCK[j]

其中 TLS-PRF 是作为 TLS 握手 [RFC5246] 一部分协商出的 PRF (如上所述). 值 j 指对应的 Inner Method 1 到 n. S-IMCK[0] 的特殊值用于引导计算, 可以在 TLS 连接建立后且任何内部方法运行前完成.

在实践中, 使用 MSK 或 EMSK 的要求意味着实现必须跟踪 IMCK[j] 的两个独立派生: 一个取决于 MSK, 另一个取决于 EMSK. 也就是说, 我们既有从 MSK 派生的值:

  • IMSK_MSK[j]

  • S-IMCK_MSK[j]

  • CMK_MSK[j]

也有从 EMSK 派生的值:

  • IMSK_EMSK[j]

  • S-IMCK_EMSK[j]

  • CMK_EMSK[j]

在成功交换 Crypto-Binding TLVs 结束时, 会根据客户端 Crypto-Binding TLV 中包含的 Compound MAC 值选择单个 S-IMCK[j]. 如果包含 EMSK Compound MAC, 则 S-IMCK[j] 取自 S-IMCK_EMSK[j]. 否则, S-IMCK[j] 取自 S-IMCK_MSK[j].

6.2.3. 安全选择 Inner Methods​

为了进一步保护 TEAP, 实现可以通过谨慎排序 Inner Methods 来提高安全性. 使用多个 Inner Methods 时, 实现应当选择一种顺序, 使首先使用的 Inner Method 是能够派生 EMSK 的方法.

对于 EAP 服务器, 它可以选择一个派生 EMSK 的方法作为第一个 Inner Method. 由于 EAP 中 Inner Methods 的顺序在其他方面并不重要, 接收该请求的对等方支持任何选定顺序.

对于 EAP 对等方, 它可以选择如何响应服务器对特定认证类型的请求. 对等方可以忽略该请求, 并返回一个派生 EMSK 的 Inner Method. 同样, 由于 EAP 中 Inner Methods 的顺序在其他方面并不重要, 接收该响应的服务器支持任何选定顺序. 一旦更安全的认证成功, 服务器随后请求另一种认证类型, 对等方可以用所选认证类型响应.

实现还可以提供配置标志, 策略或文档化建议, 用于控制所使用的 Inner Methods 类型或验证其顺序. 这些配置允许实现和管理员控制其面对路径上攻击者时的安全暴露面.

实现可以允许管理员配置 TEAP, 以强制执行以下安全检查:

  • 验证首先使用的 Inner Method 是能够派生 EMSK 的方法. 如果未做到这一点, 可以返回致命错误.

  • 验证如果任何 Inner Method 派生 EMSK, 则该方法收到的 Crypto-Binding TLV 包含 EMSK Compound MAC. 如果已派生 EMSK 但未看到 EMSK Compound MAC, 可以返回致命错误.

这些建议的目标是强制使用 EMSK Compound MAC, 以保护 TEAP 会话免受路径上攻击者影响. 如果不强制执行这些建议, 则 TEAP 会话容易受到攻击.

这些建议大多不是规范性的, 因为已知某些现有实现并不遵循它们. 相反, 这些建议用于告知新的实现者和管理员与该主题相关的问题.

6.2.4. 管理和计算 Crypto-Binding​

Inner Method 成功完成并派生内部密钥后, 服务器向对等方发送 Crypto-Binding TLV. 如果 Inner Method 失败, 服务器不会发送 Crypto-Binding TLV.

对等方通过应用第 4.2.13 节中定义的规则来验证 Crypto-Binding TLV. 如果验证通过, 对等方以自己的 Crypto-Binding TLV 响应, 服务器随后验证该 TLV. 如果任一时刻验证失败, 作出该判定的一方终止会话.

Crypto-Binding TLV 通常与其他 TLVs 一起发送, 这些 TLVs 指示中间或最终结果, 或开始协商新的 Inner Method. 该协商在其他方面不影响 Crypto-Binding TLV.

虽然第 4.2.13 节定义了 Crypto-Binding TLV 中存在 Compound MAC 字段, 但并未描述这些字段的派生和管理. 该派生很复杂, 因此与其他密钥派生一起放在本节.

以下文本定义服务器和对等方如何计算, 发送, 然后验证 Crypto-Binding TLV 中的 Compound MAC 字段. 根据 Inner Method 和站点策略, Crypto-Binding TLV 可以只包含 MSK Compound MAC (Flags=2), 只包含 EMSK Compound MAC (Flags=1), 或同时包含两个 Compound MAC (Flags=3). TEAP 会话的每一方都遵循自己的过程来计算和验证 Compound MAC 字段.

Crypto-Binding TLV 内容的确定会针对每个 Inner Method 分别进行. 如果任一时刻 Compound MAC 验证失败, 作出判定的一方会按第 3.9.3 节所述返回致命错误.

我们假定每个对等方和服务器都有站点策略, 这些策略可能要求也可能不要求使用 MSK Compound MAC 和/或 EMSK Compound MAC. 这些策略可以对所有 Inner Methods 全局强制执行, 也可以分别对每个 Inner Method 强制执行. 当已知 EAP 方法总是生成 EMSK 时, 这些策略可以自动启用, 否则可以配置.

服务器通过以下方式发起 crypto-binding: 确定要使用哪些 Compound MAC, 计算其值, 将所得 Compound MAC 放入 Crypto-Binding TLV, 然后将其发送给对等方.

随后, 服务器执行以下步骤:

  • 如果已知 Inner Method 只生成 MSK, 或者服务器策略是不使用 EMSK Compound MACs:

    • 服务器使用该 Inner Method 的 MSK 计算 MSK Compound MAC. 服务器不使用 EMSK Compound MAC 字段 (Flags=2).

    否则, EMSK 可用.

  • 如果服务器策略允许使用 MSK Compound MAC:

    • 发送方同时计算 MSK Compound MAC 和 EMSK Compound MAC (Flags=3).

    否则, 服务器策略不允许使用 MSK Compound MAC:

    • 服务器只计算 EMSK Compound MAC (Flags=1).

对等方验证从服务器收到的 Crypto-Binding TLV. 随后, 对等方通过确定要使用哪些 Compound MAC, 计算其值, 将所得 Compound MAC 放入 Crypto-Binding TLV, 然后发送给服务器, 以自己的 crypto-binding 响应作答. 该过程的结果要么是致命错误, 要么是一个或多个被放入 Crypto-Binding TLV 并发送给服务器的 Compound MAC.

随后, 对等方执行以下步骤:

  • 如果对等方站点策略要求使用 EMSK Compound MAC:

    • 对等方检查 Flags 字段是否指示存在 EMSK Compound MAC (Flags=1 或 3). 如果 Flags 字段为任何其他值, 对等方返回致命错误.

    • 对等方检查 Inner Method 是否已派生 EMSK. 如果没有, 对等方返回致命错误.

    否则, 对等方站点策略不要求使用 EMSK Compound MAC, EMSK 可以存在也可以不存在.

  • 如果已知 Inner Method 只生成 MSK 而不生成 EMSK:

    • 对等方检查 Flags 字段是否指示只存在 MSK Compound MAC (Flags=2). 如果 Flags 字段为任何其他值, 对等方返回致命错误.

    否则, MSK 存在, EMSK 可以存在也可以不存在, 并且对等方允许使用 EMSK Compound MAC. 对等方可能已收到一个或两个 Compound MACs (Flags=1,2,3). 任何存在的 Compound MAC 都会被验证. 如果某个特定 Compound MAC 不存在, 对等方不采取进一步操作. 如果存在意外的 Compound MAC, 对等方也不采取进一步操作.

    请注意, 由于先前已验证 Flags 字段 (第 4.2.13 节), 现在必须存在至少一个 Compound MAC (Flags=1,2,3).

  • 如果对等方已收到 MSK Compound MAC, 它会验证该 MAC, 并在验证失败时返回致命错误.

  • 如果 EMSK 可用且对等方已收到 EMSK Compound MAC, 它会验证该 MAC, 并在验证失败时返回致命错误.

对等方通过以下方式创建 crypto-binding 响应: 确定要使用哪些 Compound MAC, 计算其值, 将所得 Compound MAC 放入 Crypto-Binding TLV, 然后发送给服务器.

随后, 对等方执行以下步骤.

  • 如果对等方从服务器收到 MSK Compound MAC:

    • 由于 MSK 始终存在, 此步骤始终可行. 对等方为响应计算 MSK Compound MAC (Flags=2).

  • 如果对等方站点策略要求使用 EMSK Compound MAC:

    • 对等方先前执行的步骤确保 EMSK 存在且服务器已发送 EMSK Compound MAC. 对等方为响应计算 EMSK Compound MAC. Flags 字段会被更新 (Flags=1,3).

    否则, 如果 EMSK 存在:

    • 对等方为响应计算 EMSK Compound MAC. Flags 字段会被更新 (Flags=1,3).

服务器通过以下步骤处理来自对等方的响应:

  • 如果服务器站点策略要求使用 EMSK Compound MAC:

    • 服务器检查 Flags 字段是否指示存在 EMSK Compound MAC (Flags=1 或 3). 如果 Flags 字段为任何其他值, 服务器返回致命错误.

    • 服务器检查 Inner Method 是否已派生 EMSK. 如果没有, 服务器返回致命错误.

  • 如果已知 Inner Method 只生成 MSK 而不生成 EMSK:

    • 服务器检查 Flags 字段是否指示只存在 MSK Compound MAC (Flags=2). 如果 Flags 字段为任何其他值, 服务器返回致命错误.

    否则, MSK 存在, EMSK 可以存在也可以不存在. 服务器可能已收到一个或两个 Compound MACs (Flags=1,2,3). 任何存在的 Compound MAC 都会被验证. 如果某个特定 Compound MAC 不存在, 服务器不采取进一步操作. 如果存在意外的 Compound MAC, 服务器也不采取进一步操作.

  • 如果服务器已收到 MSK Compound MAC, 它会验证该 MAC, 并在验证失败时返回致命错误.

  • 如果 EMSK 可用且服务器已收到 EMSK Compound MAC, 它会验证该 MAC, 并在验证失败时返回致命错误.

上述步骤结束后, 服务器要么使用另一个 Inner Method 继续认证, 要么返回 Result TLV.

6.2.5. 非预期副作用​

在本文档的早期草案中, 密钥派生说明存在一些问题, 这些问题直到 TEAP 已被广泛实现后才被发现. 为了支持互操作实现, 需要记录这些问题.

如上所述, 某些内部 EAP 方法会派生 MSK, 但不会派生 EMSK. 当没有 EMSK 时, 因而无法从它派生 IMCK_EMSK[j]. 多个实现当时选择简单地定义为:

IMCK_EMSK[j] = IMCK_EMSK[j - 1]

该定义可以通过在数据结构中保留 IMCK_EMSK 的缓存副本来非常简单地实现. 如果 EMSK 可用, 则通过上文定义的 TLS-PRF 函数从它更新 IMCK_EMSK. 如果 EMSK 不可用, 则 IMCK_EMSK 值保持不变.

本文档的早期草案并未明确预见这种行为. 相反, 它似乎是在缺少 EMSK 这一限制下实现上述派生时产生的偶然结果. 为完整记录 TEAP, 此处明确指出这种行为.

另一个非预期后果出现在 Crypto-Binding TLV 的计算中. 该 TLV 包含依赖当前认证方法的 MSK 和 EMSK 的 compound MACs. 当当前方法不提供 EMSK 时, Crypto-Binding TLV 不包含依赖 EMSK 的 compound MAC. 当当前方法不提供 MSK 时, Crypto-Binding TLV 包含一个依赖特殊 "all zero" IMSK 的 compound MAC, 如前文所述.

该定义的结果是, 内部 TEAP 交换中的最终 Crypto-Binding TLV 可能不包含依赖 EMSK 的 compound MAC, 即使阶段 2 交换中的较早 EAP 方法提供了 EMSK. 该结果很可能对安全性产生负面影响, 但在撰写本文档时其完整影响尚不清楚.

尽管如此, 这些设计缺陷已经产生了多个互操作实现. 我们注意到, 这些实现似乎只支持 EAP-TLS 和 EAP-MSCHAPv2 的 EAP-FAST-MSCHAPv2 变体. 其他内部 EAP 方法可能偶然可用, 但不太可能是按设计可用. 对于本文档, 我们只能确保完整记录 TEAPv1 的行为, 即使该行为是本规范早期版本中文字不清晰所导致的非预期后果.

我们预计这些问题会在 TEAP 的未来修订中得到处理.

6.3. 计算 Compound MAC​

对于生成密钥材料的 Inner Methods, 通过以密码学方式绑定 TEAP 阶段 1 和 TEAP 阶段 2 对话建立的密钥材料, 可进一步防御路径上攻击. 每次内部 EAP 认证成功后, EAP EMSK 和/或 MSKs 会与来自 TEAP 阶段 1 的密钥材料以密码学方式组合, 以生成 CMK. CMK 用于计算 Compound MAC, 作为第 4.2.13 节所述 Crypto-Binding TLV 的一部分. 这有助于保证 TEAP 中所有通信都涉及相同实体. 在计算 Compound MAC 期间, MAC 字段填充为零.

Compound MAC 的计算如下:

Compound MAC = the first 20 octets of MAC( CMK[n], BUFFER )

其中 n 是最后一个成功执行的内部方法编号, MAC 是 TLS 中协商的 MAC 函数 (例如 [RFC5246] 中的 TLS 1.2), BUFFER 是按以下顺序拼接这些字段后创建的:

  1. 整个 Crypto-Binding TLV 属性, 其中 EMSK 和 MSK Compound MAC 字段均置零.

  2. 另一方在第一条 TEAP 消息中发送的 EAP Type, 它必须是 TEAP, 编码为一个 octet 的 0x37.

  3. EAP 服务器发送给对等方的第一条 TEAP 消息中的所有 Outer TLVs. 如果单条 TEAP 消息被分片为多个 TEAP 数据包, 则必须包含该消息所有分片中的 Outer TLVs.

  4. 对等方发送给 EAP 服务器的第一条 TEAP 消息中的所有 Outer TLVs. 如果单条 TEAP 消息被分片为多个 TEAP 数据包, 则必须包含该消息所有分片中的 Outer TLVs.

如果未运行 Inner Method, 则不会生成 MSK 或 EMSK. 如果需要生成 IMSK, 则 MSK 以及因此 IMSK 被设置为全零 (即 IMSK = MSK = 32 octets of 0x00s).

请注意, 步骤 (3) 和 (4) 中的字段之间没有边界标记. 但是, 服务器使用它发送的 Outer TLVs 和它从对等方收到的 Outer TLVs 来计算 compound MAC. 在另一端, 对等方使用它发送的 Outer TLVs 和它从服务器收到的 Outer TLVs 来计算 compound MAC. 因此, Outer TLVs 在传输中的任何修改都会被检测到, 因为两端会为 compound MAC 计算出不同的值.

如果未运行生成密钥的 Inner Method, 则不会生成 MSK 或 EMSK. 如果需要生成 IMSK, 则 MSK 以及因此 IMSK 被设置为全零 (即 IMSK = MSK = 32 octets of 0x00s).

6.4. EAP 主会话密钥生成​

TEAP 认证通过生成 IMCK, 确保运行 TEAP 所输出的 MSK 和 EMSK 是所有 Inner Methods 的组合结果. 如第 6.2 节所述, IMCK 由对等方和服务器通过将来自 Inner Methods 的 MSKs 与来自 TEAP 阶段 1 的密钥材料组合而共同派生. 生成的 MSK 和 EMSK 来自最终的 (第 "n" 个) Inner Method, 作为 IMCK[n] 密钥层次结构的一部分, 派生如下:

MSK  = the first 64 octets of TLS-PRF(S-IMCK[n],
       "Session Key Generating Function")
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
       "Extended Session Key Generating Function")

secret 是 S-IMCK[n], 其中 n 是第 6.2 节中最后生成的 S-IMCK[j] 的编号. label 是不带引号的字符串的 ASCII 值. seed 为空 (0 length), 并在派生中省略.

EMSK 通常只有 TEAP 对等方和服务器知道, 不提供给第三方. 派生附加密钥以及将这些密钥传输给第三方不在本文档范围内.

如果没有 Inner Method 创建 MSK 或 EMSK, 则 MSK 和 EMSK 将直接从 session_key_seed 生成, 这意味着 S-IMCK[0] = session_key_seed.

如上所述, 并非所有 Inner Methods 都同时生成 MSK 和 EMSK, 因此我们必须维护 S-IMCK[j] 的两个独立派生, 分别对应 MSK[j] 和 EMSK[j]. 使用 S-IMCK[n] 的最终派生必须只选择这些密钥中的一个.

如果 Crypto-Binding TLV 包含 EMSK compound MAC, 则派生取自 S-IMCK_EMSK[n]. 否则, 它取自 S-IMCK_MSK[n].

最后于 更新