IPsec中文RFC

ipsec 中文RFC
Network Working Group D. Harkins Request for Comments: 2409 D. Carrel Category: Standards Track cisco Systems
November 1998
Internet密钥交换（IKE）
（The Internet Key Exchange）
本备忘录的现状
本文档指定了一个Internet 团体的Internet标准协议，并请求讨论和建议以作改进。

请参考当前
版本的“Internet官方协议标准”（STD 1），查看本协议的标准化进程和现状。

本文档的分发不受限
制。

版权通告
Copyright (C) The Internet Society (1998)。

保留所有的权利。

目录
1.摘要 2
2.讨论 2
3.术语和定义 3
3.1必要的术语 3
3.2符号 3
3.3完全后继保密 4
3.4安全联盟 4
4.简介 5
5.交换 6
5.1 使用签名来验证的IKE第一阶段8
5.2 使用公共密钥加密的第一阶段验证8
5.3 使用修改过的公钥加密模式来进行第一阶段的验证10
5.4 使用共享密钥的第一阶段协商11
5.5 第二阶段——快速模式12
5.6 新组模式14
5.7 ISAKMP信息交换15
6 Oakley组15
6.1 第一个Oakley缺省组15
6.2 第二个Oakley组16
6.3 第三个Oakley组16
6.4 第四个Oakley组16
7. 完整IKE交换的负载爆炸17
7.1 使用主模式的第一阶段17
7.2 使用快速模式的第二阶段18
8. 完全后继保密举例20
10.安全考虑21
11.IANA考虑22
11.1 属性类22
11.2 加密算法类22
11.3 hash算法22
11.4 组描述和组类型23
11.5 存活期类型23
12. 鸣谢23
13.参考23
附录A 25
属性分配号码25
属性种类26
种类值26
附录B 28
作者地址30
作者的注释30
完全版权声明31
1.摘要
ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。

ISAKM被设计用
来独立的进行密钥交换，即被设计用于支持多种不同的密钥交换。

Oakley ([Orm96])中描述了一系列被称为“模式”的密钥交换，并详述了每一种提供的服务（如
密钥的完全后继保密（perfect forward secrecy），身份保护，以及验证）。

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

本文档将描述使用部分Oakley，部分SKEME，并结合ISAKMP的一种协议，它使用ISAKMP 来得
到已验证的用于生成密钥和其它安全联盟（如AH，ESP）中用于IETE IPsec DOI的材料。

2.讨论
本文档描述了一种混合协议。

目的是用于以一种保护的方式来协商安全联盟并为它提供经验证
过的密钥生成材料。

本文档中实现的过程可用于协商虚拟专用网（VPN），也可用于远程用户（其IP地址不需要事
先知道）从远程访问安全主机或网络。

支持客户协商。

客户模式即为协商双方不是安全联盟发起的两个终点。

当使用客户模式时，端
点处双方的身份是隐藏的。

本协议并没有实现整个Oakley协议，只实现了满足目的所需要的部分子集。

它并没有声称与整
个Oakley协议相一致或兼容，也并不依靠Oakley协议。

同样，本协议没有实现整个的SKEME协议，只使用了用于验证的公钥加密的方法和使用当
前时间
（nonce）交换来快速重建密钥的思路。

本协议并不依靠SKEME协议。

3.术语和定义
3.1必要的术语
本文档中出现的关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHOULD”，“SHOULD
NOT”以及“MAY”的解释在[Bra97]中描述。

3.2符号
下列的符号在整个文档中都使用。

HDR是ISAKMP的报头，它的交换类型是模式。

当写成HDR*时，意味着负载加密。

SA是有一个或多个提议的SA协商负载。

发起方可能提供多个协商的提议；应答方只能用一个
提议来回答。

<P>_b指明负载<P>数据部分（body）——不包括ISAKMP的通用vpayload负载。

SAi_b是SA负载的数据部分（除去ISAKMP通用报头）——也就是由发起者所提供的DOI、
情况（situation）、所有的提议（proposal）、以及所有的变换（transform）。

CKY-I和CKY-R分别是ISAKMP报头中发起者和响应者的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）是hash负载。

hash的内容是特定于验证方法
的。

prf(key, msg)是key的伪随机函数——通常是key的hash函数——用于产生表现有伪随机性的确
定的输出。

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完全后继保密
在本文档中使用的完全后继保密（PFS）术语是和一个概念相关的，即限制单密钥只能访问到
受本单密钥保护的数据。

要满足PFS，对于用来保护数据传输的已经存在的密钥来说，它就不能用
于衍生出其它的密钥，如果用来保护数据传输的密钥是从其它密钥材料中衍生出来的，则这些材料
就不能再用于衍生任何其它密钥。

在本协议中提供了密钥和身份的完全后继保密（5.5和8 节）
3.4安全联盟
安全联盟（SA）是一组用来保护信息的策略和密钥。

在本协议中，ISAKMP SA
是协商双方为
保护之间的通信而使用的共享的策略和密钥。

4.简介
Oakley和SKEME各自定义了建立经过验证的密钥交换的方法。

其中包括负载的构建，信息负
载的运送，它们被处理的顺序以及被使用的方法。

然而Oakley定义了“模式”，ISAKMP定义了“阶段”。

两者之间的关系非常直接，IKE 描述
了在两个阶段中进行的不同的、称为模式的交换。

第一阶段指两个ISAKMP实体建立一个安全、验证过的信道来进行通信。

这被称为ISAKMP安
全联盟（SA）。

“主模式”和“积极模式”都能完成第一阶段的交换。

“主模式”和“积极模式”只
能在第一阶段中使用。

第二阶段指协商代表服务的安全联盟，这些服务可以是IPsec或任何其它需要密钥材料以及/或
者协商参数的服务。

“新组模式”并不真正在第一阶段或第二阶段中。

它紧接着第一阶段，用于建立可在以后协商
中使用的新组。

“新组模式”只能在第一阶段之后使用。

ISAKMP SA是双向的，即一旦建立，任何一方都可以发起快速模式交换，信息交换，以及新组
模式交换。

由ISAKMP基础文档可知，ISAKMP SA由发起者的cookie后跟响应者的cookie 来标识
——在第一阶段的交换中各方的角色决定了哪一个cookie是发起者的。

由第一阶段的交换所建立的
cookie顺序继续用于标识ISAKMP SA，而不管快速模式、信息、新组交换的方向。

换句话来说，当
ISAKMP SA的方向改变时，cookie不能交换位置。

由于使用ISAKMP阶段，实现中可以在需要时完成快速的密钥交换。

单个第一阶段协商可以用
于多个第二阶段的协商。

而单个第二阶段协商可以请求多个安全联盟。

由于这种优化，实现中每个
SA可以少于一个传输往返，以及少于一次DH求幂运算。

第一阶段中的“主模式”提供了身份保护。

当身份保护不必要时，可以使用“积极模式”以进一步减少传输往返。

下面的内容中包括了开发者
对进行优化的提示。

同时必须注意当使用公共密钥加密来验证时，积极模式仍然提供身份保护。

本协议本身并没有定义自己的DOI。

在第一阶段中建立的ISAKMP SA可以使用非ISAKMP服
务（如IETF IPSec DOI [Pip97]）的DOI和情形（situation）。

在这种情况下，实现中可以限制使用
ISAKMP SA来建立具有相同DOI的服务SA。

另一种方法是使用DOI和情形（situation）为
零值（参
看[MSST98]中对这些域的描述）来建立ISAKMP SA，在这种情况下，实现中可以自由使用ISAKMP
SA来为任何已定义的DOI建立安全服务。

如果使用DOI为零来建立第一阶段的SA，第一阶段中的
标识负载的语法就在[MSST98]中定义，而不是从任何的DOI（如[Pip97]，它可能会进一步扩展标识
的语法和语义）中定义。

IKE使用下面的属性，并且作为ISAKMP安全联盟的一部分来协商。

（这些属性只属于ISAKMP
安全联盟，而不属于ISAKMP为所代表的服务进行协商而建立的任何安全联盟）：—加密算法
—hash算法
—验证方法
—进行Diffie-Hellman操作的组的有关信息。

所有这些属性是强制性的且必须被协商的。

另外，可以可选的协商一个伪随机函数（“prf”）。

（当
前本文档中还没有定义可协商的伪随机函数。

在双方都同意时可以私下使用属性值用于prf 协商。

）
如果没有协商“prf”，协商的HMAC (参看[KBC96])的hash算法就作为伪随机函数。

其它非强制性
的属性在附录A中定义。

选择的hash算法必须支持原始模式和HMAC模式。

Diffie-Hellman组必须使用一个已定义的组描述（第6节）来指定，或者定义一个组的全部属性
（第5.6节）。

组属性（如组类型或素数——参看附录A）不能和以前定义的组（不论是保留的组描
述，还是由新组模式交换后确定并建立的私下使用的描述）相关联。

IKE的实现必须支持以下的属性值：
—使用弱、半弱密钥检查，且为CBC模式的DES[DES]。

（弱、半弱密钥参考[Sch96]，并在附
录A中列出）。

密钥根据附录B进行衍生。

—MD5[MD5]和SHA[SHA]。

—通过共享密钥进行验证。

—对缺省的组1进行MODP（参看下面内容）。

另外，IKE的实现必须支持3DES加密；用Tiger ([TIGER])作为hash；数字签名标准，RSA[RSA]，
使用RSA公共密钥加密的签名和验证；以及使用组2进行MODP。

IKE实现可以支持在附录A中
定义的其它的加密算法，并且可以支持ECP和EC2N组。

当实现了IETF IPsec DOI[Pip97]时，IKE必须实现以上描述的模式。

其它DOI也可使用这里描
述的模式。

5.交换
有两中基本方法可以用来建立经过验证密钥交换：主模式和积极模式。

它们都通过短暂的
Diffie-Hellman交换来产生经过验证的密钥材料。

主模式必须要实现；积极模式最好也实现。

另外，
作为产生新密钥材料和协商非ISAKMP安全服务机制的快速模式也必须要实现。

另外，作为定义
Diffie-Hellman交换私有组机制的新组模式应该要实现。

实现中不能在交换正在进行时改变交换类
型。

交换遵从标准ISAKMP负载语法，属性编码，消息的超时和重传，以及信息消息——例如，当
一个提议未被接时，或者签名验证或解密失败时，一个通知响应就被发送，等等。

在第一阶段交换中，SA负载必须先于任何其它的负载。

除了另外的通知表明在任何消息的
ISAKMP负载中没有需要特定顺序的需求。

不论在第一阶段还是第二阶段中，在KE负载中传递的Diffie-Hellman公共值必须在必要时用零
填充，且长度必须为协商Diffie-Hellman组所需要的长度。

当前时间（nonce）负载的长度必须在8到256个字节之间。

主模式是ISAKMP身份保护交换的实现：头两个消息协商策略；下两个消息交换Diffie-Hellman
的公共值和必要的辅助数据（例如：当前时间（nonce））；最后的两个消息验证Diffie-Hellman 交换。

作为初始ISAKMP交换的验证方法的协商影响负载的组成，而不是它们的目的。

主模式的XCHG就
是ISAKMP身份保护。

类似的，积极模式是ISAKMP积极交换的实现。

头两个消息协商策略，交换Diffie-Hellman 公
共值以及必要的辅助数据，还有身份。

另外，第二个消息还要对响应者进行验证。

第三个消息对发
起者进行验证，并提供参与交换的证据。

积极模式的XCHG就是ISAKMP的积极交换。

在ISAKMP
SA的保护下，如果需要，最后的消息可以不发送，这样允许每一方延迟求幂的运算，直到
这次交换
完成以后再运算。

积极模式的图示中显示最后的负载以明文发送，这不是必须的。

IKE的交换并不是open ended，而是有固定数目的消息。

证书请求负载的回执不能扩展传输或
期待的消息的数目。

积极模式在安全联盟协商中有一定的局限性。

因为在消息构建请求中，Diffie-Hellman交换所需
要的组不能被协商。

另外，不同的验证方法可能进一步限制属性的协商。

例如，利用公共密钥加密
的验证就不能被协商，同时，当使用修改过的公共密钥加密方法来验证时，密码和hash又不能被协
商。

当要利用IKE能协商大量属性的能力时，就需要使用主模式了。

快速模式和新组模式在ISAKMP中没有与之对应的。

它们的XCHG的值在附录A 中定义。

主模式，积极模式，以及快速模式进行安全联盟的协商。

安全联盟的建议（offer）采取下列形
式：转换（transform）负载封装在提议（proposal）负载中，而提议负载又封装在安全联盟（SA）负
载中。

第一阶段交换（主模式和积极模式）中如果多个建议提出，则必须采取下列形式：多个转换
（transform）负载封装在一个提议（proposal）负载中，然后它们又封装在一个SA负载中。

对第一
阶段交换可以换种方式来表述：在单个SA负载中，不能有多个提议负载，同时，也不允许有多个
SA负载。

本文档并不禁止在第二阶段的交换中出现这些形式。

本来发起者发送给响应者的建议（offer）的数量是没有限制的，但出于性能考虑，实现中可以
选择限制将进行检查的建议（offer）的数量。

在安全联盟的协商中，发起者向响应者提出可能的安全联盟的建议（offer）。

响应者不能修改任
何建议的属性，除了属性的编码（参看附录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)
不论是主模式还是积极模式，结果都是产生三组经过验证的密钥材料：
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
以及达成了用于保护通信的一致的策略。

上面的值0，1，2由单个字节的值来代表。

用于加密的密
钥值根据具体的算法（参看附录B）从SKEYID_e中衍生出来。

为了验证交换中的双方，协议的发起者产生HASH_I，响应者产生HASH_R，其中：HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
对于使用数字签名的验证，HASH_I和HASH_R是经过签名并效验的；对于使用公共密钥加密
验证或共享密钥的验证，HASH_I和HASH_R直接验证交换。

整个ID负载（包括ID类型，端口，
协议，但通用报头除外）被hash计算进HASH_I和HASH_R。

正如上面提到的，所协商的验证方法影响第一阶段模式的消息内容和使用，但不影响它们的目
的。

当使用公共密钥来验证时，第一阶段的交换可以使用签名或使用公钥加密（如果算法支持）来
完成。

下面是使用不同的验证选项的第一阶段交换。

5.1 使用签名来验证的IKE第一阶段
使用签名，在第二个传输往返中交换的辅助信息是当前时间（nonce）；通过对相互可以得到的
hash值进行签名来对交换进行验证。

使用签名验证的主模式描述如下：
发起者响应者
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_R
和ISAKMP相关联的带签名的积极模式描述如下：
发起者响应者
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir,
[ CERT, ] SIG_R
HDR, [ CERT, ] SIG_I -->
两种模式中，签名的数据——SIG_I或SIG_R是协商的数字签名算法分别应用到HASH_I或
HASH_R所产生的结果。

总的来说，就象上面说明的一样，签名使用协商的prf，或协商的HMAC hash函数（如果没有
协商prf）来对HASH_I和HASH_R签名。

但是，如果签名算法绑定于特定的hash算法（如DSS只
定义使用SHA 160位的输出），则签名的构建会有不同。

在这种情况下，签名仍然将象上面一样覆
盖HASH_I和HASH_R，但使用和签名方法向关联的HMAC hash算法。

协商的prf和hash 函数将
被用作其它指定的伪随机函数。

既然使用的hash算法已知，就没有必要将它的OID也编码到签名之中。

另外，在PKCS#1的
RSA签名中使用的OID和本文档中使用的OID之间没有关联。

所以，RSA签名在PKCS#1格式中
必须被作为私有密钥加密来编码，而不是作为PKCS#1格式（它包括hash算法的OID）中的签名。

DSS签名必须作为r后跟s来编码。

一或多个证书负载在传递中是可选的。

5.2 使用公共密钥加密的第一阶段验证
使用公共密钥加密来验证交换，交换的辅助信息是加密的当前时间（nonce）。

每一方重新构建
hash（如果另一方能解密当前时间（nonce））的能力就验证了交换。

要执行公钥加密，发起者必须已经拥有响应者的公钥。

当响应者有多个公钥时，发起者用来加
密辅助信息的证书的hash值也作为第三个消息传递。

通过这种方式，响应者可以确定使用哪一个对
应的私钥来解密加密了的负载，同时也保持了身份保护功能。

除了当前时间（nonce）外，双方的身份（IDii和IDir）也使用对方的公钥进行加密。

如果验证
方法是公钥加密，则当前时间（nonce）和身份负载必须使用对方的公钥加密。

只有负载的数据部分
进行了加密，而负载的报头仍为明文形式。

当使用加密作为验证时，主模式定义如下：
发起者响应者
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<IDii_b>PubKey_r,
<Ni_b>PubKey_r -->
HDR, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i
HDR*, HASH_I -->
<-- HDR*, HASH_R
积极模式使用加密作为验证的描述如下：
发起者响应者
----------- -----------
HDR, SA, [ HASH(1),] KE,
<IDii_b>Pubkey_r,
<Ni_b>Pubkey_r -->
HDR, SA, KE, <IDir_b>PubKey_i,
<-- <Nr_b>PubKey_i, HASH_R HDR, HASH_I -->
其中HASH（1）是发起者用于加密当前时间（nonce）和身份的证书的hash（使用协商的hash
函数）。

RSA加密必须被编码进PKCS#1格式中。

当只有ID和当前时间（nonce）负载的数据部分要加
密时，加密的数据前必须有一个有效的ISAKMP通用报头。

负载的长度是整个加密负载加上报头的
长度。

PKCS#1编码可以不用解密而确定明文负载的实际长度。

使用加密来验证提供了可信的可拒绝交换。

没有证据（使用数字签名）表明通信曾经发生过，
因为每一方都可以完全重新构建交换的两方。

另外，秘密的产生也增加了安全，因为袭击者不仅不
得不破解Diffie-Hellman交换，还要破解RSA加密。

这种交换由[SKEME]提出。

注意，与其它的验证方法不一样，公钥加密验证允许积极模式有身份保护。

5.3 使用修改过的公钥加密模式来进行第一阶段的验证
使用公钥加密来进行验证比签名验证（参看5.2节）有更大的优点。

不幸的是，这需要4个公
钥操作为代价——两个公钥加密和两个私钥解密。

而修改过的验证模式保持了使用公钥加密来验证
的优点，但只需要一半的公钥操作。

在这种模式中，当前时间（nonce）仍然使用双方的公钥进行加密，但双方的身份（以及证书）
使用协商的对称加密算法（从SA负载中获得）来加密，其密钥是从当前时间（nonce）中衍生而来。

这种解决方案增加最少的复杂性和状态，而在每一方节省了两个公钥操作。

另外，密钥交换（KE）
负载也使用同一个衍生的密钥进行加密。

这为对Diffie-Hellman交换进行密码分析而提供了额外的保
护。

使用公钥加密的验证方法（5.2节），如果响应者有多个证书包含可用的公钥（例如，如果证书
不只是用于签名，也不受证书限制或算法限制），可以发送HASH负载来标识证书。

如果HASH负
载被发送，他必须是第二个消息交换的第一个负载，同时必须后跟加密的当前时间（nonce）。

如果
HASH负载没有发送，第二个消息交换的第一个负载必须是加密的当前时间（nonce）。

另外，发起
者可以可选的发送证书负载，以提供一个公钥给响应者进行响应时使用。

当使用修改过的加密模式来验证时，主模式定义如下：
发起者响应者
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, [ HASH(1), ]
<Ni_b>Pubkey_r,
<KE_b>Ke_i,
<IDii_b>Ke_i,
[<<Cert-I_b>Ke_i] -->
HDR, <Nr_b>PubKey_i,
<KE_b>Ke_r,
<-- <IDir_b>Ke_r,
HDR*, HASH_I -->
<-- HDR*, HASH_R
积极模式使用修改的加密方法来验证的描述如下：
发起者响应者
----------- -----------
HDR, SA, [ HASH(1),]
<Ni_b>Pubkey_r,
<KE_b>Ke_i, <IDii_b>Ke_i
[, <Cert-I_b>Ke_i ] -->
HDR, SA, <Nr_b>PubKey_i,
<KE_b>Ke_r, <IDir_b>Ke_r,
<-- HASH_R
HDR, HASH_I -->
其中HASH（1）和5.2节相同。

Ke_i和Ke_r是在SA负载交换中协商的对称加密算法的密钥。

只有负载的数据部分加密（公钥和对称密钥操作中都一样），通用的负载的报头保持明文形式。

包含
报头的负载长度用于执行加密操作。

对称加密密钥是从解密的当前时间（nonce）中衍生出来的，如下所示。

先计算值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产生的输出的长度大于或等于密码的密钥长度要求，则
Ke_i和Ke_r分别从Ne_i和Ne_r的最高位衍生。

如果Ke_i和Ke_r需要的长度超过了prf 的输出的
长度，则还需要的比特位通过下列方式得到：不断的将prf输出的结果作为prf的输入，并连接产生
的结果，直到得到需要的长度。

例如：如果协商的加密算法需要320比特的密钥，而prf的输出只有
128比特时，Ke_i就是K的最高320比特，其中：
K = K1 | K2 | K3 and
K1 = 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负载和强制的当前时间（nonce）负载的位置中，就没有其它的负载
请求了。

跟在加密的当前时间（nonce）之后的所有的负载——无论任何顺序——都必须使用Ke_i
或Ke_r来加密，具体使用哪一个取决于方向。

如果CBC模式用于对称加密，则初始向量（IV）如下所设：当前时间（nonce）后的第一个负
载的IV设为0；后继的使用临时对称加密密钥——Ke_i来加密的负载的IV是先前的负载经加密过
后的密文块。

加密过后的负载填充到最接近的块大小。

所有的填充字节都是0x00，除了最后一个字
节。

最后一个填充字节的内容为使用的填充字节数，包括它自己。

注意，这就表示总是有填充的。

5.4 使用共享密钥的第一阶段协商
通过其它带外（out-of-band）机制而衍生出来的密钥也可用于验证交换。

这种密钥实际的建立
过程已经超出了本文档的范围。

当进行共享密钥验证时，主模式定义如下：
发起者响应者
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
使用共享密钥的积极模式描述如下：
发起者响应者
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
当使用共享密钥的主模式时，密钥只能通过双方的IP地址来进行识别，因为HASH_I必须在发
起者处理IDir之前计算出来。

积极模式允许使用大量的共享秘密的标识符。

另外，积极模式还允许
双方维持多个不同的共享密钥，并能对一次特定的交换标识出正确的密钥。

5.5 第二阶段——快速模式
快速模式本身并不是一次完整的交换（因为它和第一阶段交换相关联），但又作为SA协商过程
（第二阶段）的一部分用来衍生密钥材料和协商非ISAKMP SA的共享策略。

快速模式交换
的信息
必须由ISAKMP SA来保护——即除了ISAKMP报头外，所有的负载都要加密。

在快速模式中，
HASH负载必须立即跟随在ISAKMP报头后，SA负载必须紧跟在HASH负载之后。

HASH 用于验
证消息，同时也提供了参与的证据。

在一个特定的ISAKMP SA中，在ISAKMP报头中的消息ID标识了快速模式正在进行中，而
ISAKMP SA本身由ISAKMP报头中的cookie来标识。

因为每个快速模式的实例使用唯一的初始向
量（参看附录B），这就有可能在一个ISAKMP SA中的任一时间内同时有多个快速模式在进行中。

快速模式基本上是一次SA协商和提供重放（replay）保护的当前时间（nonce）交换。

当前时间
（nonce）用于产生新的密钥材料并阻止通过重放攻击产生虚假的安全联盟。

可选的密钥交换（KE）
负载可以经交换来实现通过快速模式产生附加的Diffie-Hellman交换以及求幂运算。

但是必须支持使
用快速模式的密钥交换负载成为可选的。

基本的快速模式（没有KE负载）更新第一阶段的求幂运算所衍生出来的密钥材料。

这并不提
供PFS。

使用可选的KE负载，执行额外的求幂运算，从而为密钥材料提供了PFS。

在快速模式中SA协商中的身份隐含假定为ISAKMP双方的IP地址，且没有对协议或端口号隐
含施加限制，除非在快速模式中客户标识符是指定的。

如果ISAKMP代表另一方作为客户协商代表，
则双方的身份必须传递为IDci和IDcr。

本地策略将决定是否接受身份指定的提议（proposal）。

如果
客户身份没有被快速模式的响应者所接受（由于策略或其它原因），一个通知消息类型为INV ALID-ID-INFORMA TION (18)的通知负载将发出。

在双方之间有多个隧道存在的情况下，客户身份用于标识并指导流量进入对应的隧道，同时也
用于支持不同粒度的唯一和共享SA。

快速模式期间所发出的所有消息逻辑上是相关的并且必须一致。

例如，如果KE负载被发出，
描述Diffie-Hellman组的属性（参看6.1节和[Pip97]）必须被包括在协商的SA中的每个提议
（proposal）中的每个转换（transform）之中。

同样的，如果使用了客户身份，则它们必须应用到协。