IKEV2报文解析

目录

ikev2报文结构（加密/解密）​

ikev2部分rfc翻译

 2.15. Authentication of the IKE SA

3.6 Certificate Payload

3.7. Certificate Request Payload

Certification Authority字段计算方法

ikev2证书模式签名时，摘要的算法方案

参考

ikev2报文结构（加密/解密）

ikev2部分rfc翻译

 2.15. Authentication of the IKE SA

When not using extensible authentication (see Section 2.16),

当不使用可扩展身份验证时(参见第2.16节)

the peers are authenticated by having each sign (or MAC using a padded shared secret as the key, as described later in this section) a block of data.

通过对数据中的部分数据签名(或使用填充的共享秘密作为密钥的MAC，如本节后面所述)对双方进行身份验证。

In these calculations, IDi’ and IDr’ are the entire ID payloads excluding the fixed header.

在这些计算中，IDi '和IDr ‘是除去固定头的整个ID有效载荷。

For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in the second message.

对于响应方，要签名的字节从第二个消息(IKE_SA_INIT响应)头部的第一个SPI的第一个字节开始，以第二个消息中最后一个负载的最后一个字节结束。

Appended to this (for the purposes of computing the signature) are the initiator’s nonce Ni (just the value, not the payload containing it),and the value prf(SK_pr, IDr’).

附加到此(为了计算签名)的是发起方的nonce Ni(只是值，而不是包含它的负载)和值prf(SK_pr, IDr ')。

Note that neither the nonce Ni northe value prf(SK_pr, IDr’) are transmitted.

注意，既不传输nonce Ni，也不传输值prf(SK_pr, IDr ')。

Similarly, the initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload.

同样地，发起方签名第一个消息(IKE_SA_INIT请求)，从头中的第一个SPI的第一个字节开始，以最后一个负载的最后一个字节结束。

Appended to this (for purposes of computing the signature) are the responder’s nonce Nr, and the value prf(SK_pi, IDi’).

附加到此(为了计算签名)是响应方的nonce Nr和值prf(SK_pi, IDi ')。

It is critical to the security of the exchange hat each side sign the other side’s nonce.

交易双方在对方的协议上签名对交换的安全至关重要。

使用RSA私钥计算，如2.15所示

使用[PKCS1]中指定的RSASSA-PKCS1-v1_5签名方案

(实现者应该注意IKEv1使用了不同的方法

RSA签名)。为了促进互操作性，实现

支持这种类型的签名应该支持使用SHA-1的签名

作为哈希函数，并且应该使用SHA-1作为默认哈希

生成签名时的函数。实现可以使用

从给定对等体接收的证书，作为AUTH有效负载签名选择共同哈希函数的标识。考夫曼等人。标准跟踪RFC 5996 IKEv2bis 2010年9月

但是请注意，AUTH有效负载签名中使用的哈希算法不必与证书中使用的任何哈希算法相同。

3.6 Certificate Payload

证书有效负载(在本文档中表示为CERT)提供了一种通过IKE传输证书或其他与身份验证相关的信息的方法。如果证书对发送方可用，则证书有效载荷应该包含在交换中。证书有效负载的散列和URL格式应该被使用，以防对等端已经表明能够使用HTTP_CERT_LOOKUP_SUPPORTED Notify有效负载从其他地方检索此信息。注意，术语“证书有效负载”有些误导，因为

并非所有身份验证机制都使用证书，并且可以在此有效负载中传递证书以外的数据。

实现必须能够被配置为发送和

接受最多4个X.509证书以支持身份验证，

并且必须能够被配置为发送和接受

哈希和URL格式(使用HTTP URL)。实现应该是

能够被配置为发送和接受原始RSA密钥。如果发送多个证书，第一个证书必须包含

用于对AUTH有效负载进行签名的公钥。其他证书可以按任何顺序发送。

实现必须支持用于哈希和url查找的HTTP [HTTP]方法。其他URL方法[URLS]的行为目前没有指定，在没有文档指定它们的情况下不应该使用这些方法。

3.7. Certificate Request Payload

证书请求有效负载，在本文档中表示为证书，提供了一种通过IKE请求首选证书的方法，并可以出现在IKE_INIT_SA响应和/或IKE_AUTH请求中。当发送方需要获取接收方的证书时，证书请求有效负载可以包含在交换中。证书请求有效负载定义如下：

The Certificate Request payload is defined as follows:

1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Next Payload |C| RESERVED | Payload Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cert Encoding | |

+-+-+-+-+-+-+-+-+ |

˜ Certification Authority ˜

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

证书请求有效负载格式：

证书编码（1个字节）-包含一个证书请求的类型或格式的编码。值列于第3.6节。

认证机构（可变长度）-包含所请求的证书类型的可接受的认证机构的编码。

证书请求有效载荷的有效载荷类型为38（38）。

证书编码字段的值与第3.6节中定义的值相同。证书颁发机构值是受信任的证书颁发机构(ca)的公钥的SHA-1散列的连接列表。每一个编码为主题公钥信息元素的SHA-1哈希(参见[PKIX] 4.1.2.7节)。20个字节的哈希值被连接连接起来，并且不包含其它哈希值格式。

“Certification Authority”字段的内容仅为X.509证书定义，即类型4、12和13。其他值在标准-跟踪规范发布之前不应该使用

注意，术语“证书请求”有些误导，因为“证书”有效负载中定义了除证书之外的值，而对这些值的请求可以出现在证书请求有效负载中。在这种情况下，证书请求有效负载的语法没有在本文档中定义。

通过检查“Cert Encoding”字段来处理Certificate Request有效负载，以确定处理器是否有

此类证书。如果是，则检查“Certification Authority”字段，以确定处理器是否有任何可验证到指定的证书颁发机构之一的证书。这可以是一个证书链。

如果存在满足CERTREQ中规定的条件的终端实体证书，如果CERTREQ的接收者:

• 配置为使用证书验证，

• 允许发送一个CERT有效载荷，

• 有匹配的CA信任策略管理当前协商，而且至少有一个时间和使用合适的最终实体证书链接到CERTREQ中提供的CA。

认证过程中必须考虑证书吊销

用于选择证书的链接过程。注意，即使将两端配置为使用两个不同的ca，也应该通过适当的选择逻辑支持交叉认证关系。

遵循基于CERTREQ的证书选择严格的意图并不是为了阻止沟通，当一个

发送者可以选择备用证书

仍然使接收者能够通过交叉认证传递的信息成功地验证和信任它

带配置的意思是。因此，CERTREQ的处理应该是

这是一个证书选择的建议，而不是强制性的。如果不存在证书，则忽略CERTREQ。这不是协议的错误条件。在某些情况下，可能会在CERTREQ中发送首选CA，但可能会发送备用CA

可以接受(可能是在提示操作员之后)。

HTTP_CERT_LOOKUP_SUPPORTED通知可以包含在任何

消息，该消息可以包含CERTREQ有效负载，并表明发送方能够基于基于http的URL查找证书(因此可能更喜欢以这种格式接收证书规范)。

Certification Authority字段计算方法

使用dd命令从ca证书的der格式中取出subjectPublicInfo信息，通过sha1算法计算其hash值得到的结果，subjectPublicKeyInfo在报文中如下

计算方式如下，其中count为subjectPublicKeyInfo的长度，skip为从证书内容开始跳过多少个字节，of为subjectPublicKeyInfo输出到该文件

openssl dgst -sha1 subjectPublicKeyInfo #表示将subjectPublicKeyInfo文件中的内容通过sha1算法生成摘要

防火墙返回的Certification Authority字段值如下，和通过上述计算得到的结果一致

对于我使用的这个ca证书来说，skip需要跳过298个字节来到达subjectPublicKeyInfo的位置，如下

粗体红框代表证书内容开始一直到subjectPublicKeyInfo开始的位置，从该位置开始读取162个字节即为subkectPublicKeyInfo的内容。

ikev2证书模式签名时，摘要的算法方案

很多厂商使用的摘要算法方案为【rfc3447】中描述的，带有摘要标识，比如sha-256算法会有19个字节的固定头部，因此当计算完签名时，还需要将算法摘要标识加在签名的前面，因此解析的时候做签名验证的时候也需要做同样的处理。

这里要注意的一个点就是，签名算法如果是rsa的话，按rfc文档描述，其默认的摘要算法应该是sha-1，当然这不是必须的。

参考

[安全协议系列（五）---- IKE 与 IPSec]

[rfc5996]

[rfc3447]