组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：sword (sword zxl1025@chinese.com)
译文发布时间：2001-7-25
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本
文档的翻译及版权信息。
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）。如果
客户身份没有被快速模式的响应者所接受（由于策略或其它原因），一个通知消息类型为
INVALID-ID-INFORMATION (18)的通知负载将发出。
在双方之间有多个隧道存在的情况下，客户身份用于标识并指导流量进入对应的隧道，同时也
用于支持不同粒度的唯一和共享SA。
快速模式期间所发出的所有消息逻辑上是相关的并且必须一致。例如，如果KE负载被发出，
描述Diffie-Hellman组的属性（参看6.1节和[Pip97]）必须被包括在协商的 SA中的每个提议
（proposal）中的每个转换（transform）之中。同样的，如果使用了客户身份，则它们必须应用到协
商的每个SA中。
快速模式定义如下：
发起者 响应者
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
其中：
HASH（1）是从ISAKMP报头中的消息id（M-ID）开始，连接跟在hash后的整个消息的prf
结果,其中包括所有的负载头，但不包括为加密而加入的填充。HASH（2）和HASH（1）一样，除
了发起者的不包含负载头的当前时间（nonce）——Ni被增加在M-ID后，完整的消息之前。HASH
（2）中添加当前时间是为了增加参与证据。用于参与的HASH（3）是用单个字节代表的值0，后
跟串联着的消息id和除去负载头的两个当前时间（nonce）——先是发起者的，后跟响应者的nonce
的prf结果。换句话说，以上的交换的hash是：
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”是从包含协商的转换（transform）负载的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（从第一阶段协商中衍生）继续用于保护和验证ISAKMP
SA，同时SKEYID_d继续用于衍生密钥。
使用快速模式，多个SA和密钥可以使用一个交换来协商，如下所示：
发起者 响应者
----------- -----------
HDR*, HASH(1), SA0, SA1, Ni,
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA0, SA1, Nr,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
密钥材料和在单个SA的情况中一样的衍生出来。在这种情况下（两个SA负载的协商），结果
将是四个安全联盟——每个方向两个。
5.6 新组模式
新组模式不能在ISAKMP SA建立之前使用。新组的描述只能跟在第一阶段协商之后。（虽然它
也不是第二阶段的交换）。
发起者 响应者
----------- -----------
HDR*, HASH(1), SA -->
<-- HDR*, HASH(2), SA
其中HASH（1）是prf的输出，它使用SKEYID_a作为密钥，从ISAKMP报头中的消息ID开
始，串接整个SA的提议（包括头和数据部分）作为数据；HASH（2）也是prf的输出，它使用SKEYID_a
作为密钥，同时从ISAKMP报头中的消息ID开始，串接应答作为数据。换种方式表达，上面交换
的hash为：
HASH(1) = prf(SKEYID_a, M-ID | SA)
HASH(2) = prf(SKEYID_a, M-ID | SA)
提议将指定组的特性（参看附录A，“属性分配编号”）。私有组的组描述必须大于或等于2^15。
如果组不能被接受，响应者必须使用消息类型设为ATTRIBUTES-NOT-SUPPORTED (13)的通知负载
来应答。
ISAKMP的实现可以要求私有组在建立的它的SA中设置超时。
组可以在主模式的SA提议中直接协商。对于MODP组来说，要达到这目的，必须将下列值作
为SA的属性来传递（参看附录A）：类型、素数和产生器；对于EC2N组来说，需要类型、不可约
分多项式、组产生器1、组产生器2、组曲线A、组曲线B和组顺序。另一方面，使用新组模式，组
的种类（nature）可以隐藏，同时在第一阶段的协商中只有组标识符以明文方式传递。
5.7 ISAKMP信息交换
本协议在可能时保护ISAKMP信息交换。当使用本协议时，一旦ISAKMP安全联盟已经建立（同
时SKEYID_e 和 SKEYID_a也已产生），则ISAKMP信息交换就如下所示：
发起者 响应者
----------- -----------
HDR*, HASH(1), N/D -->
其中N/D要么是ISAKMP通知（notify）负载，要么是ISAKMP删除（delete）负载，同时HASH
（1）是prf的输出，它使用SKEYID_a作为密钥，而本交换唯一的M-ID和串接的整个信息负载（通
知负载或者删除负载）作为数据。换种方式表达，上面交换的hash为：
HASH(1) = prf(SKEYID_a, M-ID | N/D)
和提到过的一样，ISAKMP报头中的消息ID——也用在prf的计算中——是这个交换中唯一的，
不能和产生这次信息交换的第二阶段交换中的另一个消息ID相同。使用SKEYID_e来加密这个消息
时，初始向量的导出在附录B中描述。
如果ISAKMP安全联盟在信息交换时还没有建立，则交换就以明文发送，同时没有HASH负载。
6 Oakley组
使用IKE，进行Diffie-Hellman交换的组是协商而得的。下面定义了四个组，从1到4。这些组
起源于Oakley协议，因此被称为“Oakley组”。组的属性类在附录A中定义。所有大于等于2^15
的值都作为私有组的标识符。对于缺省Oakley组强度的讨论，请参考下面的安全考虑一节。
这些组都是由Richard Schroeppel在Arizona大学中创造出来的。它们的属性在[Orm96]中描述。
6.1 第一个Oakley缺省组
Oaklay的实现必须支持有下列素数和产生器的MODP组。这个组分配的id号为1。
素数为: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
它的16进制值为：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
产生器为：2
6.2 第二个Oakley组
IKE的实现必须支持有下列素数和产生器的MODP组。这个组分配的id号为2。
素数为2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }。
它的16进制值为：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
产生器为2（十进制）。
6.3 第三个Oakley组
IKE的实现应该支持有下列特征的EC2N组：组被分配的id号为3。曲线是基于伽罗瓦域
GF[2^155]，域大小为155。域的不可约多项式为：
u^155 + u^62 + 1
椭圆曲线的方程为：
y^2 + xy = x^3 + ax^2 + b
域大小：155
组素数/不可约多项式：0x0800000000000000000000004000000000000001
组产生器1：0x7b
组曲线A：0x0
组曲线B：0x07338f
当使用这个组时，KE负载中的数据就是解答（x，y）中的值x，曲线上点的选择是通过随机选
择秘密Ka并计算Ka*P而来，其中*代表组相加并加倍的不断重复的操作，P是x坐标等于产生器1
的值，y坐标为由所定义的方程计算出的值所确定的曲线上的一点。曲线的方程式由组类型和系数A
和B隐含确定。对于y坐标有两个可能的值；任何一个都可成功的使用（双方不需要对选择达成共
识）。
6.4 第四个Oakley组
IKE的实现应该支持有下列特征的EC2N组：组被分配的id号为4；曲线是基于伽罗瓦域
GF[2^185]，域大小为185。域的不可约多项式为：
u^185 + u^69 + 1
椭圆曲线的方程为：
y^2 + xy = x^3 + ax^2 + b
域大小：185
组素数/不可约多项式：0x020000000000000000000000000000200000000000000001
组产生器1：0x18
组曲线A：0x0
组曲线B：0x1ee9
当使用这个组时，KE负载中的数据和使用Oakley组3时一样。
使用新组模式也可定义其它组。这些组是由Richard Schroeppel在Arizona大学中创建出来的。
这些素数的特性在[Orm96]中定义。
7. 完整IKE交换的负载爆炸
这一节说明IKE协议的使用目的：
—在ISAKMP进程间（第一阶段）建立一个安全并经过验证的信道；同时
—为IPsec SA（第二阶段）产生密钥材料，并协商。
7.1 使用主模式的第一阶段
下列图表说明在双方的第一个传输往返的交换中的负载交换。发起者可以提出多个提议；响应
者只能用一个来回答。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_SA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ prefered SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
响应者选择一个转换的（transform）提议（ISAKMP SA的属性）来应答。
第二个交换由下列负载组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
共享密钥SKEYID_e和SKEYID_a现用于保护和验证所有后继的通信。注意SKEYID_e和
SKEYID_a都未经过验证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
如5.1节所描述的一样，密钥交换是用签名的hash来验证的。一旦签名使用作为ISAKMP SA
协商的一部分的验证算法来校验且通过了，则共享密钥、SKEYID_e和SKEYID_a可以被认为经过
验证了。（为简洁起见，证书负载没有被交换）。
7.2 使用快速模式的第二阶段
下列负载在进行ISAKMP SA协商的快速模式的第一个传输往返中交换。在这假设的交换中，
ISAKMP协商者作为其它需要验证的部分的代表。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
其中hash的内容如上面5.5节的描述。响应者使用只包含一个转换的相似消息来应答——选择
的AH转换（transform）。依赖于接受，发起者通过协商的安全联盟和密钥材料可以提供密钥引擎。
作为对重放攻击的检查，响应者等待直到收到下一个消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
其中hash的内容在上面的5.5节中描述。
8. 完全后继保密举例
本协议能提供对密钥和身份的PFS。不但ISAKMP协商双方的身份可以由PFS保护，如果可用
的话，连双方为谁进行协商的身份都可以保护。
要为密钥和全部的身份提供完全后继保密，双方要执行下列操作：
o 一次主模式交换来保护ISAKMP双方的身份。
这就建立了一个ISAKMP SA。
o一次快速模式交换来协商其它安全协议保护。
这就在这个协议的两端建立了一个SA。
o删除ISAKMP SA和与它相关的状态。
因为在非ISAKMP SA中使用的密钥是从单个临时Diffie-Hellman交换中衍生出的，PFS是保留
的。
如只是为非ISAKMP安全联盟的密钥提供完全后继保密，则在ISAKMP SA已经在两端存在的
情况下，就没有必要进行第一阶段的交换了。所有需要的只是一个包含可选的KE交换的快速模式
和一次额外的Diffie-Hellman交换。在这一步上，如同5.5节所描述的一样，从快速模式衍生出来的
状态必须从ISAKMP SA中删除。
9.实现提示
使用单个ISAKMP第一阶段协商使得后继的第二阶段协商非常的快。只要第一阶段的状态保留
在缓存中，并且不需要PFS，第二阶段就可以进行而不用进行求幂运算。在单个第一阶段协商后，
可以有多少个第二阶段协商，这取决于本地策略。其决定依赖于使用的算法的强度和双方系统的信
赖等级。
实现中可能希望在执行快速模式时，能够协商一系列的SA。通过这样，可以加快“重新生成密
钥”的速度。快速模式定义一系列SA的KEYMAT是怎样确定的。当一方觉得需要改变SA时，只
需要简单的使用声明过的一系列SA中的下一个。一系列SA可以通过在一次快速模式中协商多个
SA（同样的属性，不同的SPI）来建立。
一个很有用的优化方法是在双方需要安全联盟之前就建立它，这样当需要时就已经有了。这样
确保在最初的数据发送前没有因密钥管理而产生的延迟。这种优化很容易实现，通过在每次请求安
全联盟时设置多个安全联盟并将还没有被使用的缓存起来。
同样，如果ISAKMP的实现知道很快就需要SA时（例如，替换一个很快就到期的SA），就可
以在需要它之前建立一个新的SA。
基本的ISAKMP规范描述了协议的一方可以通知另一方一些活动的条件——删除安全联盟或对
一些错误的响应，如签名校验失败或负载解密失败。强烈建议这些信息交换在任何情况下都不要响
应。否则会引致“通知之战”——对一个消息的理解失败则发出通知给对方，而对方又不能理解，
又发出自己的通知，但这仍然是不可理解的。
10.安全考虑
本文档讨论的是一种混合协议，将部分的Oakley以及部分的SKEME和ISAKMP相合并，用来
以一种安全和经过验证的方式协商安全联盟，并为之衍生密钥材料。
机密性由使用协商的加密算法来保证。验证由使用协商的方法来保证：数字签名算法；支持加
密的公钥算法；或共享密钥。交换的机密性和验证相当于作为ISAKMP安全联盟的一部分来协商的
属性。
使用快速模式来不停的重新生成密钥会消耗Diffie-Hellman共享秘密的信息量。实现者应该注意
到这个事实并在相同幂期间限制快速模式的交换。
本协议是可以实现密钥材料和身份的完全后继保密（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交换中衍生出的密钥的强度依靠于组本身的强度、使用
的指数的大小、以及使用的随机数产生器提供的信息量。根据这些输入很难确定任何定义组的密钥
强度。缺省的Diffie-Hellman组（第一组）和一个强随机数产生器以及不少于160比特的指数一起使
用时，足够用于DES了。第二组到第四组提供更强的安全性。实现中在建立策略和协商安全参数时
应该考虑到这些保守的估计。
注意，这些限制是对Diffie-Hellman组自身的。IKE中没有限制使用更强的组，也不会减弱从更
强组中得到的强度。事实上，IKE的可扩展的框架支持定义更多的组；使用椭圆曲线组会大大的增
加使用更小的数字时的强度。
在已定义的组没有提供足够强度的情况下，可以使用新组模式来交换能提供必要强度的
Diffie-Hellman组。具体的实现有责任检查提供的组的基本性质并且能独立的达到估计的强度。
总是假设交换中的Diffie-Hellman指数在使用过后就从内存中删除了。更为具体的，这些指数不
能从长期存在的秘密，如伪随机数产生器中的种子（seed）中衍生。
IKE交换维持不断改变的初始向量（IV），即最后的消息的最后的密文块就是下一个消息的IV。
为阻止重播（或有着有效cookie的伪造消息）引起同步IKE产生交换，实现中不能立即更新IV，除
非解密的消息通过了基本的完整性检查并且被用于实际改变IKE状态机——也就是说，这不是一个
重播消息。
虽然主模式的最后一个传输往返（以及积极模式可选的最后一个消息）是加密的，但严格的说，
它们并没有验证。一个密文形式的主动置换攻击会导致负载损坏。如果这样的攻击破坏了强制性的
负载，它将会由于验证失败而被发现，但如果它破坏了任何可选的负载（例如链接到主模式交换中
最后一个消息前的通知负载），它就不会被发觉。
11.IANA考虑
本文档包含许多由IANA维护的“幻数”。这一节解释由IANA使用来在每一个列表中分配另外
的数字的标准。
11.1 属性类
本协议中协商的属性由它们的种类来识别。分配一个新种类的请求必须伴随一个描述这些属性
的使用的标准跟踪RFC。
11.2 加密算法类
在本文档中使用的加密算法种类的值定义了一个使用的加密算法。分配一个新加密算法值的请
求必须伴随对一个标准跟踪或信息RFC的参考，或对描述这个算法的已出版的密码学书籍的参考。
11.3 hash算法
在本文档中使用的hash算法中类的值定义了一个使用的hash算法。分配一个新hash算法值的
请求必须伴随对一个标准跟踪或信息RFC的参考，或对描述这个算法的已出版的密码学书籍的参考。
由于在IKE中，密钥衍生和密钥扩展使用hash算法的HMAC形式，分配一个新hash算法值的请求
必须考虑到hash算法自身的密码的特性——例如它的抗冲突性。
11.4 组描述和组类型
组描述种类的值标识在Diffie-Hellman交换中使用的组。组类型类的值定义组的类型。分配一个
新组的请求必须伴随对一个描述这个组的标准跟踪或信息RFC的参考。分配一个新组类型的请求必
须伴随对一个标准跟踪或信息RFC的参考，或对描述这个新类型的已出版的密码学书籍或数学书籍
的参考。
11.5 存活期类型
存活期类型种类的值定义了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]中得来。所有的密钥以16进制列出。
DES 弱密钥：
0101 0101 0101 0101
1F1F 1F1F E0E0 E0E0
E0E0 E0E0 1F1F 1F1F
FEFE FEFE FEFE FEFE
DES 半弱密钥：
01FE 01FE 01FE 01FE
1FE0 1FE0 0EF1 0EF1
01E0 01E0 01F1 01F1
1FFE 1FFE 0EFE 0EFE
011F 011F 010E 010E
E0FE E0FE F1FE F1FE
FE01 FE01 FE01 FE01
E01F E01F F10E F10E
E001 E001 F101 F101
FE1F FE1F FE0E FE0E
1F01 1F01 0E01 0E01
FEE0 FEE0 FEF1 FEF1
属性分配号码
第一阶段的属性协商使用下列定义。第二阶段的属性定义在可应用的DOI规范中（例如，IPsec
属性定义在IPsec DOI中），除了在快速模式中包含一个临时Diffie-Hellman交换时的组描述。属性
类型可以是基本（B）或是变长（V）。这些属性的编码在基本ISAKMP规范中定义为类型/值（基本）
和类型/长度/值（变长）。
被描述为基本的属性不能作为变长来编码。而如果变长属性的值在能装在两个字节的情况下，
可以作为基本属性来编码。在这种情况下，本协议的发起者提供的变长（或基本）属性可能作为基
本（或变长）返回给发起者。
属性种类
种类 值 类型
-----------------------------------------------------------------------------------------
加密算法 1 B
Hash算法 2 B
验证方法 3 B
组描述 4 B
组类型 5 B
组素数/不可约多项式 6 V
组产生器1 7 V
组产生器2 8 V
组曲线A 9 V
组曲线B 10 V
存活期类型 11 B
存活期长度 12 V
PRF 13 B
密钥长度 14 B
域大小 15 B
组顺序 16 V
值17-16383保留给IANA。值16384-32767用于相互同意的双方私下使用。
种类值
- 加密算法 定义在
DES-CBC 1 RFC 2405
IDEA-CBC 2
Blowfish-CBC 3
RC5-R16-B64-CBC 4
3DES-CBC 5
CAST-CBC 6
值7-65000保留给IANA。值 65001-65535在相互同意的双方之间私下使用。
- Hash算法 定义在
MD5 1 RFC 1321
SHA 2 FIPS 180-1
Tiger 3 参看[TIGER]
值4-65000保留给IANA。值65001-65535在相互同意的双方之间私下使用。
-验证方法
共享密钥 1
DSS签名 2
RSA 签名 3
使用RSA加密 4
修改过的RSA加密 5
值6-65000保留给IANA。值65001-65535在相互同意的双方之间私下使用。
- 组描述
缺省768比特 MODP 组 （6.1节） 1
另一个1024比特 MODP组（6.2节） 2
使用GP[2^155]的EC2N组 （6.3节） 3
使用GP[2^185]的EC2N组（6.4节） 4
值5-32767保留给IANA。值32768-65535在相互同意的双方之间私下使用。
- 组类型
MODP （模求幂组） 1
ECP (基于GF[P]的椭圆曲线组) 2
EC2N (基于GF[2^N]的椭圆曲线组) 3
值4-65000保留给IANA。值65001-65535在相互同意的双方之间私下使用。
- 存活期类型
秒 1
千字节 2
值3-65000保留给IANA。值65001-65535在相互同意的双方之间私下使用。对于给定的“存活
期类型”，“存活期长度”属性的值定义SA存活期的实际长度——或者为秒数，或者为保护的千字
节数。
- PRF
当前没有定义的伪随机函数。
值6-65000保留给IANA。值65001-65535在相互同意的双方之间私下使用。
- 密钥长度
当使用有可变长度密钥的加密算法时，这个属性以比特为单位指定了密钥的长度。（必须使用网
络字节序）。当指定的加密算法使用固定长度密钥时，这个属性不能使用。
- 域大小
以比特为单位的Diffie-Hellman组的域大小。
- 组顺序
椭圆曲线组的组顺序。注意这个属性的长度依赖于域大小。
定义的额外交换-- XCHG值
快速模式 32
新组模式 33
附录B
附录描述了只在进行ISAKMP消息加密时使用的加密细节。当服务（例如IPSEC转换
（transform））利用ISAKMP来产生密钥材料时，所有加密算法的特定细节（例如密钥和IV的产生，
填充，等等）必须由这个服务来定义。ISAKMP不支持产生的密钥可适用于任何加密算法。ISAKMP
产生请求数量的密钥材料，而服务必须产生适合的密钥。细节，例如弱密钥检查，是服务的责任。
由于本文档采用的PRF回馈机制，使用协商的PRF可能会要求PRF的输出被扩充。例如，如
果（ficticious）DOORAK-MAC要求24字节的密钥，但只产生了8字节的输出，则输出在被用作密
钥前，必须通过将它作为自己的另一个实例的密钥来扩充到3倍的大小。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:
BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
以及
SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
后继的PRF的衍生作同样的处理。
用于保护ISAKMP SA的加密密钥用算法特定的方式从SKEYID_e中衍生。当SKEYID_e用来
提供算法需要的所有必要的密钥材料时出现不够长的情况，就通过回馈伪随机函数的结果给自己，
并将结果串联起来，最后从高位开始取需要的比特数的方法来衍生密钥。
例如，如果（ficticious）算法AKULA要求320比特的密钥（且没有弱密钥检查），同时用于产
生SKEYID_e的prf只产生了120比特的材料，则AKULA的密钥将是Ka的头320比特，其中：
Ka = K1 | K2 | K3
且
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)
其中prf是协商的prf或是协商的HMAC版本的hash函数（如果没有协商prf），同时0由一个
字节来代表。每个prf提供总的360比特中的120比特的材料。AKULA将使用360比特串中的头320
比特。
在第一阶段，对于CBC模式加密算法的初始向量材料（IV材料）是从hash值中衍生出来的，
而这个hash值是使用协商的hash算法对串联起来的发起者的公共Diffie-Hellman值和响应者的公共
Diffie-Hellman值进行hash运算所得的。这只对头一个消息使用。每个消息应该用包含0x00的字节
来填充到最接近的块大小。报头中的消息长度必须包括填充字符的长度，因为这反映了密文的长度。
后继的消息必须使用前一个消息的最后一个CBC加密块来作为自己的初始向量。
在第二阶段，快速模式的第一个消息中的CBC模式加密的初始向量材料是从hash值中衍生的，
这个hash值是使用协商的hash算法对串联的第一阶段的最后一个CBC输出块和第二阶段的消息ID
进行hash运算所得的。快速模式交换中的后继消息的IV是前一个消息的CBC输出块。后继消息的
填充和IV处理和第一阶段中的处理一样。
在ISAKMP SA已经被验证后，所有的消息交换都使用SKEYID_e进行加密。这些交换的初始
向量的衍生方式和快速模式中一模一样——即从串联的第一阶段最后的CBC输出块和ISAKMP信
息交换报头中的消息ID（不是引起信息交换的消息中的消息ID）的hash值中衍生出来。
注意，第一阶段的最后一个CBC输出块，即第一阶段的最后一个消息的加密/解密的结果必须
保持在ISAKMP SA状态中，以允许每个快速模式产生唯一的IV。每个第一阶段后期（快速模式和
信息交换）独立的产生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外，支持其它的算法是完全可选的。一些可选的算法可能要服从知识产权的声
明。
作者地址
Dan Harkins
cisco Systems
170 W. Tasman Dr.
San Jose, California, 95134-1706
United States of America
Phone: +1 408 526 4000
EMail: dharkins@cisco.com
Dave Carrel
76 Lippard Ave.
San Francisco, CA 94131-2947
United States of America
Phone: +1 415 337 8469
EMail: carrel@ipsec.org
作者的注释
作者鼓励对本混合协议进行独立的实现和交互性测试。
完全版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2409——The Internet Key Exchange Internet密钥交换（IKE）
1
RFC文档中文翻译计划