2.15. IKE SA 的认证

当不使用可扩展认证 (见第 2.16 节) 时, 对端通过让每一方对一块数据签名 (或者使用一个填充的共享密钥作为密钥进行 MAC 运算, 如本节后面所述) 来进行认证。在这些计算中, IDi' 和 IDr' 是除固定头部之外的整个 ID 载荷。对于响应方, 要签名的八字节从第二条消息 (IKE_SA_INIT 响应) 头部中第一个 SPI 的第一个八字节开始, 到第二条消息中最后一个载荷的最后一个八字节结束。附加在其后 (用于计算签名) 的是发起方的随机数 Ni (只是值, 而不是包含它的载荷), 以及值 prf(SK_pr, IDr')。注意, 随机数 Ni 和值 prf(SK_pr, IDr') 都不会被传输。类似地, 发起方对第一条消息 (IKE_SA_INIT 请求) 签名, 从头部中第一个 SPI 的第一个八字节开始, 到最后一个载荷的最后一个八字节结束。附加在其后 (用于计算签名) 的是响应方的随机数 Nr, 以及值 prf(SK_pi, IDi')。对交换的安全性至关重要的点是: 每一方都必须对对方的随机数签名。

发起方签名的八字节可以描述为:

响应方签名的八字节可以描述为:

注意, 所有载荷都包含在签名之下, 包括本文档中未定义的任何载荷类型。如果交换的第一条消息被发送了多次 (例如带有响应方 cookie 和/或不同的 Diffie-Hellman 组), 被签名的是该消息的最新版本。

可选地, 消息 3 和 4 可以 (MAY) 包含一个证书, 或提供计算数字签名的密钥属于 ID 载荷中名字的证据的证书链。签名或 MAC 将使用由签名者使用的密钥类型决定、并由认证 (Authentication) 载荷中的认证方法字段指定的算法来计算。不要求 (REQUIRED) 发起方和响应方使用相同的密码算法进行签名。密码算法的选择取决于各自拥有的密钥类型。特别地, 发起方可能使用共享密钥, 而响应方可能拥有公开签名密钥和证书。常见的情况 (但不要求) 是, 如果使用共享密钥进行认证, 则在两个方向上使用相同的密钥。

注意, 一个常见的但通常不安全做法是拥有仅从用户选择的口令派生的共享密钥, 而不包含其他随机性来源。这通常是不安全的, 因为用户选择的口令不太可能具有足够的不可预测性以抵抗字典攻击, 并且这些攻击在这种认证方法中未被阻止。(使用基于口令的认证进行引导 (bootstrapping) 和 IKE SA 的应用程序应使用第 2.16 节中的认证方法, 该方法旨在防止离线字典攻击。) 预共享密钥需要包含与所协商的最强密钥一样多的不可预测性。在预共享密钥的情况下, AUTH 值计算如下:

对于发起方: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), ) 对于响应方: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), )

其中字符串 "Key Pad for IKEv2" 是 17 个 ASCII 字符, 无空终止符。共享密钥可以是可变长度。添加填充字符串, 以便如果共享密钥是从口令派生的, IKE 实现不需要以明文存储口令, 而可以存储值 prf(Shared Secret,"Key Pad for IKEv2"), 该值不能被用作除 IKEv2 以外协议的口令等价物。如上所述, 从口令派生共享密钥是不安全的。使用这种构造是因为预期人们无论如何都会这样做。提供共享密钥的管理接口必须 (MUST) 接受至少 64 个八字节的 ASCII 字符串, 并且必须 (MUST) 在将它们用作共享密钥之前不添加空终止符。它也必须 (MUST) 接受共享密钥的十六进制编码。如果翻译编码到二进制字符串的算法已指定, 管理接口可以 (MAY) 接受其他编码。

EAP 认证有两种类型 (在第 2.16 节中描述), 每种类型在上面所示的 AUTH 计算中使用不同的值。如果 EAP 方法是生成密钥的, 在计算中用主会话密钥 (MSK) 替代共享密钥。对于非生成密钥的方法, 在两个 AUTH 计算中分别用 SK_pi 和 SK_pr 替代共享密钥。

2.15. IKE SA 的认证​

2.15. IKE SA 的认证