IKE：互联网密钥交换-HQY 一个和谐有爱的空间

29

2025
05
10:56:16

IKE：互联网密钥交换

RFC2409：The Internet Key Exchange (IKE)，November 1998

本备忘录的状态

本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。

1、摘要

ISAKMP ([MSST98]) 为认证和密钥交换提供了一个框架，但没有定义它们。ISAKMP 旨在独立于密钥交换；也就是说，它旨在支持许多不同的密钥交换。

Oakley ([Orm96]) 描述了一系列密钥交换——称为“模式/modes”——并详细说明了每个提供的服务（例如密钥的完美前向安全性、身份保护和身份验证）。

SKEME ([SKEME]) 描述了一种通用的密钥交换技术，它提供匿名性、可否认性和快速密钥更新。

本文档描述了使用 Oakley 的一部分和 SKEME 的一部分与 ISAKMP 结合使用的协议，以获得用于 ISAKMP 的认证密钥材料，以及用于 IETF IPsec DOI 的其他安全联盟，例如 AH 和 ESP。

2、讨论

本备忘录描述了一种混合协议。目的是以受保护的方式为安全联盟协商并提供经过验证的密钥材料。

实现此备忘录的进程可用于协商虚拟专用网络 (virtual private networks，VPN)，也可用于为远程用户提供从远程站点（其 IP 地址无需事先知道）访问安全主机或网络的权限。

支持客户端协商。客户端模式是协商方不是正在为其进行安全联盟协商的端点。在客户端模式下使用时，终端方的身份保持隐藏。

这并没有实现整个 Oakley 协议，而只是实现其目标所必需的一个子集。它并不声称符合或遵守整个 Oakley 协议，也不以任何方式依赖于 Oakley 协议。

同样，这并没有实现整个 SKEME 协议，而只是实现了用于身份验证的公钥加密方法及其使用随机数交换的快速重新加密的概念。该协议不以任何方式依赖于 SKEME 协议。

3、术语和定义

3.1、需求术语

本文档中出现的关键字“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”应按照 [Bra97] 中的描述进行解释。

3.2、符号

本备忘录通篇使用以下符号。

HDR 是一个 ISAKMP 头，其交换类型是模式。当写为 HDR* 时，它表示负载加密。

SA 是带有一个或多个提议的 SA 协商有效载荷。发起方可以提供多个协商建议；响应者必须只回复一个。

<P>_b 表示payload的主体<P>，不包括ISAKMP通用vpayload。

SAi_b 是 SA 有效载荷的整个主体（减去 ISAKMP 通用标头）。即 DOI、情况、所有提议和发起方提供的所有转换。

CKY-I 和 CKY-R 分别是来自 ISAKMP 头的发起方的 cookie 和响应方的 cookie。

g^xi 和 g^xr 分别是发起者和响应者的 Diffie-Hellman ([DH]) 公共值。

g^xy 是 Diffie-Hellman 共享密钥。

KE 是密钥交换有效载荷，其中包含在 Diffie-Hellman 交换中交换的公共信息。没有用于 KE 有效载荷数据的特定编码（例如 TLV）。

Nx 是 nonce 有效载荷；x 可以是：i 或 r 分别代表 ISAKMP 发起者和响应者。

IDx 是“x”的标识有效载荷。x 可以是：“ii”或“ir”，分别表示第一阶段协商中的 ISAKMP 发起方和响应方；或“ui”或“ur”分别用于第二阶段的用户发起者和响应者。互联网 DOI 的 ID 有效载荷格式在 [Pip97] 中定义。

SIG 是签名有效载荷。要签名的数据是特定于交换的。

CERT 是证书负载。

HASH（以及任何衍生物，如 HASH(2) 或 HASH_I）是哈希有效负载。散列的内容特定于身份验证方法。

prf(key, msg) 是键控伪随机函数（pseudo-random function），通常是键控散列函数。用于生成出现伪随机的确定性输出。prf 用于密钥派生和身份验证（即作为密钥 MAC）。（见 [KBC96]）。

SKEYID 是从只有交换中的活跃玩家知道的密钥材料派生出来的字符串。

SKEYID_e 是 ISAKMP SA 用来保护其消息机密性的密钥材料。

SKEYID_a 是 ISAKMP SA 用来验证其消息的密钥材料。

SKEYID_d 是用于为非 ISAKMP 安全联盟派生密钥的密钥材料。

<x>y 表示“x”是用密钥“y”加密的。

--> 表示“发起者到响应者”的通信（请求）。

<-- 表示“响应者到发起者”的通信（回复）。

| 表示信息的串联——例如X | Y 是 X 与 Y 的连接。

[x] 表示 x 是可选的。

消息加密（当在 ISAKMP 头后用“*”表示时）必须在 ISAKMP 头后立即开始。当通信受到保护时，必须对 ISAKMP 标头之后的所有有效载荷进行加密。加密密钥是以为每个算法定义的方式从 SKEYID_e 生成的。

3.3、完美的前向安全性

当在备忘录中使用时，完美前向安全性 (Perfect Forward Secrecy，PFS) 指的是这样一种概念，即破坏单个密钥将仅允许访问受单个密钥保护的数据。为了使 PFS 存在，用于保护数据传输的密钥不得用于派生任何其他密钥，并且如果用于保护数据传输的密钥是从某些其他密钥材料派生的，则该材料不得用于派生更多键。

本协议提供了密钥和身份的完美前向安全性。（第 5.5 和 8 节）。

3.4、安全联盟

安全联盟 (security association，SA) 是一组用于保护信息的策略和密钥。ISAKMP SA 是此协议中协商对等方用于保护其通信的共享策略和密钥。

4、介绍

Oakley 和 SKEME 各自定义了一种方法来建立经过身份验证的密钥交换。这包括有效载荷构造、有效载荷携带的信息、处理它们的顺序以及如何使用它们。

Oakley 定义了“模式/modes”，而 ISAKMP 定义了“阶段/phases”。两者之间的关系非常简单，IKE 将不同的交换呈现为在两个阶段之一中运行的模式。

阶段 1 是两个 ISAKMP 对等体建立一个安全的、经过身份验证的通道以进行通信。这称为 ISAKMP 安全联盟 (SA)。“主模式”和“野蛮模式”各自完成第一阶段的交换。“主模式”和“野蛮模式”只能在阶段 1 中使用。

第 2 阶段是代表 IPsec 等服务或任何其他需要密钥材料和/或参数协商的服务协商安全联盟。“快速模式”完成了第 2 阶段的交换。“快速模式”只能在阶段 2 中使用。

“新组模式”并不是真正的第1阶段或第2阶段。它在第1阶段之后，而是用于建立一个可用于未来协商的新组。“新组模式”只能在第 1 阶段之后使用。

ISAKMP SA 是双向的。也就是说，一旦建立，任何一方都可以启动快速模式、信息和新组模式交换。根据基础 ISAKMP 文档，ISAKMP SA 由发起方的 cookie 和响应方的 cookie 标识——每一方在阶段 1 交换中的角色决定哪个 cookie 是发起方的。由第一阶段交换建立的 cookie 顺序继续识别 ISAKMP SA，而不管快速模式、信息或新组交换的方向如何。换句话说，当 ISAKMP SA 的方向改变时，cookie 不得交换位置。

通过使用 ISAKMP 阶段，实现可以在必要时完成非常快速的键控。单个阶段 1 协商可用于多个阶段 2 协商。此外，单个阶段 2 协商可以请求多个安全联盟。通过这些优化，实现可以看到每个 SA 少于一次往返以及每个 SA 少于一次 DH 取幂。阶段 1 的“主模式”提供身份保护。当不需要身份保护时，可以使用“野蛮模式”进一步减少往返次数。下面包含了进行这些优化的开发人员提示。还应该注意的是，使用公钥加密来验证野蛮模式交换仍将提供身份保护。

该协议本身没有定义自己的 DOI。在第 1 阶段建立的 ISAKMP SA 可以使用来自非 ISAKMP 服务（例如 IETF IPSec DOI [Pip97]）的 DOI 和情况。在这种情况下，实现可以选择限制使用 ISAKMP SA 为相同 DOI 的服务建立 SA。或者，一个 ISAKMP SA 可以在 DOI 和情况下用零值建立（参见 [MSST98] 了解这些字段的描述），在这种情况下，实现将可以自由地使用这个 ISAKMP SA 为任何定义的 DOI 建立安全服务.如果 DOI 为零用于建立阶段 1 SA，则阶段 1 中使用的身份有效载荷的语法是在 [MSST98] 中定义的，而不是来自任何 DOI——例如[Pip97]--这可能会进一步扩展身份的语法和语义。

以下属性由 IKE 使用，并作为 ISAKMP 安全联盟的一部分进行协商。（这些属性仅与 ISAKMP 安全联盟有关，与 ISAKMP 可能代表其他服务协商的任何安全联盟无关。）

- 加密演算法
- 哈希算法
- 身份验证方法
- 有关进行 Diffie-Hellman 的组的信息。

所有这些属性都是强制性的，必须进行协商。此外，可以选择性地协商伪随机函数（“prf”）。（目前本文档中没有定义可协商的伪随机函数。私有使用属性值可用于同意方之间的 prf 协商）。如果“prf”不是协商，则协商散列算法的 HMAC（参见 [KBC96]）版本用作伪随机函数。其他非强制性属性在附录 A 中描述。所选散列算法必须同时支持本机和 HMAC 模式。

必须使用定义的组描述（第 6 节）或通过定义组的所有属性（第 5.6 节）来指定 Diffie-Hellman 组。组属性（例如组类型或主数——参见附录 A）不得与先前定义的组（保留组描述或在新组模式交换结束后建立的专用描述）一起提供。

IKE 实现必须支持以下属性值：

- CBC 模式下的 DES [DES] 带有弱密钥和半弱密钥检查（弱密钥和半弱密钥在 [Sch96] 中引用并在附录 A 中列出）。密钥是根据附录 B 导出的。
- MD5 [MD5] 和 SHA [SHA}。
- 通过预共享密钥进行身份验证。
- 默认组号为 1 的 MODP（见下文）。

此外，IKE 实现应该支持：用于加密的 3DES；Tiger ([TIGER]) 用于哈希；数字签名标准、RSA [RSA] 签名和使用 RSA 公钥加密的身份验证；和 MODP 组编号 2。IKE 实现可以支持附录 A 中定义的任何附加加密算法，并且可以支持 ECP 和 EC2N 组。

每当实施 IETF IPsec DOI [Pip97] 时，必须实施此处描述的 IKE 模式。其他 DOI 可以使用此处描述的模式。

5. 交换

有两种基本方法可用于建立经过身份验证的密钥交换：主模式和野蛮模式。每个都从短暂的 Diffie-Hellman 交换中生成经过验证的密钥材料。必须实现主模式；应该实施野蛮模式。此外，快速模式必须作为一种机制来实现，以生成新的密钥材料和协商非 ISAKMP 安全服务。此外，新组模式应该作为一种机制来实现，为 Diffie-Hellman 交换定义私有组。实现不得在交换过程中切换交换类型。

交换符合标准 ISAKMP 有效负载语法、属性编码、消息的超时和重传以及信息性消息——例如，当提案不可接受，或签名验证或解密不成功等时，将发送通知响应。

在第 1 阶段交换中，SA 有效载荷必须先于所有其他有效载荷。除非另有说明，否则不要求任何消息中的 ISAKMP 有效负载按任何特定顺序排列。

在第 1 阶段或第 2 阶段交换中，在 KE 有效载荷中传递的 Diffie-Hellman 公共值必须是协商的 Diffie-Hellman 组的长度，如有必要，通过在该值前面加上零来强制执行。

nonce 有效载荷的长度必须介于 8 和 256 字节之间。

Main Mode 是 ISAKMP Identity Protect Exchange 的一个实例：前两个消息协商策略；接下来的两个交换 Diffie-Hellman 公共值和交换所需的辅助数据（例如随机数）；最后两条消息验证了 Diffie-Hellman 交换。作为初始 ISAKMP 交换的一部分协商的身份验证方法会影响有效负载的组成，但不会影响其目的。主模式的 XCHG 是 ISAKMP Identity Protect。

同样，野蛮模式是 ISAKMP 积极交换的实例。前两个消息协商策略、交换 Diffie-Hellman 公共值和交换所需的辅助数据以及身份。此外，第二条消息验证响应者。第三条消息对发起者进行身份验证并提供参与交换的证明。Aggressive 模式的 XCHG 是 ISAKMP Aggressive。最终消息可能不会在 ISAKMP SA 的保护下发送，如果需要，允许每一方推迟求幂，直到此交换的协商完成。野蛮模式的图形描述清楚地显示了最终的有效载荷；不必如此。

IKE 中的交换不是开放式的，并且具有固定数量的消息。证书请求有效载荷的接收不得扩展传输或预期的消息数量。

安全联盟协商受限于野蛮模式。由于消息构建要求，无法协商执行 Diffie-Hellman 交换的组。此外，不同的认证方式可能会进一步限制属性协商。例如，无法协商使用公钥加密的身份验证，并且当使用修改后的公钥加密方法进行身份验证时，无法协商密码和散列。对于需要 IKE 丰富的属性协商能力的情况，可能需要 Main Mode。

快速模式和新组模式在 ISAKMP 中没有模拟。快速模式和新组模式的 XCHG 值在附录 A 中定义。

Main Mode、Aggressive Mode和Quick Mode进行安全联盟协商。安全联盟提议采用封装在建议有效负载中的转换有效负载的形式，封装在安全联盟 (SA) 有效负载中。如果为阶段 1 交换（主模式和野蛮模式）提供多个提议，则它们必须采用多个转换有效载荷的形式，用于单个 SA 有效载荷中的单个提议有效载荷。换句话说，对于阶段 1 交换，单个 SA 有效载荷不得有多个提议有效载荷，也不得有多个 SA 有效载荷。本文档不禁止在第 2 阶段交换中的报价中出现此类行为。

发起者可以发送给响应者的提议数量没有限制，但出于性能原因，一致性实现可以选择限制它将检查的提议数量。

在安全联盟协商期间，发起方向响应方提供潜在安全联盟的提议。响应者不得修改任何报价的属性，属性编码除外（参见附录 A）。如果交换的发起者注意到属性值已经改变，或者属性已经从一个提议中添加或删除，那么这个响应必须被拒绝。

主模式或野蛮模式允许使用四种不同的身份验证方法：数字签名、使用公钥加密的两种身份验证形式或预共享密钥。值 SKEYID 是针对每种身份验证方法单独计算的。

对于签名：

SKEYID = prf(Ni_b | Nr_b, g^xy)

对于公钥加密：

SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)

对于预共享密钥：

SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

Main Mode 或 Aggressive Mode 的结果是三组经过身份验证的密钥材料：

并商定了保护进一步通信的政策。上面的 0、1 和 2 的值由单个八位字节表示。用于加密的密钥是以特定于算法的方式从 SKEYID_e 派生的（参见附录 B）。

为了验证任一交换，协议发起方生成 HASH_I，响应方生成 HASH_R，其中：

对于数字签名认证，HASH_I 和 HASH_R 被签名和验证；对于使用公钥加密或预共享密钥进行身份验证，HASH_I 和 HASH_R 直接对交换进行身份验证。整个 ID 负载（包括 ID 类型、端口和协议，但不包括通用标头）被散列到 HASH_I 和 HASH_R 中。

如上所述，协商的身份验证方法会影响阶段 1 模式消息的内容和使用，但不会影响它们的意图。使用公钥进行身份验证时，可以通过使用签名或使用公钥加密（如果算法支持）来完成阶段 1 交换。以下是具有不同身份验证选项的第 1 阶段交换。

5.1、使用签名进行身份验证的 IKE 阶段 1

使用签名，第二次往返时交换的辅助信息是随机数；通过签署相互可获得的哈希来验证交换。带签名认证的Main Mode描述如下：

带有签名和 ISAKMP 的野蛮模式描述如下：

在这两种模式下，签名数据 SIG_I 或 SIG_R 是分别应用于 HASH_I 或 HASH_R 的协商数字签名算法的结果。

通常，使用协商的 prf 或协商的散列函数的 HMAC 版本（如果没有协商 prf），签名将如上所述超过 HASH_I 和 HASH_R。但是，如果签名算法与特定的散列算法相关联（例如，DSS 仅使用 SHA 的 160 位输出定义），则这可以被覆盖以构建签名。在这种情况下，签名将在 HASH_I 和 HASH_R 上面，除了使用与签名方法关联的哈希算法的 HMAC 版本。协商的 prf 和散列函数将继续用于所有其他规定的伪随机函数。

由于使用的哈希算法是已知的，因此无需将其 OID 编码到签名中。此外，PKCS #1 中用于 RSA 签名的 OID 与本文档中使用的 OID 之间没有绑定。因此，RSA 签名必须被编码为 PKCS #1 格式的私钥加密，而不是 PKCS #1 格式（包括散列算法的 OID）的签名。DSS 签名必须编码为 r 后跟 s。

可以选择传递一个或多个证书有效负载。

5.2、第一阶段使用公钥加密进行身份验证

使用公钥加密来验证交换，交换的辅助信息是加密的随机数。每一方重建散列的能力（证明另一方解密了随机数）验证了交换。

为了执行公钥加密，发起者必须已经拥有响应者的公钥。在响应者有多个公钥的情况下，发起者用来加密辅助信息的证书的哈希值作为第三条消息的一部分被传递。通过这种方式，响应者可以确定使用哪个对应的私钥来解密加密的有效载荷，并保留身份保护。

除了nonce之外，双方的身份（IDii和IDir）也用对方的公钥加密。如果认证方法是公钥加密，则 nonce 和身份载荷必须用另一方的公钥加密。只有有效载荷的主体被加密，有效载荷标头保持明文。

当使用加密进行认证时，主模式定义如下。

使用加密进行身份验证的野蛮模式描述如下：

其中 HASH(1) 是发起者用来加密随机数和身份的证书的哈希值（使用协商的哈希函数）。

RSA 加密必须以 PKCS #1 格式编码。虽然只有 ID 和 nonce 有效负载的主体被加密，但加密数据之前必须有一个有效的 ISAKMP 通用标头。有效载荷长度是整个加密有效载荷加上头部的长度。PKCS #1 编码允许在解密时确定明文有效载荷的实际长度。

使用加密进行身份验证提供了一种合理可否认的交换。没有证据（如数字签名）表明对话曾经发生过，因为每一方都可以完全重建交换的双方。此外，安全性被添加到密钥生成中，因为攻击者不仅必须成功破解 Diffie-Hellman 交换，还要成功破解两个 RSA 加密。这种交换是由 [SKEME] 发起的。

请注意，与其他身份验证方法不同，使用公钥加密的身份验证允许使用野蛮模式进行身份保护。

5.3、第 1 阶段使用修订的公钥加密模式进行身份验证

与使用签名的身份验证相比，使用公钥加密的身份验证具有显着的优势（请参阅上面的第 5.2 节）。不幸的是，这是以 4 次公钥操作为代价的——两次公钥加密和两次私钥解密。这种身份验证方式保留了使用公钥加密进行身份验证的优点，但只使用了一半的公钥操作。

在这种模式下，nonce 仍然使用对等方的公钥加密，但是对等方的身份（以及发送的证书）使用协商的对称加密算法（来自 SA 有效载荷）使用从随机数。该解决方案增加了最小的复杂性和状态，但在每一侧都节省了两个昂贵的公钥操作。此外，密钥交换负载也使用相同的派生密钥进行加密。这提供了针对 Diffie-Hellman 交换的密码分析的额外保护。

与身份验证的公钥加密方法（第 5.2 节）一样，如果响应方有多个包含可用公钥的证书（例如，如果证书不是仅用于签名，或者由于证书限制或算法限制）。如果发送了 HASH 有效载荷，它必须是第二次消息交换的第一个有效载荷，并且必须跟随加密的随机数。如果未发送 HASH 有效载荷，则第二次消息交换的第一个有效载荷必须是加密的随机数。此外，发起者可以选择发送证书有效负载，以向响应者提供响应的公钥。

当使用修改后的加密模式进行认证时，主模式定义如下。

使用修改后的加密方法进行身份验证的野蛮模式描述如下：

其中 HASH(1) 与第 5.2 节相同。Ke_i 和 Ke_r 是在 SA 负载交换中协商的对称加密算法的密钥。只有有效载荷的主体被加密（在公钥和对称操作中），通用有效载荷标头保持明文。有效载荷长度包括为执行加密而添加的长度。

对称密码密钥是从解密的随机数中导出的，如下所示。首先计算值 Ne_i 和 Ne_r：

Ne_i = prf(Ni_b, CKY-I)Ne_r = prf(Nr_b, CKY-R)

然后以附录 B 中描述的方式分别从 Ne_i 和 Ne_r 中获取密钥 Ke_i 和 Ke_r，用于导出与协商加密算法一起使用的对称密钥。如果协商prf的输出长度大于或等于密码的密钥长度要求，则分别从Ne_i和Ne_r的最高有效位导出Ke_i和Ke_r。如果 Ke_i 和 Ke_r 的期望长度超过了 prf 输出的长度，则通过将 prf 的结果反复反馈回自身并将结果连接起来，直到达到所需的数量，从而获得所需的比特数。例如，如果协商加密算法需要320位密钥，而prf的输出只有128位，则Ke_i是K的最高有效320位，其中

K = K1 | K2 | K3 andK1 = prf(Ne_i, 0)K2 = prf(Ne_i, K1)K3 = prf(Ne_i, K2)

为简洁起见，仅显示 Ke_i 的推导；Ke_r 是相同的。K1 计算中值 0 的长度是单个八位字节。请注意，Ne_i、Ne_r、Ke_i 和 Ke_r 都是短暂的，使用后必须丢弃。

保存对可选 HASH 有效载荷和强制随机数有效载荷位置的要求，没有进一步的有效载荷要求。所有有效载荷——无论顺序如何——都必须根据方向使用 Ke_i 或 Ke_r 加密。

如果 CBC 模式用于对称加密，则初始化向量 (initialization vectors，IV) 设置如下。用于加密随机数之后的第一个有效负载的 IV 设置为 0（零）。使用临时对称密码密钥 Ke_i 加密的后续有效负载的 IV 是前一个有效负载的最后一个密文块。加密的有效载荷被填充到最接近的块大小。除最后一个填充字节外，所有填充字节都包含 0x00。填充的最后一个字节包含使用的填充字节数，不包括最后一个。请注意，这意味着将始终存在填充。

5.4、第一阶段使用预共享密钥进行身份验证

由某种带外机制导出的密钥也可用于验证交换。这个密钥的实际建立超出了本文档的范围。

在进行预共享密钥认证时，Main Mode 定义如下：

具有预共享密钥的野蛮模式描述如下：

当在主模式下使用预共享密钥身份验证时，密钥只能由对等方的 IP 地址识别，因为必须在发起方处理 IDir 之前计算 HASH_I。野蛮模式允许使用更广泛的预共享密钥标识符。此外，野蛮模式允许两方维护多个不同的预共享密钥，并为特定交换确定正确的密钥。

5.5、阶段 2 - 快速模式

快速模式本身不是一个完整的交换（因为它绑定到第 1 阶段的交换），而是用作 SA 协商过程（第 2 阶段）的一部分，为非 ISAKMP SA 派生密钥材料和协商共享策略。与快速模式一起交换的信息必须受到 ISAKMP SA 的保护——即除 ISAKMP 标头之外的所有有效载荷都被加密。在快速模式下，HASH 有效载荷必须紧跟在 ISAKMP 标头之后，SA 有效载荷必须紧跟在 HASH 之后。该 HASH 验证消息并提供活跃度证明。

ISAKMP 标头中的消息 ID 为特定的 ISAKMP SA 标识正在进行的快速模式，该 SAKMP SA 本身由 ISAKMP 标头中的 cookie 标识。由于快速模式的每个实例都使用唯一的初始化向量（参见附录 B），因此可以在任何时间基于单个 ISAKMP SA 有多个同时进行的快速模式。

快速模式本质上是一种 SA 协商和一种提供重放保护的随机数交换。随机数用于生成新的密钥材料并防止重放攻击生成虚假的安全联盟。可以交换可选的密钥交换有效负载，以允许每个快速模式进行额外的 Diffie-Hellman 交换和幂运算。虽然在快速模式下使用密钥交换有效负载是可选的，但它必须得到支持。

基本快速模式（没有 KE 有效载荷）刷新从阶段 1 中取幂导出的密钥材料。这不提供 PFS。使用可选的 KE 有效载荷，执行额外的幂运算，并为密钥材料提供 PFS。

在快速模式中协商的 SA 的身份被隐式假定为 ISAKMP 对等体的 IP 地址，对协议或端口号没有任何隐含的限制，除非在快速模式中指定了客户端标识符。如果 ISAKMP 代表另一方充当客户端协商者，则各方的身份必须作为 IDci 传递，然后是 IDcr。当地政策将决定这些提议对于指定的身份是否可以接受。如果快速模式响应者不接受客户端身份（由于策略或其他原因），则应发送具有通知消息类型 INVALID-ID-INFORMATION (18) 的通知负载。

在两个对等点之间存在多个隧道的情况下，客户端身份用于识别流量并将其引导到适当的隧道，并且还允许具有不同粒度的唯一和共享 SA。

在快速模式期间提供的所有报价在逻辑上都是相关的，并且必须一致。例如，如果发送了 KE 有效载荷，则必须在每个正在协商的 SA 的每个提议的每个转换中包含描述 Diffie-Hellman 组的属性（参见第 6.1 节和 [Pip97]）。类似地，如果使用客户端身份，它们必须应用于协商中的每个 SA。

快速模式定义如下：

在这里：

HASH(1) 是来自 ISAKMP 标头的消息 ID (M-ID) 上的 prf，它与包含所有有效负载标头的散列后面的整个消息连接，但不包括为加密添加的任何填充。HASH(2) 与 HASH(1) 相同，除了发起者的随机数——Ni，减去有效载荷头——被添加在 M-ID 之后但在完整消息之前。将随机数添加到 HASH(2) 是为了证明活力。HASH(3)——对于活跃度——是表示为单个八位字节的零值上的 prf，后面是消息 id 和两个随机数的串联 - 发起者后面是响应者 - 减去有效负载标头。换句话说，上述交换的哈希是：

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr )HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

除了 HASH、SA 和可选的 ID 有效负载外，快速模式没有有效负载排序限制。如果消息中的有效载荷的顺序与说明性示例不同，或者如果任何可选的有效载荷（例如通知有效载荷）已链接到消息，则 HASH(1) 和 HASH(2) 可能与上述说明不同。

如果不需要 PFS，并且不交换 KE 有效载荷，则新的密钥材料定义为

KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

如果需要 PFS 并且交换了 KE 有效载荷，则新的密钥材料定义为

KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

其中 g(qm)^xy 是来自此快速模式的短暂 Diffie-Hellman 交换的共享密钥。

在任何一种情况下，“协议”和“SPI”都来自包含协商转换的 ISAKMP 提议有效负载。

单个 SA 协商会产生两个安全联盟：一个入站和一个出站。每个 SA 的不同 SPI（一个由发起者选择，另一个由响应者选择）保证每个方向的密钥不同。SA 的目的地选择的 SPI 用于为该 SA 派生 KEYMAT。

对于所需的密钥材料数量大于 prf 提供的数量的情况，KEYMAT 通过将 prf 的结果反馈回自身并连接结果进行扩展，直到达到所需的密钥材料。换句话说，

KEYMAT = K1 | K2 | K3 | ...

在这里

K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)

等等。

该密钥材料（无论是否带有 PFS，无论是直接派生的还是通过级联派生的）必须与协商的 SA 一起使用。由服务来定义如何从密钥材料中派生出密钥。

在快速模式下的临时 Diffie-Hellman 交换的情况下，指数 (g(qm)^xy) 不可恢复地从当前状态中删除，并且 SKEYID_e 和 SKEYID_a（源自阶段 1 协商）继续保护和验证 ISAKMP SA 并且 SKEYID_d 继续用于派生密钥。

使用快速模式，多个 SA 和密钥可以与一个交换机协商，如下所示：

密钥材料的导出与单个 SA 的情况相同。在这种情况下（两个 SA 负载的协商），结果将是四个安全联盟——两个 SA 各有两个。

5.6、新增群组模式

在建立 ISAKMP SA 之前，不得使用新的组模式。新组的描述必须仅遵循阶段 1 协商。（不过，这不是第 2 阶段的交换）。

其中 HASH(1) 是 prf 输出，使用 SKEYID_a 作为密钥，来自 ISAKMP 标头的消息 ID 与整个 SA 提议、正文和标头连接，作为数据；HASH(2) 是 prf 输出，使用 SKEYID_a 作为键，来自 ISAKMP 标头的消息 ID 与作为数据的回复连接。换句话说，上述交换的哈希是：

HASH(1) = prf(SKEYID_a, M-ID | SA)HASH(2) = prf(SKEYID_a, M-ID | SA)

该提案将详细说明该组的特征（参见附录 A，“属性分配编号”）。私人组的组描述必须大于或等于 2^15。如果该组不可接受，则响应者必须回复带有消息类型设置为 ATTRIBUTES-NOT-SUPPORTED (13) 的 Notify 有效负载。

ISAKMP 实现可能要求私有组与建立它们的 SA 一起老化。

组可以在 SA 提案中与 Main Mode 直接协商。为此，组件部分——对于 MODP 组，类型、素数和生成器；对于 EC2N 组，类型、不可约多项式、组生成器一、组生成器二、组曲线 A、组曲线 B 和组顺序——作为 SA 属性传递（参见附录 A）。或者，可以使用新组模式隐藏组的性质，并且在第 1 阶段协商期间仅以明文形式传递组标识符。

5.7、 ISAKMP 信息交换

该协议在可能的情况下保护 ISAKMP 信息交换。一旦建立了 ISAKMP 安全联盟（并且生成了 SKEYID_e 和 SKEYID_a），ISAKMP 信息交换在与此协议一起使用时如下：

其中 N/D 是 ISAKMP 通知有效载荷或 ISAKMP 删除有效载荷，HASH(1) 是 prf 输出，使用 SKEYID_a 作为密钥，以及与整个信息有效载荷连接的此交换唯一的 M-ID（通知）或删除）作为数据。换句话说，上述交换的哈希是：

HASH(1) = prf(SKEYID_a, M-ID | N/D)

如前所述，ISAKMP 报头中的消息 ID——并在 prf 计算中使用——对于该交换是唯一的，并且不得与生成此信息交换的另一个阶段 2 交换的消息 ID 相同。初始化向量的推导，与 SKEYID_e 一起使用来加密这个消息，在附录 B 中描述。

如果在信息交换时尚未建立 ISAKMP 安全联盟，则交换以明文方式完成，没有随附的 HASH 负载。

6、奥克利组

使用 IKE，协商进行 Diffie-Hellman 交换的组。四个组——值 1 到 4——定义如下。这些组起源于奥克利协议，因此被称为“奥克利组”。“组”的属性类在附录 A 中定义。所有 2^15 和更高的值都用于私有组标识符。有关默认 Oakley 组的强度的讨论，请参阅下面的安全注意事项部分。

这些小组都是由亚利桑那大学的 Richard Schroeppel 创建的。[Orm96] 中描述了这些基团的特性。

6.1、第一奥克利默认组

Oakley 实现必须支持具有以下素数和生成器的 MODP 组。该组被分配了 id 1（一）。

质数是：

2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }

它的十六进制值为

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD129024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DDEF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

生成器是：2。

6.2、第二奥克利组

IKE 实现应该支持具有以下素数和生成器的 MODP 组。该组被分配了 id 2（二）。

质数是

2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }。

它的十六进制值为

生成器为 2（十进制）

6.3、第三奥克利组

IKE 实现应该支持具有以下特征的 EC2N 组。该组被分配了 id 3（三）。该曲线基于伽罗瓦域 GF[2^155]。字段大小为 155。该字段的不可约多项式为：

u^155 + u^62 + 1。

椭圆曲线的方程为：

y^2 + xy = x^3 + ax^2 + b。

字段大小：155

群素数/不可约多项式：

0x0800000000000000000000004000000000000001

组生成器一：0x7b

组曲线 A：0x0

组曲线 B：0x07338f

组顺序：

0X0800000000000000000057db5698537193aef944

使用该组时KE载荷中的数据是解(x,y)中的值x，曲线上的点取随机选择的密钥Ka并计算Ka*P，其中*是该组的重复加法和双运算，P 是曲线点，其 x 坐标等于生成器 1，y 坐标由定义方程确定。曲线方程由组类型以及 A 和 B 系数隐含已知。y 坐标有两个可能的值；任何一个都可以成功使用（双方无需就选择达成一致）。

6.4、第四奥克利组

IKE 实现应该支持具有以下特征的 EC2N 组。该组被分配了 id 4（四）。该曲线基于伽罗瓦域 GF[2^185]。字段大小为 185。该字段的不可约多项式为：

u^185 + u^69 + 1。

椭圆曲线的方程为：

y^2 + xy = x^3 + ax^2 + b。

字段大小：185

群质数/不可约多项式：

0x020000000000000000000000000000200000000000000001

组生成器一：0x18

组曲线 A：0x0

组曲线 B：0x1ee9

组顺序：

0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc

使用该组时 KE 有效载荷中的数据将与使用 Oakley Group 3（三）时的数据相同。

可以使用新组模式定义其他组。这些默认组由亚利桑那大学的 Richard Schroeppel 生成。这些素数的性质在 [Orm96] 中有描述。

7、完整 IKE 交换的有效载荷爆炸

本节说明 IKE 协议如何用于：

- 在 ISAKMP 进程之间建立一个安全和经过身份验证的通道（阶段 1）；和
- 生成并协商 IPsec SA 的密钥材料（第 2 阶段）。

7.1、阶段 1 使用主模式

下图说明了双方在第一次往返交换中交换的有效载荷。发起人可以提出几个建议；响应者必须回复一个。

响应者以实物回复但选择并返回一个转换提议（ISAKMP SA 属性）。

第二个交换包含以下有效载荷：

共享密钥 SKEYID_e 和 SKEYID_a 现在用于保护和验证所有进一步的通信。请注意，SKEYID_e 和 SKEYID_a 均未经身份验证。

密钥交换通过签名散列进行身份验证，如第 5.1 节所述。一旦使用作为 ISAKMP SA 一部分协商的身份验证算法验证了签名，共享密钥 SKEYID_e 和 SKEYID_a 可以标记为已验证。（为简洁起见，未交换证书有效负载）。

7.2、使用快速模式的第 2 阶段

以下有效载荷在第一轮快速模式中通过 ISAKMP SA 协商进行交换。在这个假设的交换中，ISAKMP 协商者是已请求身份验证的其他方的代理。

其中散列的内容在上面的 5.5 中描述。响应者回复一条类似的消息，其中只包含一个变换——选定的 AH 变换。收到后，发起者可以向密钥引擎提供协商的安全联盟和密钥材料。作为对重放攻击的检查，响应者等待直到收到下一条消息。

其中散列的内容在上面的 5.5 中描述。

8、完美的前向安全性示例

该协议可以提供密钥和身份的 PFS。ISAKMP 协商对等方的身份以及（如果适用）对等方协商的身份都可以使用 PFS 进行保护。

为了提供密钥和所有身份的完全前向安全性，双方将执行以下操作：

** 主模式交换以保护 ISAKMP 对等体的身份。

这将建立一个 ISAKMP SA。

** 用于协商其他安全协议保护的快速模式交换。

这将为该协议在每一端建立一个 SA。

** 删除 ISAKMP SA 及其关联状态。

由于在非 ISAKMP SA 中使用的密钥源自单个临时 Diffie-Hellman 交换，因此保留了 PFS。

为了仅提供非 ISAKMP 安全联盟的密钥的完全前向安全性，如果两个对等体之间存在 ISAKMP SA，则不需要进行阶段 1 交换。只需要一个单一的快速模式，其中传递可选的 KE 有效载荷，并执行额外的 Diffie-Hellman 交换。此时，必须从 ISAKMP SA 中删除从该快速模式派生的状态，如第 5.5 节所述。

9、实施提示

使用单个 ISAKMP 阶段 1 协商使后续阶段 2 协商非常快。只要阶段 1 状态保持缓存状态，并且不需要 PFS，阶段 2 就可以进行而无需任何取幂。单个阶段 1 可以执行多少阶段 2 协商是本地策略问题。该决定将取决于所使用算法的强度和对等系统中的信任级别。

在执行快速模式时，实现可能希望协商一系列 SA。通过这样做，他们可以加速“重新键入”。快速模式定义了如何为一系列 SA 定义 KEYMAT。当一个对等体认为是时候更改 SA 时，他们只需使用规定范围内的下一个。可以通过使用一个快速模式协商多个 SA（相同属性、不同 SPI）来建立一系列 SA。

通常有用的优化是在需要之前与对等点建立安全联盟，以便在需要时它们已经就位。这可确保在初始数据传输之前不会因密钥管理而出现延迟。通过为每个请求的安全联盟设置多个具有对等点的安全联盟并缓存那些未立即使用的安全联盟，可以轻松实现这种优化。

此外，如果 ISAKMP 实现收到警报，即将需要 SA（例如，替换将在不久的将来到期的现有 SA），则它可以在需要新 SA 之前建立新 SA。

基本 ISAKMP 规范描述了协议的一方可以通知另一方某些活动的条件——删除安全联盟或响应协议中的某些错误，例如签名验证失败或有效载荷解密失败.强烈建议在任何情况下都不要回应这些信息交换。这种情况可能会导致“通知战争”，在这种情况下，无法理解消息会导致向无法理解消息的对等方发送通知，并将其自己的通知发回，而对方也无法理解。

10、安全考虑

这份完整的备忘录讨论了一种混合协议，将 Oakley 的部分和 SKEME 的部分与 ISAKMP 结合起来，以安全和经过身份验证的方式协商和导出安全联盟的密钥材料。

通过使用协商的加密算法来确保机密性。使用协商方法确保身份验证：数字签名算法；支持加密的公钥算法；或者，预共享密钥。此交换的机密性和身份验证仅与作为 ISAKMP 安全联盟的一部分协商的属性一样好。

使用快速模式重复重新加密会消耗 Diffie-Hellman 共享密钥的熵。实施者应注意这一事实，并对指数之间的快速模式交换设置限制。本备忘录没有规定这样的限制。

使用此协议可以实现密钥材料和身份的完美前向安全性 (Perfect Forward Secrecy，PFS)。通过指定一个 Diffie-Hellman 组，并在 KE 有效载荷中传递公共值，ISAKMP 对等方可以建立密钥的 PFS——身份将受到来自 ISAKMP SA 的 SKEYID_e 的保护，因此不会受到 PFS 的保护。如果需要密钥材料和身份的 PFS，则 ISAKMP 对等方必须为每个 ISAKMP SA 仅建立一个非 ISAKMP 安全联盟（例如 IPsec 安全联盟）。密钥和身份的 PFS 是通过在建立单个非 ISAKMP SA 时删除 ISAKMP SA（并可选地发出 DELETE 消息）来完成的。通过这种方式，第一阶段协商唯一地绑定到单个第二阶段协商，并且在第一阶段协商期间建立的 ISAKMP SA 永远不会再次使用。

使用此处定义的任何组从 Diffie-Hellman 交换派生的密钥的强度取决于组的固有强度、所用指数的大小以及所用随机数生成器提供的熵。由于这些输入，很难确定任何已定义组的密钥强度。当与强随机数生成器和不小于 160 位的指数一起使用时，默认的 Diffie-Hellman 组（第一）足以用于 DES。第二组到第四组提供更高的安全性。在建立策略和协商安全参数时，实现应该注意这些保守的估计。

请注意，这些限制是针对 Diffie-Hellman 组本身的。IKE 中没有任何内容禁止使用更强的组，也没有任何内容会稀释从更强的组中获得的强度。事实上，IKE的可扩展框架鼓励定义更多的组；使用椭圆曲线组将使用更小的数字大大增加强度。

对于定义的组提供的强度不足的情况，可以使用新组模式来交换提供必要强度的 Diffie-Hellman 组。In 有责任在实施中检查所提供的组中的素数并独立地得出强度估计。

假设此交换中的 Diffie-Hellman 指数在使用后从内存中删除。特别是，这些指数不能从长期存在的密钥（如种子到伪随机发生器）中推导出来。

IKE 交换维护运行初始化向量 (IV)，其中最后一条消息的最后一个密文块是下一条消息的 IV。为了防止重传（或带有有效 cookie 的伪造消息）导致交换不同步，IKE 实现不应该更新其运行的 IV，直到解密的消息通过基本的健全性检查并确定实际推进 IKE 状态机 -即它不是重传。

虽然主模式的最后一次往返（以及可选的野蛮模式的最后一条消息）是加密的，但严格来说，它没有经过身份验证。对密文的主动替换攻击可能导致有效载荷损坏。如果此类攻击破坏了强制有效载荷，则认证失败会检测到它，但如果它破坏了任何可选有效载荷（例如，链接到主模式交换的最后一条消息的通知有效载荷），则可能无法检测到。

11、 IANA 考虑

该文档包含许多由 IANA 维护的“magic numbers”。本节解释了 IANA 用于在这些列表中的每一个中分配附加号码的标准。

11.1、属性类

本协议中协商的属性由它们的类标识。分配新类的请求必须附有描述该属性使用的标准跟踪 RFC。

11.2、加密算法类

加密算法类的值定义了在本文档中调用时要使用的加密算法。分配新加密算法值的请求必须附有对标准轨道或信息 RFC 的引用，或对描述此算法的已发布密码文献的引用。

11.3、哈希算法

散列算法类的值定义了在本文档中调用时要使用的散列算法。分配新散列算法值的请求必须附有对标准轨道或信息 RFC 的引用，或对描述此算法的已发布密码文献的引用。由于 IKE 中散列算法的 HMAC 形式的密钥派生和密钥扩展使用，分配新散列算法值的请求必须考虑散列算法本身的密码属性——例如，它的抗冲突性。

11.4、组描述和组类型

组描述类的值标识要在 Diffie-Hellman 交换中使用的组。Group Type Class 的值定义了组的类型。分配新组的请求必须附有对描述该组的标准跟踪或信息 RFC 的引用。分配新组类型的请求必须附有对标准轨道或信息 RFC 的引用，或对描述新类型的已发布加密或数学文献的引用。

11.5、生命类型

Life Type Class 的值定义了 ISAKMP 安全联盟适用的生命周期类型。分配新生命周期类型的请求必须附有此类型单位及其到期日的详细说明。

12、致谢

本文档是与 Hugo Krawczyk、Douglas Maughan、Hilarie Orman、Mark Schertler、Mark Schneider 和 Jeff Turner 密切协商的结果。它依赖于他们编写的协议。没有他们的兴趣和奉献，就不会写出这篇文章。

特别感谢 Rob Adams、Cheryl Madson、Derrell Piper、Harry Varnis 和 Elfed Weaver 在此过程中提供的技术投入、鼓励和各种健全性检查。

我们还要感谢 IPSec 工作组的许多成员，他们在过去一年中为该协议的开发做出了贡献。

13、参考文献

[CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.[BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. Dobb's Journal, v. 19, n. 4, April 1994.[Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983.[DH] Diffie, W., and Hellman M., "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977.[DSS] NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security.[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992.[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard", November 1993.[Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998.[RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's Journal, v. 20, n. 1, January 1995.[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978.[Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 2nd edition.[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue of Standards and Technology, U.S. Department of Commerce, May 1994.[TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", Springer LNCS v. 1039, 1996.

附录 A

这是 DES 弱密钥和半弱密钥的列表。密钥来自 [Sch96]。所有密钥都以十六进制列出。

DES 弱密钥

0101 0101 0101 01011F1F 1F1F E0E0 E0E0E0E0 E0E0 1F1F 1F1FFEFE FEFE FEFE FEFE

DES 半弱密钥

01FE 01FE 01FE 01FE1FE0 1FE0 0EF1 0EF101E0 01E0 01F1 01F11FFE 1FFE 0EFE 0EFE011F 011F 010E 010EE0FE E0FE F1FE F1FEFE01 FE01 FE01 FE01E01F E01F F10E F10EE001 E001 F101 F101FE1F FE1F FE0E FE0E1F01 1F01 0E01 0E01FEE0 FEE0 FEF1 FEF1

属性分配编号

在第一阶段协商的属性使用以下定义。第二阶段属性在适用的 DOI 规范中定义（例如，IPsec 属性在 IPsec DOI 中定义），当快速模式包括临时 Diffie-Hellman 交换时的组描述除外。属性类型可以是基本 (B，Basic) 或可变长度 (V，Variable-length)。这些属性的编码在基本 ISAKMP 规范中定义为类型/值（基本）和类型/长度/值（变量）。

描述为基本的属性不得编码为变量。如果可变长度属性的值可以放入两个八位字节，则它们可以被编码为基本属性。如果是这种情况，本协议发起者作为变量（或基本）提供的属性可以作为基本（或变量）返回给发起者。

属性类

值 17-16383 保留给 IANA。值 16384-32767 供双方同意的私人使用。

类值

值 7-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。

值 4-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。

值 6-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。

值 5-32767 保留给 IANA。值 32768-65535 供双方同意的私人使用。

值 4-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。

值 3-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。对于给定的“生命类型”，“生命持续时间”属性的值定义了 SA 生命的实际长度：要么是秒数，要么是受保护的千字节数。

- PRF

目前没有定义伪随机函数。
值 1-65000 保留给 IANA。值 65001-65535 供双方同意的私人使用。

- 密钥长度

当使用具有可变长度密钥的加密算法时，此属性以位为单位指定密钥长度。（必须使用网络字节顺序）。当指定的加密算法使用固定长度的密钥时，不得使用此属性。

- 字段大小

Diffie-Hellman 组的字段大小（以位为单位）。

- 组顺序

椭圆曲线组的组序。请注意，此属性的长度取决于字段大小。
定义的其他交换-- XCHG 值
快速模式 32
新组模式 33

附录 B

本附录描述了仅在加密 ISAKMP 消息时使用的加密细节。当服务（例如 IPSEC 转换）使用 ISAKMP 生成密钥材料时，所有加密算法的特定细节（例如密钥和 IV 生成、填充等）必须由该服务定义。ISAKMP 并不声称永远生成适用于任何加密算法的密钥。ISAKMP 生成请求数量的密钥材料，服务必须从中生成合适的密钥。诸如弱密钥检查之类的细节是服务的责任。

由于本文档采用的 PRF 反馈机制，协商 PRF 的使用可能需要扩展 PRF 输出。例如，如果（虚构的）DOORAK-MAC 需要 24 个字节的密钥但只产生 8 个字节的输出，则输出必须扩展三倍才能用作其另一个实例的密钥。PRF 的输出通过将 PRF 的结果反馈到自身中来扩展以生成连续的块。这些块被连接起来，直到达到所需的字节数。例如，对于使用 DOORAK-MAC 作为协商 PRF 的预共享密钥身份验证：

BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)

并且

SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24

所以因此得出 SKEYID_d：

并且

SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24

随后的 PRF 推导也类似。

用于保护 ISAKMP SA 的加密密钥是以特定于算法的方式从 SKEYID_e 派生的。当 SKEYID_e 的长度不足以提供算法所需的所有必要的密钥材料时，密钥是通过将伪随机函数的结果输入自身、连接结果并取必要的最高位来推导出来的。

例如，如果（虚构的）算法 AKULA 需要 320 位密钥（并且没有弱密钥检查）并且用于生成 SKEYID_e 的 prf 仅生成 120 位材料，则 AKULA 的密钥将是前 320 位 Ka，其中：

Ka = K1 | K2 | K3

并且

K1 = prf(SKEYID_e, 0)K2 = prf(SKEYID_e, K1)K3 = prf(SKEYID_e, K2)

其中 prf 是协商的 prf 或协商散列函数的 HMAC 版本（如果没有协商 prf），0 由单个八位字节表示。prf 的每个结果提供 120 位材料，总共 360 位。AKULA 将使用该 360 位字符串的前 320 位。

在第 1 阶段，CBC 模式加密算法的初始化向量（IV 材料）的材料来自使用协商散列算法的发起方公共 Diffie-Hellman 值和响应方公共 Diffie-Hellman 值串联的散列。这仅用于第一条消息。应使用包含 0x00 的字节将每条消息填充到最接近的块大小。报头中的消息长度必须包括填充的长度，因为这反映了密文的大小。后续消息必须使用来自前一个消息的最后一个 CBC 加密块作为它们的初始化向量。

在阶段 2 中，用于快速模式交换的第一条消息的 CBC 模式加密的初始化向量的材料是使用协商散列算法从最后一个阶段 1 CBC 输出块和阶段 2 消息 id 的串联的散列中导出的。快速模式交换中后续消息的 IV 是来自前一条消息的 CBC 输出块。后续消息的填充和 IV 在阶段 1 中完成。

在对 ISAKMP SA 进行身份验证后，所有信息交换都使用 SKEYID_e 进行加密。这些交换的初始化向量以与快速模式完全相同的方式导出——即，它是从最后一个阶段 1 CBC 输出块和来自 Informational Exchange（不是来自可能提示信息交换的消息的消息 ID）。

请注意，最后一个阶段 1 CBC 输出块，即最后一个阶段 1 消息的加密/解密结果，必须保留在 ISAKMP SA 状态中，以允许为每个快速模式生成唯一的 IV。每个阶段 1 后的交换（快速模式和信息交换）独立生成 IV，以防止同时启动两个不同的交换时 IV 不同步。

在所有情况下，都有一个双向密码/IV 上下文。让每个快速模式和信息交换保持独特的上下文可以防止 IV 不同步。

DES-CBC 的密钥源自 SKEYID_e 的前八 (8) 个非弱和非半弱（见附录 A）字节。IV是上面导出的IV材料的前8个字节。

IDEA-CBC 的密钥源自 SKEYID_e 的前十六 (16) 个字节。IV 是上面派生的 IV 材料的前八 (8) 个字节。

Blowfish-CBC 的密钥要么是协商的密钥大小，要么是在上述伪随机函数反馈方法中导出的密钥的前五十六 (56) 个字节（如果没有协商密钥大小）。IV 是上面派生的 IV 材料的前八 (8) 个字节。

RC5-R16-B64-CBC 的密钥是协商的密钥大小，或者在必要时从上述伪随机函数反馈方法导出的密钥的前十六 (16) 个字节（如果没有协商密钥大小）。IV 是上面派生的 IV 材料的前八 (8) 个字节。轮数必须为 16，块大小必须为 64。

3DES-CBC 的密钥是在上述伪随机函数反馈方法中导出的密钥的前二十四 (24) 个字节。3DES-CBC 是使用整个 3DES-CBC 密钥的第一个、中间和最后八 (8) 个字节的加密-解密-加密操作。IV 是上面派生的 IV 材料的前八 (8) 个字节。

CAST-CBC 的密钥要么是协商的密钥大小，要么是在上述伪随机函数反馈方法中导出的密钥的前十六 (16) 个字节。IV 是上面派生的 IV 材料的前八 (8) 个字节。

对 DES-CBC 以外的算法的支持完全是可选的。某些可选算法可能会受到知识产权声明的约束。

作者注

作者鼓励这种混合协议的独立实施和互操作性测试。

本文件及其译文可能会被复制和提供给他人，并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文档本身，例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用，除非出于制定 Internet 标准的需要，在这种情况下，版权程序定义在必须遵循 Internet 标准流程，或按照要求将其翻译成英语以外的语言。

上述授予的有限权限是永久性的，不会被互联网协会或其继任者或受让人撤销。

本文档和其中包含的信息按“原样”提供，互联网协会和互联网工程工作队不提供所有明示或暗示的保证，包括但不限于任何保证，即使用此处的信息不会侵犯任何有关适销性或特定用途适用性的权利或任何默示保证。

推荐本站淘宝优惠价购买喜欢的宝贝: