跳到主要内容

2.8. Rekeying (重密钥)

2.8. Rekeying (重密钥)​

IKE, ESP 与 AH 安全关联 (Security Association, SA) 使用的密钥只应在有限时间内使用并保护有限量的数据. 这限制了整个 SA 的生存期. 当 SA 生存期届满时, 绝对不能继续使用该 SA. 若有需要, 可以建立新的 SA. 为取代到期 SA 而重新建立 SA 称为 "rekeying" (重密钥).

为允许最小化 IPsec 实现, 在不重启整个 IKE SA 的情况下重密钥 SA 的能力是可选的. 实现可以拒绝 IKE SA 内的所有 CREATE_CHILD_SA 请求. 若 SA 已到期或即将到期, 且按本文机制进行的重密钥尝试失败, 实现必须关闭 IKE SA 及所有关联 Child SA, 然后可以启动新的. 实现可希望支持原地重密钥 SA, 因为这样性能更好, 且可能减少过渡期间丢失的分组数.

要在已有 IKE SA 内重密钥 Child SA, 应创建新的等价 SA (见下文 2.17 节), 新 SA 建立后删除旧的. 注意, 重密钥时, 新 Child SA 不应与旧的有不同的 Traffic Selector (流量选择子) 与算法.

要重密钥 IKE SA, 在现有 IKE SA 内使用 CREATE_CHILD_SA 与共享旧 IKE SA 的对等方建立新的等价 IKE SA (见下文 2.18 节). 如此创建的 IKE SA 继承原 IKE SA 的全部 Child SA, 新 IKE SA 用于维护这些 Child SA 所需的全部控制消息. 新的等价 IKE SA 创建后, 发起方删除旧 IKE SA, 且删除自身的 Delete 载荷必须是经旧 IKE SA 发送的最后一条请求.

应主动重密钥 SA, 即在新 SA 到期不可用之前先建立新 SA. 新 SA 建立与旧 SA 变为不可用之间应留出足够时间, 以便将流量切换到新 SA.

IKEv1 与 IKEv2 的一点差异是: IKEv1 会协商 SA 生存期. 在 IKEv2 中, SA 的每一端负责执行自身的生存期策略并在需要时重密钥. 若两端策略不同, 生存期较短的一端将总是发起重密钥的一方. 若 SA 长期无活动, 且端点在无流量时本不会发起该 SA, 则当生存期届满时端点可以选择关闭 SA 而非重密钥. 若自上次重密钥以来一直无流量, 亦可如此.

注意 IKEv2 有意允许在相同端点之间并行存在具有相同 Traffic Selector 的 SA. 目的之一是支持不同 SA 之间的流量服务质量 (QoS) 差异 (见 [DIFFSERVFIELD], [DIFFSERVARCH] 与 [DIFFTUNNEL] 的 4.1 节). 因此与 IKEv1 不同, 端点与 Traffic Selector 的组合未必能唯一标识其间的 SA, 故不应使用 IKEv1 基于重复 Traffic Selector 删除 SA 的启发式做法.

存在时间窗口, 尤其在丢包时, 两端可能对某 SA 的状态认识不一致. CREATE_CHILD_SA 的响应方必须准备在发送对创建请求的响应之前就在某 SA 上接受消息, 这样对发起方没有歧义. 发起方可以在处理完响应后立即开始在 SA 上发送. 但发起方在收到并处理完对其 CREATE_CHILD_SA 请求的响应之前, 无法在新创建的 SA 上接收. 那么响应方如何知道何时可以在新 SA 上发送?

从技术正确性与互操作性角度, 响应方可以在发送对 CREATE_CHILD_SA 请求的响应后立即开始在 SA 上发送. 但在某些情况下这可能导致分组被不必要丢弃, 因此实现可以推迟此类发送.

若 (1) 已在 SA 对的另一半上收到密码学上有效的消息, 或 (2) 新 SA 重密钥某已有 SA 且收到关闭被替换 SA 的 IKE 请求, 则响应方可确信发起方已准备好在该 SA 上接收. 重密钥 SA 时, 响应方继续在旧 SA 上发送流量, 直到上述事件之一发生. 建立新 SA 时, 响应方可以推迟在新 SA 上发送消息, 直到收到来自对端的消息或发生超时. 若发起方在某 SA 上收到消息, 但尚未收到对其 CREATE_CHILD_SA 请求的响应, 则将其解释为可能丢包并重传 CREATE_CHILD_SA 请求. 若队列中没有消息, 发起方可以在新创建的 ESP SA 上发送哑 ESP 消息, 以向响应方表明已准备好接收.

2.8.1. Child SA 同时重密钥​

若两端生存期策略相同, 双方可能同时发起重密钥 (导致冗余 SA). 为降低概率, 重密钥请求的时机应该加入抖动 (在发现需要重密钥后随机延迟一段时间).

这种重密钥可能暂时在相同节点对之间产生多个相似 SA. 当有两个 SA 均可接收分组时, 节点必须能通过任一 SA 接受入站分组. 若因碰撞产生冗余 SA, 应用两次交换中所用四个 nonce 中最低者创建的那条 SA 应该由创建它的端点关闭. "最低" 指按字节比较 (而非例如将 nonce 当作大整数比较). 即从第一字节开始比较; 若相等则比较下一字节, 依此类推. 若某一 nonce 先结束, 则该 nonce 更低. 发起存活重密钥 SA 的一方应在新 SA 建立后删除被替换的 SA.

以下说明对实现的影响. 假定主机 A 与 B 有 SPI 为 (SPIa1,SPIb1) 的 Child SA 对, 双方同时开始重密钥:

Host A                            Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
    SA(..,SPIa2,..),Ni1,..  -->
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
recv req2 <--

此时 A 知道正在发生同时重密钥, 但尚不能知道哪次交换的 nonce 更低, 因此只记录情况并照常响应.

send resp2: SA(..,SPIa3,..),
     Nr1,..  -->
                                -->  recv req1

此时 B 也知道同时重密钥正在进行, 照常响应.

                              <--  send resp1: SA(..,SPIb3,..),
                                       Nr2,..
recv resp1 <--
                              -->  recv resp2

此时 A 与 B 之间有三对 Child SA (旧的一对与两对新的). A 与 B 可比较 nonce. 假定 resp2 中 Nr1 为最低; 则 B (req2 的发送方) 删除冗余的新 SA, A (发起存活重密钥 SA 的节点) 删除旧 SA.

send req3: D(SPIa1) -->
                                <--  send req4: D(SPIb2)
                                -->  recv req3
                                <--  send resp3: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->

重密钥完成.

但若网络丢包导致重传, 还可能出现另一序列. 重密钥照常开始, 但 A 的第一个分组 (req1) 丢失.

Host A                            Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
    SA(..,SPIa2,..),
    Ni1,..  -->  (lost)
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
recv req2 <--
send resp2: SA(..,SPIa3,..),
    Nr1,.. -->
                                -->  recv resp2
                                <--  send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
                                -->  recv resp3

从 B 看来重密钥已完成, 且尚未收到 A 的 req1, 甚至不知道曾发生同时重密钥. 但 A 会继续重传, 最终到达 B.

resend req1 -->
                                -->  recv req1

对 B 而言 A 似乎在重密钥已不存在的 SA; 因此 B 以非致命方式响应, 例如 CHILD_SA_NOT_FOUND.

                               <--  send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <--

A 收到该错误时已知曾发生同时重密钥, 可忽略该错误消息.

2.8.2. IKE SA 同时重密钥​

最复杂的情况可能是双方同时尝试重密钥 IKE_SA. 基本上 2.8 节的文字也适用于此; 但必须确保 Child SA 由正确的 IKE_SA 继承.

两端都察觉到同时重密钥时, 与 Child SA 情形相同. CREATE_CHILD_SA 交换后, A 与 B 之间存在三条 IKE SA: 旧的与两条新的. 含最低 nonce 的新 IKE SA 应该由创建它的节点删除, 另一条存活的新 IKE SA 必须继承所有 Child SA.

除正常同时重密钥外, 还有一种特例: 一方在完成重密钥时尚未注意到另一方也在重密钥. 若仅一方检测到同时重密钥, 不会产生冗余 SA. 此时, 未察觉的一方收到重密钥其已成功重密钥的 IKE SA 的请求时, 应该返回 TEMPORARY_FAILURE, 因为它正在尝试关闭该 IKE SA (无论是否已发送该 SA 的删除通知). 若察觉到同时重密钥的一方收到对端删除旧 IKE SA 的请求, 可知对端未检测到同时重密钥, 第一方可以放弃自身的重密钥尝试.

Host A                      Host B
-------------------------------------------------------------------
send req1:
     SA(..,SPIa1,..),Ni1,.. -->
                          <-- send req2: SA(..,SPIb1,..),Ni2,..
                          --> recv req1
                          <-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
                          --> recv req3

此时主机 B 看到关闭 IKE_SA 的请求, 除照常回复外没有太多可做. 但此时 B 应停止重传 req2, 因为一旦 A 收到 resp3, 将删除与旧 IKE_SA 相关的全部状态, 无法再对其作出回应.

                          <-- send resp3: ()

TEMPORARY_FAILURE 通知未包含在 RFC 4306 中, 对 TEMPORARY_FAILURE 的支持也未协商. 因此仅实现 RFC 4306 而未实现本文档的旧对等方可能收到这些通知. 此时它们会像对待任何其他未知错误通知一样处理并停止交换. 由于对方已重密钥该交换, 这样做并无不良后果.

2.8.3. IKE SA 重密钥与重新认证​

在 IKEv2 中, IKE SA 重密钥与重新认证 (reauthentication) 是不同的概念. 重密钥 IKE SA 为 IKE SA 建立新密钥并重置 Message ID 计数器, 但不再次认证双方 (不涉及 AUTH 或 EAP 载荷).

虽然在某些环境中重密钥 IKE SA 很重要, 重新认证 (验证双方仍拥有长期凭据) 往往更重要.

IKEv2 对重新认证没有专门支持. 重新认证通过从零创建新 IKE SA (使用 IKE_SA_INIT/IKE_AUTH 交换, 不带任何 REKEY_SA Notify 载荷), 在新 IKE SA 内创建新 Child SA (不带 REKEY_SA Notify 载荷), 最后删除旧 IKE SA (同时删除旧 Child SA) 来完成.

这意味着重新认证也会为 IKE SA 与 Child SA 建立新密钥. 因此, 虽然重密钥可以比重新认证更频繁, 但 "认证生存期" 短于 "密钥生存期" 的情形没有意义.

虽然任一方 (原 IKE SA 中的发起方或响应方) 都可发起创建新 IKE SA, 但 EAP 与/或 Configuration 载荷的使用意味着实践中重新认证须由原 IKE SA 的同一方发起. IKEv2 目前不允许响应方在此情形下请求重新认证; 不过有扩展可增加此能力, 例如 [REAUTH].

最后于 更新