RFC2408 Internet 安全关联和键管理协议 (ISAKMP)

RFC2408:
Internet安全联盟和密钥管理协议
(ISAKMP)
Internet Security Association
and Key Management Protocol (ISAKMP)








摘要：
该文档为Internet团体指定了一个Internet标准协议栈。它描述了利用安全概念来建立安全联盟（SA），以及Internet环境中密钥所需的协议。安全联盟协议协商，建立，修改和删除安全联盟，以及Internet环境所需的属性。Internet环境中，有多种安全机制，对于每一种安全机制都有多个可选项。密钥管理协议必须健壮，以处理Internet团体公钥的产生，以及私人网络私钥的产生。Internet安全联盟和密钥管理协议（ISAKMP）定义了认证一个通信同位体，安全联盟的建立和管理，密钥的产生方法，以及减少威胁（例如：服务否认和重放攻击）的过程。在Internet环境里，对于建立和维护安全联盟（经过IP 安全服务和其它安全协议），这些都是必不可少的。

目录
1  介绍 5
1.1  需要的技术术语 5
1.2  所需的商议 6
1.3  什么能够被协商？ 6
1.4  安全联盟和管理 7
1.4.1  安全联盟和注册 7
1.4.2  ISAKMP的需求 7
1.5  认证 8
1.5.1  认证中心 8
1.5.2  实体命名 8
1.5.3  ISAKMP的需求 9
1.6  公钥加密系统 9
1.6.1  密钥交换属性 10
1.6.2  ISAKMP的需要 10
1.7  ISAKMP保护 11
1.7.1  防止障碍(服务否认) 11
1.7.2  拦截连接 11
1.7.3  中途攻击 11
1.8  多播通信 12
2  术语和概念 12
2.1  ISAKMP术语 12
2.2  ISAKMP布置 13
2.3  协商状态 14
2.4  标识安全联盟 15
2.5  其它 17
2.5.1  传输协议 17
2.5.2  保留域 17
2.5.3  反障碍标记的创建 17
3  ISAKMP载荷 18
3.2  ISAKMP头格式 18
3.2  普通载荷头 21
3.3  数据属性 22
3.4  安全联盟载荷 23
3.5  提议载荷 24
3.6  传输载荷 25
3.7  密钥交换载荷 27
3.8  标识载荷 28
3.9  证书载荷 29
3.10  证书请求载荷 31
3.11  哈希载荷 32
3.12  签名载荷 33
3.13  NONCE载荷 33
3.14  通告载荷 34
3.14.1  通告信息类型 36
3.15  删除载荷 38
3.16  厂商ID载荷 40
4.6  证明唯一交换 41
4.7  主动交换 43
4.8  信息交换 44
5  ISAKMP有效载荷处理 44
5.1  普通信息处理 45
5.2  ISAKMP头操作 45
5.3  特殊有效载荷头处理 47
5.4  安全联盟有效载荷处理 48
5.5  提议有效载荷处理 48
5.6  转换有效载荷处理 49
5.7  密钥的交换有效负载的处理 50
5.8  鉴定有效负载的处理 50
5.9  处理的证书有效负载 51
5.10  处理的证书请求有效负载 52
5.11  哈希值有效负载的处理 53
5.12  签名有效负载的处理 53
5.13  目前有效负载的处理 54
5.14  通知有效负载的处理 54
5.15  删除有效负载的处理 56
6  结论 58
A  ISAKMP 安全协会属性 59
A.1  背景 / 基本原理 59
A.2  因特网 IP 安全 DOI 的分配值 59
A.3  支持安全协议 59
A.4  ISAKMP 鉴定类型值 60
A.4.1  ID_IPV4_ADDR 60
A.4.2  ID_IPV4_ADDR_SUBNET 60
A.4.3  ID_IPV6_ADDR 60
A.4.4  ID_IPV6_ADDR_SUBNET 60
B定义新的解释域 60
B.1  状况 61
B.2  安全策略 61
B.3  命名计划 62
B.4  为指定安全服务的句法 62
B.5  有效负载说明 62
B.6  定义新交换类型的 62
安全考虑 62
IANA 考虑 63
解释域 63
支持的安全协议 63
鸣谢 63
参考数目 64
作者地址 66
版权声明 67

1  介绍
此文档描述了因特网安全联盟和密钥管理协议（ISAKMP）。ISAKMP结合加密安全的概念，密钥管理和安全联盟来建立政府，商家和因特网上的私有通信所需要的安全。
因特网安全联盟和密钥管理协议（ISAKMP）定义程序和信息包的格式来建立，协商，修改和删除安全联盟（SA）。SA包括所有如IP层服务，传输或应用层服务或流通传输的自我保护的各种各样的网络协议所需要的信息。ISAKMP定义交换密钥生产的有效载荷和认证数据。这些格式为依靠于密钥产生技术，加密算法和验证机制的传输密钥和认证数据提供了一致的框架。
ISAKMP与密钥交换协议的不同处是把安全联盟管理的详细资料从密钥交换的详细资料中彻底的分离出来。不同的密钥交换协议中的安全道具也是不同的。但一个支持SA属性格式，和谈判，修改与删除SA的共同的框架是需要的。
把函数分离为三部分给一个完整的ISAKMP执行的安全分析增加了复杂性。因此分离在有不同安全要求的系统之间是不被赞成的，而且还应该将更多ISAKMP服务的发展的分析变得简单化。
ISAKMP被用来支持在所有网络堆栈的层上的安全协议的SA的谈判。ISAKMP通过集中安全联盟的管理减少了在每个安全协议中复制函数的数量。ISAKMP还能通过一次对整个服务堆栈的协议来减少建立连接的时间。
剩下的部分，第一节建立安全协议的动机和ISAKMP主要组成部分的概要，也就是安全联盟和管理，认证，公钥密码系统及混合的条款。第二节讲述和ISAKMP相关的术语和概念.第三节不同ISAKMP有效载荷的格式。第四节描述ISAKMP的有效载荷在一种认证方法中是怎样被组织到一起来作为交换类型来建立安全联盟和执行密钥交换。另外，安全联盟的协商，删除和错误通知也将被讨论。第五节描述在ISAKMP交换环境中包括错误句柄和安全行为的有效载荷的处理。附录提供ISAKMP必要的属性值和在ISAKMP中定义一个新的解释域（DOI）的所需要求。
1.1  需要的技术术语
词MUST , MUSTNOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , MAY和OPTIONAL出现在文档时，他们的解释都在[RFC-2119]中描述。
1.2  所需的商议
ISAKMP在[DOW92]中扩充的声明，为了较多的安全认证和密钥交换必须被组合道包括安全联盟的交换中。安全服务需要的通信依靠着个体的网络结构和环境。机构正在建立私有个人网络（VPN）作为企业内部互联网，它将需要需要一套在VPN中通信的安全功能和在VPN之外的通信的许多可能的不同安全功能来支持地理上分开的组织成份，消费者，供应者，分消人，政府和其它。在大组织中的部门也许需要一些安全联盟在网络内来分离协议数据，其它的安全联盟在同样的部门内通信。游动的用户希望“打电话回家”表现出另一个安全需要。这些需要必须由带宽来调节。很少人的组的安全需要也许是要建立“信任网”。 ISAKMP交换提供这些向同等地位的人提出用户为达成协议有关安全的共同的一套支持的证实，而且保护的方法的安全功能性的能力归于多种多样的网络组，也就是一个共同的安全联盟。
1.3  什么能够被协商？
安全联盟必须支持不同安全协议的加密算法，认证机制和密钥生成算法，作为IP的安全。安全联盟还要支持底层协议面向主机的定向证书和高层协议中面向用户的证书。算法和机制的独立在通信定向协议，路由协议，和链路层协议中需要应用于如电子邮件，远程登陆，和文件传输。ISAKMP为安全协议，应用，安全需求和网络环境这个宽广的范围提供了一个共同的安全联盟和密钥生成协议。
ISAKMP不能被限制于任何特定的加密算法，密钥产生技术或安全机制。这种适应性在某些前提下是有好处的。首先，它支持在动态的通信环境下被描述。其次，特定安全机制和算法的独立性为向前移动的路径提供了更好的机制和算法。当改良的安全机制被发展或当前的加密算法受到新的攻击，认证机制和密钥交换被发现时，ISAKMP允许在没有发展出一个新的完整的KMP或到当前的一个路径的情况下，更新算法和机制。
ISAKMP对它的认证和密钥交换部分有基本的要求。这些要求拒绝被否认得服务，重放，窃听和拦截攻击。因为这些类型的攻击，所以被作为目标的协议是很重要的。完整的安全联盟的支持提供独立的机制和算法，及针对议定书威胁的保护措施是ISAKMP的强度支持。
1.4  安全联盟和管理
安全联盟是两个或多个描述实体实怎样利用安全服务来安全通信的实体之间的发关系。这种关系被一套能被认为是两个实体间的契约的信息来描述。这个信息必须被所有的实体承认和共享。有时这个信息被作为SA单独引用，但这只是存在地联系中的一个实例。这种关系和信息的存在，是为安全的相互操的实体提供作所需的一致的安全信息。所有的安全实体必须尽可能的坚持SA的安全通信。当访问SA的属性时，实体用一个指针或标识符访问安全参数索引（SPI）。[SEC-ARCH]提供IP安全联盟（SA）和安全参数索引（SPI）定义的详细内容。
1.4.1  安全联盟和注册
SA所需和被IP安全（AH,ESP）要求的属性在[SEC-ARCH]中被定义。属性为IP安全SA指定了包括但是不被限制的认证机制，加密算法，算法模式，密钥长度和初始化向量（IV）。其它提供的算法和机制的独立的安全协议必须定义SA所需要的属性。把特殊的SA定义从ISAKMP中分开对于能为所有可能的安全协议和应用产生SA束的确信的ISAKMP是十分重要的。
注意：见[IPDOI]中对SA属性的讨论，当定义安全协议或应用时它是可信的。
为了使不同网络实体之间的特殊属性能被容易的识别，这些属性必须被分配标识符，并且这些标识符必须由认证中心注册。IANA为英特网提供这项功能。
1.4.2  ISAKMP的需求
安全联盟的建立必须经过密钥管理协议为IP基本网络的定义。SA被用来支持各种动态网络环境下的安全协议。正如认证和密钥交换必须被链接来提供担保密钥是由认证机关[DOW92]来建立，SA的指定必须被链接到认证和密钥管理协议。
ISAKMP提供协议交换来在跟在一些协议的益处中协商实体的安全联盟体制协商的实体间建立安全联盟（如ESP/AH）。首先，最初的协议交换允许一套基本的安全属性被支持。这套基础为并发的ISAKMP交换提供保护。它还指定将被作为ISAKMP协议的一部分被执行的认证方法和密钥交换。如果一套基础的安全属性已经被放到协商实体之间的话，初始的ISAKMP交换可能被略过，并且安全联盟的建立可能被直接的进行。在这套基础的安全属性被支持，初始的身份认证和必需的密钥产生后，建立的SA能被调用ISAKMP的实体用于并发通信。这套基础的SA属性必须被实现来提供在附录A中定义的互用的ISAKMP。
1.5  认证
在建立安全网络通信时十分重要的一步是在通信的另一端对实体的认证。有很多认证机制能被用到。认证机制实现在两种情况之下——脆弱和强壮。在一个脆弱的网络发送清晰的密钥或未被保护的认证信息，受到网络刺探者读它们的威胁。另外，以低熵发送单行无用的缺乏选择的信号也很危险，会受到刺探信息者的猜测攻击。因为[IAB]中新近的声明，当口令能被用于建立认证时，他们不被认为包含在这个内容内。数字签名，如数字签名标准（DSS）和RSA签名，是基于强大的人证机制下的公钥体制。当应用公钥数字签名时，每个实体都需要一个公钥和一个私钥。证书是数字签名认证体制中的实质部分。证书绑定一个特殊实体的身份和其它可能的安全信息，如特权，清除和象限到它的公钥上。基于数字签名的认证需要一个信任的第三方和证书中心来生成，签名和适当地分发证书。如DSS何RSA这样的数字签名和证书的详细信息可参看[Schneier]。
1.5.1  认证中心
证书需要一个基本组织来产生，确认，撤回，管理和分配它。IPRA[RFC-1422]已经为IETF制定了这个基本组织。IPRA认证PCA。PCA控制CA，CA证明用户和从属的实体。当前有关证书的工作包括DNS安全扩展，将提供DNS内有标识的实体密钥。PKIX工作组正在为X.509证书指定因特网轮廓。它将继续在工业中发展X.500目录服务，它能给用户提供X.509证书。美国邮电部门正在发展一个CA层次。NIST公钥结构工作组已经在这个领域开始工作。DOD MISSI纲要已经开始为美国政府发展一个证书基本组织。作为选择，如果基础组织存在，信任证书的PGP网能被用于提供用户认证和相互信任的用户团体的保密。
1.5.2  实体命名
一个实体的名字是它的身份，并且它证书里的公钥被绑在它里面。CA必须为证书的出版定义名字的符号。作为CA是怎样定义策略名字的例子，可以参看UNINETT PCA策略声明[Berge]。当证书被校验时，名字被校验，并且名字在CA地领域里将有意义。例子是把DNS服务器CAs做成他们服务的域和节点的DNS安全扩展。源档案由公钥提供，数字签名就在这些密钥中。有关密钥的名字是IP地址和域名，它们表明了实体访问DNS的信息。信任网是另外一个例子。当信任网建起时，名字被绑到公钥中。在PGP中，名字通常是实体的电子邮件地址，它来表明只有明白电子邮件的人的意思。另外的信任网可以使用一个完全不同的命名方案。
1.5.3  ISAKMP的需求
必须在ISAKMP交换上提供强大的认证。不能认证另一端实体身份的安全联盟和密钥的生成对话将被怀疑。不经过认证就不能信任实体的身份，它的访问控制是可疑的。当加密（ESP）和完整性（AH）保护被偷听者并发的通信时，没有经过认证的SA合密钥可能是敌对方执行一个拦截攻击生成的，而且可能正在偷取你所有的私人数据。
数字签名算法必须被用到ISAKMP的认证部分。但ISAKMP不要求一个特殊的签名算法或认证中心（CA）。ISAKMP允许一个实体初始化通信时指出支持哪个CA。当选择了一个CA后，协议提供所需的信息来支持实际的认证交换。协议支持不同认证中心，整数类型和证书交换标识的认证设备。
ISAKMP利用基于公钥加密的数字签名来进行身份认证。其它可利用的强壮的认证系统被指定为ISAKMP附选的认证体制。其中一些认证系统依赖一个称为密钥分配中心（KDC）的信任的第三方组织来分配会话密钥。Kerberos是一个例子，这儿信任的第三方组织是Kerberos服务器，它掌管了在这个网络域内所有客户和服务器的密钥。客户拿其密钥的证明给服务器提供认证。
ISAKMP规范没有指定与信任的第三方组织（TTP）或证书目录服务器通信的协议。这些协议在TTP河整数目录服务器中被定义，并且指定了它对外的范围。这些额外服务和协议的使用将在密钥交换这个文档中被描述。
1.6  公钥加密系统
公钥加密系统是用户获得共享密钥的最具灵活性，可升级性和高效性的方法，而且是会话密钥支持的英特网用户相互操作的最多方法。许多有不同属性的密钥产生算法对用户使有利的。密钥交换协议的属性包括密钥产生方法，认证，对称，完全向前保密和向后通行保护。
注意：加密密钥能在一个相当长的时间内保护信息。但这是以假定被用于通信保护的密钥在使用后被破坏的基础上的。
1.6.1  密钥交换属性
密钥产生：为密钥产生使用公共的密钥加密的两个共同的方法是密钥运输和密钥产生。一个密钥传输的例子是RSA算法用来加密一个随机产生的会话公共密钥。加密随机密钥被送到拥有私钥的接收者处。在这一点上两端都有相同的会话密钥，但它是被基于从通信的一端输出而创造的。密钥传输方法的好处是它比下面的方法有更小的计算开销。D-H算法说明了公钥加密体制中密钥的产生。D-H算法由两个用户交换公共信息开始。每个用户用他自己的秘密信息算术的结合其它用户的公共信息来来算出共享密钥值。这个共享值能被用作共享密钥或用来把随机产生的会话密钥的密码化密钥锁上。这种方法基于两个用户的公共和私有信息来产生会话密钥。D-H算法的好处是密钥用于加密信息是基于两个用户和一个到另一个密钥交换的。这些加密算法在[Schneier]中详细描述。在两个密钥生成配置上有许多变化，而这些变化是没必要相互操作的。
密钥交换认证：密钥交换能在协议中或协议完成后被认证。协议中密钥交换的认证是当协议中止之前每个组织提供它有私有回话密钥的证明时被提供的。证明能被在协议交换中加密私有会话密钥中已知的数据提供。在协议之后的认证必须发生在并发的通信中。如果秘密会话密钥没有被所希望的组织建立，协议中的认证被指为未初始化的并发的通信。
对称密钥交换：如果每个组织都能不影响产生的密钥，初始化交叉运行的交换和被交换的信息的话，密钥交换可提供对称。合乎需要，密钥的计算不要求任何一个党知道它们的初始化交换。当需要对称密钥交换时，在整个密钥管理协议中的对称能预防攻击。
完全向前保密：正如[DOW92]中的描述，如果长期密钥资料败露来自先前的通信的交换的钥匙的秘密调解的话，认证密钥交换协议提供完全向前保密。完全向前保密的属性不适用于没有认证的密钥交换。
1.6.2  ISAKMP的需要
一个认证密钥交换必须被ISAKMP支持。用户应该根据他们的必要条件的补充性选择密钥算法。ISAKMP不指定一个特殊的密钥交换。但[IKE]描述了在ISAKMP连接中的Oakley密钥交换的协议。当选择一个包括方法，完全向前保密，计算开销，密钥由第三者保存附带条件委付盖印的契约，和密钥长度的密钥产生算法时，需要应该被评估。基于用户的要求，ISAKMP允许一个实体初始化信息来指出支持那种密钥交换。在选择了一个密钥交换后，协议提供需要的信息来支持实际的密钥产生。
1.7  ISAKMP保护
1.7.1  防止障碍(服务否认)
在众多可利用的安全服务中，对于服务否认得保护常常被视作最难的。一个“cookie”或（TCT）的目的在于不为了决定其确实性花费过度的中央处理器资源而保护计算的资源免受攻击的影响。一个指向加强CPU公钥操作的指针能阻碍一些企图的服务否认。对服务否认得绝对保护是不可能的，但这个防止阻碍标记为让它容易的操作提供了一种技术。防止阻碍标记的使用在[Karn]中由Karn和Simpson来介绍。
在第四节中被说明的交换应被注意，加密机制应被用于废弃的连接机制地连接中。攻击者仍能用伪造IP地址的包注往服务器，并导致状态被创建。这种侵入内存管理的技术应该被协议用到ISAKMP中，不通过初始化，防止阻碍的状态，在[Karn]中被做。
1.7.2  拦截连接
ISAKMP用连接认证，密钥交换和安全联盟交换来防止拦截连接。这种连接防止攻击者在密钥和安全联盟交换期间从允许的认证到完成，然后从模仿的一个实体跳到另一个。
1.7.3  中途攻击
中途攻击包括窃听，插入，删除和窜改信息，返回信息给发送人，回复旧信息和重发信息。ISAKMP的特征能成功的防止这些类型的攻击。ISAKMP交换连接防止协议交换中的信息插入。ISAKMP协议状态机制被定义,因此删除信息不能引起一个局部的SA被建立，状态机制将清理所有的状态，并返回到空闲状态。状态机制还防止信息返回带来的危害。每个新的SA建立的各种不同资料的一个新的cookie的需求防止包括重发旧信息的攻击。ISAKMP强大的认证要求防止用其它故意的组织建立的SA。信息能被发往不同目的地或修改，但这将被删除，并且SA不会被建立。ISAKMP规范定义了已经发生的不正常进程和不正常的组织推荐的通报。
1.8  多播通信
多播通信被希望和单播通信有相同的安全服务，和能引进所需的附加安全服务。多播传输的分配SPIs的发行在[SEC-ARCH]中被介绍。多播安全发行在[RFC-1949]和[BC]中被讨论。ISAKMP将来的扩展将支持多播密钥分配。有关多播安全有关的流出的发行，参考因特网草案[ RFC-2094 ]和[ RFC-2093 ]，描述在这个域中Sparta的研究。
2  术语和概念
2.1  ISAKMP术语
安全协议：安全协议由网络堆栈中单独点的实体组成，为网络通信提供安全服务。例如IPSEC ESP和IPSEC AH是两个不同的安全协议。TLS是另外一个例子。安全协议能提供不止一项服务，如可在一个模块中提供完整性和机密性。
保护组：保护组是必须被各种安全协议执行的安全服务的列表。例如，安全组可能包括IP ESP中的DES加密合IP AH中的密钥MD5。组中的所有保护必须被作为一个单独的单元对待。因为安全服务在不同的安全协议里有敏感的交互作用，并且组的影响必须被作为整体分离和校验，所以它是必要的。
安全联盟（SA）：安全联盟是安全协议指定的一套完整的定义必须的服务和机制的参数来保护安全协议域中的传输。这些参数包括算法标识符，模式，加密密钥等。SA由它的安全联盟协议指定。
ISAKMP SA：被ISAKMP服务应用的SA来保护它自身的传输。2.3和2.4节提供ISAKMP SA的更多详细资料。
安全参数索引（SPI）：安全联盟的标识符，相关的一些安全协议。每个安全协议由它自己的“SPI－space”。一组唯一的识别一个SA。SPI的唯一性是依靠的实现，但是能每个系统每个协议或其他的任意选择被形成了。依靠于DOI地附加信息能必然的标识一个SA。DOI也能决定哪个SPI在通信期间被发出。
解释域：解释域（DOI）定义有效载荷的格式，交换类型和如安全政策或加密算法和模式这样的相应安全信息命名的协定。DOI标识符被用于ISAKMP有效载荷的有效载荷。系统必须同时支持多个DOI。DOI的概念是基于TSIG CIPSO 工作组先前的工作的，但扩展安全实验室的解释包括命名和安全服务的解释。DOI的定义：
* 状态：这套信息将被用于决定所需的安全服务。
* 这套安全政策必须而且能被支持。
* 被提供的安全服务的规范的语法。
* 命名相关安全信息的方案，它包括加密算法，密钥交换算法，安全策略分配和认证中心。
* 不同有效载荷内容的特殊格式。
* 所需的附加交换类型。
IETF IF安全DOI的规则在[IPDOI]中被介绍。用户化DOI的详细规则在分散的文档中被介绍。
状态：状态包含系统认为重要的所有相关安全信息来决定被保护的正在协商的会话密钥所需要的安全服务。状态可以包含地址，安全分类，操作模式等。
提议：提议是减少优先选择顺序的一个系统认为可接受来在被给定的状态下保护传输的保护状态的列表。
有效载荷：ISAKMP定义有效载荷的几种类型，它们被用于传送在被定义DOI格式下的如安全联盟数据或密钥交换数据地信息。有效载荷由一般有效载荷头和ISAKMP中不透明的一个八位串组成。ISAKMP用指定DOI来综合和解释有效载荷。多级有效载荷能在一个单独的ISAKMP信息中被传送。第三节有更多有效载荷类型的详细资料，[IPDOI]中有IETF IF安全DOI有效载荷的格式。
交换类型：交换类型是ISAKMP交换中信息的规范，有效载荷类型被用于提供一套特殊的安全服务，如共享者匿名，密钥资料的完全向前保密，共享者的身份认证等。4.1节定义一套ISAKMP交换类型的默认设置。其它交换类型被加入到所需的支持的附加密钥交换。
2.2  ISAKMP布置
图一是在ISAKMP地网络建筑中的系统环境中的高级布置图。协商安全服务的一个重要部分是把所有的个体SA堆栈看作一个单元。这被作为一个“保护组”。
     +------------+        +--------+                +--------------+
     !     DOI    !        !        !                !      应用    !
     !     定义   ! <----> ! ISAKMP !                !      进程    !
     +------------+    --> !        !                !--------------!
    +--------------+   !   +--------+                ! Appl 协议    !
    !   密钥交换   !   !     ^  ^                    +--------------+
    !     定义     !<--      !  !                           ^
    +--------------+         !  !                           !
                             !  !                           !
            !----------------!  !                           !
            v                   !                           !
        +-------+               v                           v
        !  API  !        +---------------------------------------------+
        +-------+        !                Socket 层                    !
            !            !---------------------------------------------!
            v            !              传输协议 (TCP / UDP)           !
     +----------+        !---------------------------------------------!
     !   安全   ! <----> !                     IP                      !
     !   协议   !        !---------------------------------------------!
     +----------+        !                  链路层协议                 !
                         +---------------------------------------------+
      图1：ISAKMP关系图
2.3  协商状态
ISAKMP提供了两个协商状态。第一个，两个实体同意在他们之间如何保护协商传输，建立ISAKMP SA。ISAKMP SA被用于保护所需SA协议的协商。两个实体能协商多个ISAKMP SA。
第二个协商状态被用于建立其它安全协议的安全联盟。第二个协商能被用于建立多个安全联盟。在状态被安全协议用来保护多个信息/数据交换的过程中，安全联盟被ISAKMP建立。
当两个状态方法对最简单的方案有更高的启动价值时，对于大多数案例有理由是有益的。
首先，实体（例如ISAKMP服务器）能穿过几个第二的阶段协商提取第一个阶段的成本。允许多个SA被建立，而不必为每个在同等地位的通信建立重复的SA。
第二，在第一个状态提供安全属性期间，安全服务为第二个状态协商。例如，在第一个状态协商后，ISAKMP SA提供的密码能提供身份保护，还默认得允许简单的第二个状态交换的使用。另一方面，如果这个通道在第一个状态不提供适当的身份保护期间被建立，第二个状态必须协商适当地安全机制。
第三，相当有适当的ISAKMP SA降低ISAKMP管理活动的成本－不用ISAKMP SA给你的“信赖路径”，将必须SA的为每个错误通知或删除穿过完整的重新认证。
每个状态的协商用定义的ISAKMP交换或DOI中定义的密钥交换来完成。
注意，安全服务被每个协商状态不同的应用。例如，不同的组织在每个协商状态期间被认证。在第一个状态，被认证的组织可能是ISAKMP服务器/主机，当第二个状态时，用户或应用级程序被认证。
2.4  标识安全联盟
当ISAKMP在两个系统之间引导安全通道时，它不能假设安全服务存在，必须对自己提供一些安全保护。因此，ISAKMP认为一个ISAKMP安全联盟与其它类型的不同，并且ISAKMP在它们自己的名称空间内处理它自己的ISAKMP SA。ISAKMP用ISAKMP头中的这两个cookie域来标识ISAKMP SA。ISAKMP头中的信息ID和建议有效载荷中的SPI域在SA建立期间被用来为其它安全协议标识SA。这四个域的解释是依靠操作发生的地点的。
下面的表格现出了在SA建立期间几个域的存在和不存在。以下的域对于各种SA建立相关的操作是必须的：ISAKMP头中的cookies，ISAKMP头的信息ID域，和建议有效载荷中的SPI域。列中的‘X’表示这个值是必须被提出。列中的‘NA’表示列中的值不适用于操作。
  #             操作              I-Cookie  R-Cookie  Message ID    SPI
 (1)  开始ISAKMP协商                X         0         0           0
 (2)  回答 ISAKMP SA 协商            X         X         0           0
 (3)  初始化其它 SA 协商             X         X         X           X
 (4)  回答其它SA 协商               X         X         X           X
 (5)  其它 (KE, ID, etc.)            X         X         X/0         NA
 (6)  安全协议 (ESP, AH)             NA        NA        NA          X
在表的第（1）行，初始值包括初始ISAKMP头中的cookie域，使用程序概括见2.5.3和3.1节。
表中的第二行，回答包括ISAKMP头中的初始化和回答cookie域，使用程序概括见2.5.3和3.1节。附加信息能在同等地ISAKMP间交换，依靠ISAKMP交换类型在状态1协商中的使用。一旦状态1交换完成，初始值和回答cookies北包含在同等地ISAKMP并发通信的ISAKMP头中。
在状态1协商期间，初始值和回答cookie决定了ISAKMP SA。因此，建议有效载荷中的SPI域变得多余，并且被设置成0或包含信号发送实体的cookie。
在表的第三行中，初始化连接一个协议的信息ID，它包含在SA 建议中。这个被连接在每个建议中协议信息ID和初始化的SPI被发往回答者。一旦状态2协商完成，SPI将被安全协议使用。
表中的第（4）行，回答包括相同的信息ID和回答SPI来连接接收建议中的每个协议。这个信息被返回给初始者。
表中的第（5）行，初始者和回答者用ISAKMP头中的信息ID域来保持进程协议协商的轨迹。这只适用于状态2交换，并且这个对状态1的交换的值必须是0。这是因为混合的cookie标识了ISAKMP SA。在建议有效载荷中的SPI域不适用是因为建议有效载荷只在SA协商信息交换中使用。
表中的第（6）行，状态2协商完成。安全协议使用SPI来决定哪个安全服务和机制来应用于它们之间的通信。第6行中的SPI值不是建议有效载荷中的SPI域，但SPI域包含在安全协议头中。
在SA的建立中，SPI必须被产生。ISAKMP被用于处理可变得SPI。这用建议有效载荷中的SPI尺寸域在SA建立期间来完成。SPI的处理将在DOI详细资料中介绍。
当安全联盟被初始建立，一方假设初始者的身份和另一个回答者的身份。一旦SA被建立，同等实体的源初始者和回答者能初始化状态2协商。因而，ISAKMP SA在实际中使双向的。
附加的，ISAKMP允许初始者和回答者在协商过程中控制。当ISAKMP被用来允许包括分建议的SA协商时，初始者能通过仅仅按照初始者本地的安全政策做一个比例维持一些控制。一旦初始者发出一个包含不止一个建议的建议，初始者将放弃对回答者的控制。一旦回答者正在控制SA的建立时，它将能使这个策略优先于初始者提供的多选择的环境里的初始者。选择建议最匹配回答本地安全策略和返回这个选择的初始者来完成它。
2.5  其它
2.5.1  传输协议
ISAKMP能被在任何传输协议或IP自身上执行。执行必须包含ISAKMP在端口500上使用UDP的发送和接收性能。UDP端口500被IANA指派给DSAKMP。执行能附加支持在其它传输协议或IP自身的ISAKMP。
2.5.2  保留域
在ISAKMP有效载荷中保留域的存在被用来保护字节队列。在一个数据报被发出时，所有ISAKMP协议中的保留域必须被设置成0。接收者应该检查0值的保留域，如果没有找到其它值，则丢弃这个数据报。
2.5.3  反障碍标记的创建
cookie产生的详细资料是所依靠的执行，但必须满足这些基本的要求：
1. cookie必须依赖于特殊的组织。这防止一个从cookie使用一个真实IP地址和UDP端口的攻击者，并且用Diffie－Hellman所需的随机的IP地址或端口来覆盖受害者。
2. 它不可能为其它任何发出的实体产生cookie，这将被那个实体接收。这个暗示意味着发出的实体必须用cookie的产生和并发确认中的本地秘密信息。不可能从任何特殊的cookie中推导出这个秘密信息。
3. cookei产生函数必须非常快的阻止对CUP资源的故意攻击。
Karn's关于创建cookie方法的提议是在IP源地址和目的地址上实现快速哈希（例如，MD5），UDP源端口和目的端口以及一个本地产生的秘密随机数。ISAKMP要求cookie对每个SA机构都是唯一的以便帮助防止重播攻击，因此，数据和时间必须被添加到被哈希的信息中。产生的cookie被放在ISAKMP（在3.1章节中描述）头启动和应答机cookie域中。这些域有8个字节长，因此需要产生的cookie也是8字节长。通知和删除信息（参看3.14,3.15和4.8章节）是单向传输并且在现有ISAKMP SA保护下运行，不需要生成新的cookie。有一种例外情况是在完成SA建立之前，第一阶段交换期间通知信息的传输。3.14 和4.8章节提供了辅助细节。
3  ISAKMP载荷
 ISAKMP载荷提供模块化的组建块来构造ISAKMP消息。ISAKMP中载荷的存在和顺序由在ISAKMP头(见图2)中所定位的交换类型字段来定义。ISAKMP载荷类型将在3.4节的3.15中进行讨论。ISAKMP载荷，消息和交换（见4节）的描述用网络八字节顺序来表示。
3.2  ISAKMP头格式 
 一个ISAKMP消息有固定的头格式，见图2，后面紧跟一个变化的载荷号。固定头简化了分析，如果考虑协议所带来的好处，分析软件将变得简单，并且更容易实现。固定头包括协议所需的信息，来维持状态，处理载荷，并可能防止服务否认或重放攻击。ISAKMP头字段定义如下：
* 发起者cookie（8字节）－－实体的cookie对应于一个SA建立请求，或SA通告，或SA删除。
* 应答cookie(八字节)－－实体的cookie用来应答一个SA建立请求，和SA通告，或SA删除。
                         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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            发起者                             !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            应答                             !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   下一个载荷  ! MjVer ! MnVer !    交换类型   !     标志      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            消息  ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                             长度                              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图2：ISAKMP 头格式
* 主版本（4 bit）－表示使用的ISAKMP协议的主版本。实现是基于此ISAKMP的Internet草案时，主版本号必须定为1。实现是基于以前ISAKMP的Internet草案时，主版本号必须定为0。实现永远也不能接受一个主版本号大于它自己的数据包。
* 微版本（4字节）－－表示使用的ISAKMP协议的文版本。实现是基于此ISAKMP的Internet草案时，微版本号必须定为0。实现是基于以前ISAKMP的Internet草案时，微版本号必须定为1。给定同样的主版本号，实现永远不能接受一个微版本号大于它自己的数据包。
* 类型互换（1个八字节）－－表示所用的交换类型。这表示消息和载荷遵循所用的交换顺序。
                        交换类型                值
                         NONE                    0
                         Base                    1
                         Identity Protection     2
                         Authentication Only     3
                         Aggressive              4
                         Informational           5
                         ISAKMP Future Use     6 - 31
                         DOI Specific Use     32 - 239
                         Private Use         240 - 255
* 标志（1个八字节）－－表示特定的选项，用于设定ISAKMP交换。以下在标志字段中指定的标志，从最低有效位开始，如：在标志字段中加密位是0，提交位是1，鉴别位是2。其他剩余位必须在传输前设为0。
――加密位（1位）－－如果设为1，头后面所有的载荷用ISAKMP SA中标识的加密算法来加密。ISAKMP SA标识符是初始和应答cookie的组合。建议加密尽可能在对等体之间进行。对于所有在4.1节中描述的ISAKMP交换，加密必须在双方都交换了密钥交换载荷之后进行。如果加密位不是设为0，不对载荷进行加密。
－－提交位（1位）－此位用于同步的单密钥交换。它用来保证加密的内容不会在sa建立之前被接收到。提交位可由参与建立SA的任何一方（任何时刻）来进行设置，可用在ISAKMP SA建立的两个阶段。然而，在阶段1协商之后，它的值必须复位。如果设为1，未设置提交位的实体必须等待从设置了提交位的实体处的包含一个通知载荷（带有CONNECTED通知消息）的信息交换。在这种情况下，信息交换的消息ID字段必须包含原始ISAKMP 阶段2SA协商的消息ID。完成这，可以保证带有CONNECTED通知消息的信息交换可以和正确的阶段2SA相连。信息交换的接收和处理，表示SA的成功建立，并且任何一个实体现在可以处理加密的通信信息。除了同步密钥交换，提交位可以用来保护在不可信网络上传输的丢失，还可以防止多次重发送的必要。
注意：交换的最后消息很有可能被丢失。在这种情况下，希望接收到交换的最后消息的实体，将接收到在阶段1交换之后的协商消息，或阶段2交换之后的加密通信。这种情况的处理并未标准化，但我们由以下提议：如果等待信息交换的实体可以检验接收到的消息（如：阶段2的SA协商消息，或加密通信），那么，它们可以认为SA已经建立，并且继续处理过程。另一个可选项用来转播最后的ISAKMP消息，以迫使另一个实体转播最后的消息。这意味着实现可以将最后的消息（本地的）一直保持到它们确信SA已经建立。
――唯一鉴别位（1 bit），这一位用在带有通知载荷的信息交换中，并且允许带有完整性检查，但不加密的信息传送中（如：“紧急模式”）。4.8节说明了阶段2信息交换必须在一个ISAKMP SA的保护下的信息交换中中发送。对于那个策略，这是唯一的例外。如果唯一鉴别位设置为1，仅只有鉴别安全服务将被应用到实体中，以通报信息交换载荷，并且不对信息交换载荷进行加密。
* 消息ID（4个八位字节）－－唯一消息标识符用来标识在同步阶段2的协议状态。这个值由同步阶段2的启动程序来随即产生。在同步SA的建立中（也就是说冲突），此字段的值将会有所不同，因为它们是独立产生的，并且，两个安全联盟将促进SA的建立。然而，不可能由绝对同步的建立。在阶段1的同步中，值必须置为0。
* 长度（4个八位字节）以八位字节来计的整个消息（头＋载荷）的长度，加密会扩大ISAKMP 的大小。
3.2  普通载荷头
每一个定义在3.4节到3.16节中的ISAKMP载荷都有一个普通头，见图3，它提供了一个载荷链性能，并清楚的定义了载荷的边界。
                            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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! 下一个载荷     !   保留       !         载荷长度              !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 3:  普通载荷头
* 下一个载荷（一个8位字节）――消息中下一个载荷的载荷类型的标识符。如果当前载荷在消息中的最后，此字段将为0。此字段提供了链性能。
* 保留（一个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通载荷头。
3.3  数据属性
有一些例子，在ISAKMP中有必要表示数据类型。其中一例及时安全联盟（SA）属性，包括在传输载荷中（在3.6节中有描述）。这些数据属性不是一个ISAKMP载荷，而是包含在ISAKMP 载荷中。数据属性的格式提供了表示许多种不同类型信息的灵活性。可能在一个载荷中由多张数据属性。数据属性的长度将是4个八位字节，或由属性长度字段来定义。这些将由下述属性格式位来完成。关于每一个字段的特定属性信息将在DOI 文档中描述，也就是IPSEC DOI [IPDOI]。
                  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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !A!       属性类型              !    AF=0  属性长度             !
     !F!                             !    AF=1  属性值               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                   AF=0  属性值                                .
     .                   AF=1  不发送                                .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        图4：数据属性
数据属性字段定义如下：
* 属性类型（2个八位字节）――每一种属性类型的唯一标识符。这些定义的属性将作为特定DOI信息。
最高有效位，或属性格式（AF），表示在类型/长度/值（TLV）格式后的数据属性是否位短类型/值（TV）格式。如果AF位为0，数据格式将是类型/长度/值（TLV）格式。如果AF位位1，数据类型位类型/值格式。
* 属性长度（2个八位字节）－以八位字节位单位的属性值。当AF位为1时，属性值仅2个八位字节，并且没有属性长度。
* 属性值（变化长度）－和特定DOI属性类型相连的属性值。如果AF位为0，此字段将有一个属性长度字段定义的可变长度。如果AF位为1，属性长度值位2个八位字节的长度。
3.4  安全联盟载荷
安全联盟载荷用来协商安全属性，用来表示解释字段（DOI）和协商发生的环境。图5表示了安全联盟载荷的格式。
                          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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷    !   保留        !         载荷长度              !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        解释字段(DOI)                            !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                             环境                              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 5:  安全联盟载荷
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段位0。当它们作为安全联盟协商的一部分时，此字段绝不能包含建议或转换载荷的值。例如，在基交换的第一条消息中，此字段将包含值“10”（Nonce载荷），在标识保护交换中的第一条消息中，此字段将包含值“0”。（见4.5节）
* 保留（1 个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，整个安全联盟载荷的长度，包括SA载荷，所有提议载荷，和所有与被提议安全联盟相连的传输载荷。
* 解释字段（4个8位字节）――表示DOI（见2.1节的描述），有了它协商才可以进行。DOI是一个32位无符号整数。在阶段1的交换中DOI的值为0，说明了普通ISAKMP SA可在第二阶段中用于任何协议。SA属性的必要性在A.4中有定义。Ipsec DOI【IPDOI】的值指定为1。所有其它的DOI值留给IANA以备后用。在没有参考一些公开规范，如 Internet RFC之前，是不会随便指定一个DOI值的。其它DOI可用附录B中的描述来进行定义。这个字段必须在安全联盟载荷之内。
* 环境（可变长度）――一个特定的DOI字段，用来标识环境，有了它，协商才可以进行。环境用来做出关于所协商的安全属性的策略决定。IETF IP 安全DOI环境的具体细节的说明见【IPDOI】。此字段必须包含在安全联盟载荷之内。
3.5  提议载荷
提议载荷包含用在安全联盟协商中的信息。提议由安全机制，或转换组成，用来加强通信信道的安全。图6表示了提议载荷的格式。关于它的用途将在4.2节中描述。
                    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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷    !   保留        !         载荷长度              !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  提议     #   !  协议－ID     !    SPI 大小   !     # 转换    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SPI (可变)                             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图6 ：提议载荷格式
* 下一个载荷（1个八位字节）――表示消息中下一个载荷的载荷类型。此字段只能包含值2或0。如果消息中还有额外的提议载荷，此字段为2。如果当前提议载荷处于安全联盟提议的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，整个提议载荷，包括普通载荷头，提议载荷，和所有与此提议相关的转换载荷。当同一个提议号对应有多个提议时（见4.2节），载荷长度字段仅用在当前的提议载荷，而不是对所有的提议载荷。
* 提议＃（1个八位字节）――标识当前载荷的提议号。此字段的用途将在4.2节中进行描述。
* 协议－ID（1个八位字节）――指定当前协商中的协议描述符。实例中可能包括IPSEC ESP,IPSEC AH,OSPF,TLS等。
* SPI 大小（1个八位字节）――以八位字节为单位，由协议－ID所定义的SPI 长度。在ISAKMP中，ISAKMP头部的初始和响应cookie对是ISAKMP SPI，因此，SPI大小是不相关的，可能从0到16。如果SPI大小非0，SPI字段的内容必须忽略。如果SPI的大小不是4个八位字节的整数倍，它对SPI字段，和消息中的载荷联盟有一些影响。解释域（DOI）将规定对于其它协议的SPI大小。
* 传输的＃（1个八位字节）――规定提议的转换号。每一个都包含在传输转换载荷中。
* SPI（可变）――发送实体的SPI。当SPI不是4个八位字节的整数倍时，不会对载荷进行填充，然而，它可以用在消息的末尾。
提议载荷的载荷类型是2。
3.6  传输载荷
传输载荷包含用在安全联盟协商中的信息。传输载荷由特定安全机制，或传输组成，用来加强信道的安全。传输载荷同样包括和特定传输相关的安全联盟属性。这些SA属性是DOI特有的。图7表示了传输载荷的格式。在4.2节将对其使用进行描述。
                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷    !    保留       !            载荷长度           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !     传输   #  !    传输－Id   !             保留2             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                          SA 属性                              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图7:  传输载荷格式
传输字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。这个字段是3或0。在提议中有额外的传输载荷，此字段为3。如果当前传输载荷处于提议的最后，此字段为0。
* 保留（1个8位字节）――以八位字节为单位，当前载荷的长度，包括普通载荷头，传输值，和所有SA属性。
* 传输＃（1个八位字节）――标识当前载荷的传输号。如果在一个提议载荷内，对于一个特定的协议有多个传输被提议，那么，每一个传输载荷有一个传输号。4.2节将描述此字段的使用。
* 传输－ID(1个八位字节)――指定当前提议中协议的传输标识符。这些传输有DOI定义，并且独立于所协商的协议。
* 保留2（2个八位字节）――未用，置为0。
* SA属性（可变长度）――此字段包括在传输-ID字段中对于给定传输的安全联盟属性。如果SA属性并不是结盟成4字节的边界，并发载荷将不会结盟，任何填充将将到消息的末尾，形成4字节结盟的消息。
* 传输＃（1个字节）――标识当前载荷的传输号。如果在提议的载荷内，对于一个特定的协议，有多个传输被提议，那么，每一个传输载荷都有唯一传输号。4.2节将描述此的使用。
* 传输-ID（1个八位字节）－指定在当前提议内协议的传输标识符。这些传输有DOI来定义，并且，独立于所协商的协议。
* 保留（2个八位字节）――未用，置为0。
* SA属性（可变长度）――此字段包括在传输－ID字段中给定传输的安全联盟属性。SA属性的表示应该用在3.3节中描述的数据属性格式。如果SA属性不是结盟成4个八位字节边界，并发的载荷将结盟，填充将加在消息的末尾，形成4个八位字节的消息。
传输载荷的载荷类型为3。
3.7  密钥交换载荷
密钥交换载荷支持可变的密钥交换技术。例如：密钥交换有Oaklay【Oakley】，Diffie-Hellman, 在X9.42【ANSI】中描述的加强的Diffie-Hellman密钥交换，以及PGP所用到的基于RSA的密钥交换。图8表示了密钥交换载荷的格式。
密钥交换载荷字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
                      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷    !     保留      !             载荷长度          !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                          密钥交换数据                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图8：密钥交换载荷格式
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通的载荷头。
* 密钥交换数据（可变长度）――用来产生会话密钥的数据。此数据有DOI和联盟密钥交换算法来解释。此字段同样可以包含前置的密钥指示符。密钥交换载荷的载荷类型为4。
3.8  标识载荷
标识载荷包括用于交换标识信息的特定DOI数据。此信息用来决定通信对等实体的同一性，还可以用来决定信息的可靠性。图9表示了标识载荷的格式。
标识载荷字段定义如下：
* 下一个载荷（1个八位字节）－－消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通的载荷头。
* ID 类型（1个八位字节）――指定被用的标识类型。
                     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷  !    保留      !           载荷长度          !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   ID 类型     !               DOI 专用 ID 数据                !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                            标识数据                           ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图9：标识载荷格式
此字段依赖于DOI。
* DOI专用ID数据（3个八位字节）－包含DOI 专用标识数据。如果未用，此字段必须置为0。
* 标识数据（可变长度）－－包含同一性信息。此字段的值是DOI专用的，而且，格式由ID类型字段来指定。IETF IP 安全标识数据的特定细节见【IPDOI】。
标识载荷的载荷类型为5。
3.9  证书载荷
证书载荷提供了一种经由ISAKMP，进行传送证书活其他证书相关的信息的方法，它可以在任何ISAKMP消息中出现。只要适当的目录服务对于分发的证书不可用，证书载荷将包含在一个交换中（如：安全DNS【DNSSEC】）。证书载荷必须被交换中的所有点接受。图10表示了证书载荷的格式。
注意：证书类型和格式一般并不绑定到DOI中－希望只有少量的证书类型，并且，大多数DOI都可以接受所有这些类型。
证书载荷字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
                          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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   下一个载荷  !     保留      !           载荷长度            !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   证书编码    !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                          证书数据                             ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图10 证书载荷格式
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前在恶化的长度，包括普通的载荷头。
* 证书编码（1个八位字节）――此字段表示证书的类型，或包含在证书数据字段中与证书相关的信息。
证书类型                              值
                  NONE                                   0
                  PKCS #7 wrapped X.509 certificate      1
                  PGP Certificate                        2
                  DNS Signed Key                         3
                  X.509 Certificate - Signature          4
                  X.509 Certificate - Key Exchange       5
                  Kerberos Tokens                        6
                  Certificate Revocation List (CRL)      7
                  Authority Revocation List (ARL)        8
                  SPKI Certificate                       9
                  X.509 Certificate - Attribute         10
                  RESERVED                           11 - 255
* 证书数据（可变长度）――证书数据的实际编码。证书类型由证书编码字段来表示。
证书载荷的载荷类型是6。
3.10  证书请求载荷
  证书请求载荷提供了一种经由ISAKMP请求证书的方法，它可以在任何消息中出现。当适当的目录服务（例如：安全DNS【DNSSEC】）对于分发的证书不可用时，证书请求载荷应包含在交换中。交换中的所有点都必须接受证书请求载荷。基于包含在载荷中的值，如果证书被支持，对于证书请求载荷的响应必须发送它们的证书。如果需要多个证书，应该传送多个证书请求载荷。图11表示了证书请求载荷的格式。
                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  下一个载荷   !     保留      !           载荷长度            !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !     证书类型  !                                               !
     +-+-+-+-+-+-+-+-+                                               !
     ~                         人证机构                              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图11：证书请求载荷格式
证书载荷字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通的载荷头。
* 证书类型（1个八位字节）――包含所请求的证书类型的编码。可接受的值在3.9节中列出。
* 认证机构（可变长度）――包含所请求证书类型的可接受证书机构的编码。作为一个例子，对于X.509证书，此字段将包含此载荷的发送者所接受的X.509证书机构的发行者名字的高级名字编码。包含此信息，可以帮助应答作出，需要多少证书链来响应请求的决定。如果没有要求特定的证书机构，将不包含此字段。
3.11  哈希载荷
  哈希载荷包含哈希函数所产生的数据（在SA建立交换期间所选择），基于消息和/或ISAKMP状态的部分信息。此载荷用来验证ISAKMP消息的完整性，或对协商实体进行鉴别。图12表示了哈希载荷的格式。
                 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !   下一个载荷  !     保留      !           载荷长度            !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                           哈希数据                            ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图12 哈希载荷格式
哈希载荷字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通的载荷头。
* 哈希数据（可变长度）――将哈希程序应用到ISAKMP消息和/或状态所得来的数据。
3.12  签名载荷
签名载荷包括由数字签名函数所产生的数据（在SA建立交换期间所选择），基于消息和/或ISAKMP状态的部分信息。此载荷用来认证ISAKMP消息的完整性，还可用作无否认服务。图13表示了签名载荷的格式。
                 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  下一个载荷   !     保留      !           载荷长度            !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                         签名数据                              ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图13 签名载荷格式
签名载荷字段定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（2个八位字节）――以八位字节为单位，当前在恶化的长度，包括普通的载荷头。
* 签名数据（可变长度）――将数字签名函数用到ISAKMP消息和/或状态所得到的数据。
签名载荷的载荷类型为9。
3.13  Nonce载荷
Nonce载荷包含在交换期间用于保证存活，和防止重放攻击的随机数。图14表示了Nonce载荷的格式。如果nonce用于特殊的密钥交换，nonce载荷的使用将由密钥交换来指定。Nonce可作为传输密钥交换数据的一部分，或作为一个独立的载荷。然而，这是由密钥交换来定义，而不是ISAKMP。
                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! 下一个载荷    !     保留      !          载荷长度             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                            Nonce 数据                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图14 ：nonce载荷格式
nonce载荷定义如下：
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型的标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以字节为单位，当前载荷的长度，包括普通载荷头。
O nonce数据（可变长度）――包含由传送实体所产生的随机数。
Nonce载荷的载荷类型为10。
3.14  通告载荷
通告载荷可以既包含ISAKMP，又包含DOI特定数据，用来传送信息数据，例如：ISAKMP同位体的错误条件。可以在单一的ISAKMP消息中发送多个通告载荷。图15表示了通告载荷的格式。
出现在，或关心阶段协商的通告，由在ISAKMP消息中发起者和应答cookie对来进行标识。协议标识符，在这种情况下，ISAKMP和SPI的值为0，因为是由ISAKMP头中的cookie对来标识ISAKMP SA。如果通告先于密钥信息的完整交换，那么，通告将不会受到保护。
出现在，或关心阶段2协商的通告，由在ISAKMP 头中的发起者和应答cookie对，和消息ID，和于当前协商相关的SPI来进行标识。其中这种通告类型的实例就是用来指定为什么一个提议被拒绝。
                        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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  下一个载荷   !     保留      !            载荷长度           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                       解释域  (DOI)                           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !    协议-ID    !   SPI 大小    !      通告消息类型             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                          安全参数索引 (SPI)                   ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                          通告数据                             ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图15：通告载荷格式
* 下一个载荷（1个八位字节）――消息中下一个载荷的载荷类型标识符。如果当前载荷处于消息的最后，此字段为0。
* 保留（1个八位字节）――未用，置为0。
* 载荷长度（2个八位字节）――以八位字节为单位，当前载荷的长度，包括普通载荷头。
* 解释域（4个八位字节）――标识DOI后（如2.1节中所描述的），通告可以发生。对于ISAKMP ，此字段为0，对于IPSEC DOI，它为1。其它DOI的值用附录B中的说明来定义。
* 协议－ID(1个八位字节)――这顶当前通告的协议标识符。实例可能包括ISAKMP,IPSEC ESP,IPSEC AH,OSPF,TLS等。
* SPI 大小（1个八位字节）――以八位字节为单位，由协议-ID所定义的SPI长度。在ISKMP中，ISAKMP头中的发起者和应答cookie对是ISAKMP SPI，因此，SPI大小并不重要，可以从0到16。如果SPI的大小非0，SPI字段的内容必须被忽略。解释域将指定对于其他协议的SPI大小。
* 通告消息类型（2个八位字节）――指定通告消息的类型（见3.1.14节）。如果由DOI指定，附加文本将放在通告数据字段内。
* SPI（可变长度）――安全参数索引。接收实体的SPI。SPI字段的使用将在2.4节中说明。此字段的长度将由SPI大小字段来决定，不一定要结盟成4个八位字节边界。
* 通告数据（可变长度）――除通告消息类型之外的信息和错误数据。此字段的值是DOI特定的。
通告载荷的载荷类型为11。
3.14.1  通告信息类型
通告信息可能是指定为什么一个SA不能被建立的错误信息。它也可以是一个状态数据，关于一个管理SA数据库的过程想和对等的过程通信的状态数据。例如：一个安全前端或者安全网关可以使用通告信息来同步SA通信。下表列出了通告信息和它们相应的值。专用范围内的值期望是DOI特定的值。
                      通告信息－错误类型
                       错误                      值
                 INVALID-PAYLOAD-TYPE             1
                 DOI-NOT-SUPPORTED                2
                 SITUATION-NOT-SUPPORTED          3
                 INVALID-COOKIE                   4
                 INVALID-MAJOR-VERSION            5
                 INVALID-MINOR-VERSION            6
                 INVALID-EXCHANGE-TYPE            7
                 INVALID-FLAGS                    8
                 INVALID-MESSAGE-ID               9
                 INVALID-PROTOCOL-ID             10
                 INVALID-SPI                     11
                 INVALID-TRANSFORM-ID            12
                 ATTRIBUTES-NOT-SUPPORTED        13
                 NO-PROPOSAL-CHOSEN              14
                 BAD-PROPOSAL-SYNTAX             15
                 PAYLOAD-MALFORMED               16
                 INVALID-KEY-INFORMATION         17
                 INVALID-ID-INFORMATION          18
                 INVALID-CERT-ENCODING           19
                 INVALID-CERTIFICATE             20
                 CERT-TYPE-UNSUPPORTED           21
                 INVALID-CERT-AUTHORITY          22
                 INVALID-HASH-INFORMATION        23
                 AUTHENTICATION-FAILED           24
                 INVALID-SIGNATURE               25
                 ADDRESS-NOTIFICATION            26
                 NOTIFY-SA-LIFETIME              27
                 CERTIFICATE-UNAVAILABLE         28
                 UNSUPPORTED-EXCHANGE-TYPE       29
                 UNEQUAL-PAYLOAD-LENGTHS         30
                 RESERVED (Future Use)        31 - 8191
                 Private Use                8192 - 16383
                       通告信息      －   状态类型
                     状态             值
                  CONNECTED                   16384
                  RESERVED(Future Use)   16385 - 24575
                  DOI-specific codes     24576 - 32767
                  Private Use            32768 - 40959
                  RESERVED (Future Use)  40960 - 65535
3.15  删除载荷
删除载荷包括一个协议特有的安全联盟标识符，发送方已经将该标识符从其安全联盟数据库中删除，因此它不再有效。图16说明了删除载荷的格式。在一个删除载荷中发送多个SPI是可能的，但是，每一个SPI必须有相同的协议。在删除载荷中不能执行混合协议标识符。
与ISAKMP SA相关的删除将包含一个ISAKMP的Protocol－Id，SPIs是ISAKMP头的发起者cookie和应答cookie。与SA协议，如：ESP或者AH，相关的删除包含该协议（例如：ESP，AH）的Protocol－Id，SPI是发送实体的SPI（s）。
注意：删除载荷不是对应答删除SA的请求，而是发起者向应答的一个建议。如果应答选择忽略这个信息，那么使用下一个从应答到发起者的使用安全联盟的通信，将会失败。应答不期望承认收到删除载荷。

                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  下一个载荷   !     保留      !            载荷长度           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                          解释域  (DOI)                        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !    协议-Id    !   SPI 大小    !           # of SPIs           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                    安全参数索引(es) (SPI)                    ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         图16：删除载荷格式
删除载荷字段的定义如下：
* 下一个载荷（1个八位字节）－消息中的下一个载荷的载荷类型标识符。如果当前的载荷是消息中的最后一个载荷，该字段为0。
* 保留 (1个八位字节)－未用，置为0。
* 载荷长度 （2个八位字节）－以位组为单位表示长度的当前载荷，包括通有的载荷头。
* 解释域 （4个八位字节）－DOI的标识符（见2.1节描述），删除发生在DOI中。对于ISAKMP，它的值是0；对于IPSEC DOI，它的值是1。其它的DOI的标识符可用附录B中的描述来定义。
* 协议－Id（1个八位字节）－ISAKMP可以为各种协议建立安全联盟，包括ISAKMP和IPSEC。这个字段标识了那一安全联盟数据库适用于删除请求。
* SPI大小（1个八位字节）－由Protocol－Id定义的以位组表示的SPI长度。在ISAKMP情形下，发起者cookie和应答cookie对是ISAKMP SPI。在这种情况下，对于每一个被删除的SPI，SPI的大小应该为16个八位位组。
* ＃of SPIs（2个八位字节）－包含在删除载荷中的SPIs数。每一个SPI的大小由SPI Size字段定义。
* 安全参数索引（es）（长度可变）－识别将要删除的特定的安全联盟。这个字段的值是DOI和协议特有的。这个字段的长度由SPI Size和＃of SPIs 字段决定。
删除载荷的载荷类型是12。
3.16  厂商ID载荷
厂商ID载荷包含一个厂商定义的常量。厂商用这个常量来识别和确认它们实现的远程情况。这个机制允许厂商在维持向后兼容性的同时，试验新的特性。这对于ISAKMP不是一个通用的扩展工具。图17说明了厂商ID载荷的格式。
厂商ID载荷不是来自发起者的声明，它将发送专用的载荷类型。发送厂商ID的厂商一定不能作出任何它将发送的专用载荷的假设，除非也接收到一个厂商ID。可以发送多厂商ID载荷。实现不需要发送任何的厂商ID载荷。如果发送了一个没有得到事先同意的专用载荷，顺从的实现将拒绝一个建议，该建议带有一个INVALID-PAYLOAD-TYPE类型的通告消息。
如果发送一个ID载荷，它必须在商协阶段1发送。在阶段1中接收一个熟悉的厂商ID载荷，将允许实现使用专用USE载荷号（128－255），在3.1节中描述了在阶段2协商过程中厂商特有的扩展。“熟悉”的定义留给实现来决定。一些厂商可能希望在标准化之前实现其他厂商的扩展。但是，这项实践不应该广泛分布，厂商应该先在标准化工作上努力。
厂商定义的常量应该是唯一的。哈希函数和要被哈希的原文由厂商选择。例如：厂商可以用包含产品名、产品版本的串的明文哈希来产生他们的厂商ID。使用哈希而不使用厂商注册，可以避免带有“被认可的”产品的列表的密码策略问题，和避免维持厂商列表，以及允许分类的产品避免出现在任何列表上。例如：
"Example Company IPsec.  Version 97.1"（不包括引号）用MD5哈希：如果使用MD5文件，48544f9b1fe662af98b9b39e50c01a5a。因为载荷长度将限制数据，因此厂商可以包括所有的哈希，或者哈希的一部分。没有哈希的安全暗含，所以它的选择是任意的。
                   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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  下一个载荷   !      保留     !            载荷长度           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                         厂商 ID (VID)                         ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          图17：厂商ID载荷格式
厂商ID载荷字段定义如下：
* 下一个载荷（1个八位字节）－消息中的下一个载荷的载荷类型标识符。如果当前的载荷是消息中的最后一个载荷，该字段为0。
* 保留 (1个八位字节)－未用，置为0。
* 载荷长度 （2个八位字节）－以位组为单位表示长度的当前载荷，包括通有的载荷头。
* 厂商ID (可变长度)－厂商的串加上版本（上面有描述）的哈希。
厂商ID载荷的载荷类型是13。
如果一个错误出现在这些信息中，局部安全策略就会指令执行该操作。一个可能的操作是传送作为一个信息交换的部分的一个有效载荷的通告。
4.6  证明唯一交换
证明唯一交换本意是允许对相关传输信息进行唯一的证明。这种交换的好处是能够在不估算密钥代价的情况下完成唯一证明。在流通中使用这种交换，传输中的信息不会被加密。但是信息可以在其它地方被加密。例如，如果加密在第一个流通阶段被通过并且证明唯一交换使用在第二个流通阶段，那么证明唯一交换将在第一个流通阶段被ISAKMP Sas加密。下面的图表说明了在每个信息中可能传送的有效载荷和证明唯一交换的实例。
证明唯一交换
启动器
方向
响应器
注释
（1）HDR；SA；NONCE
=>

开始于ISAKMP-SA或流通代理
（2）
<=
HDR; SA; NONCE;                                 IDir; AUTH
基于SA允许的由启动器检验的响应器恒等式
（3）HDR; IDii; AUTH
=>

由已确定的响应SA校验的启动器恒等式

在第一个信息中，启动器产生一个提议，对给定情形下的传输提供足够的保护。安全联盟建议并转换包括安全联盟有效载荷在内的有效载荷。被用作保证有效和防止重放攻击的随机信息也被转换。随机信息如果被两方提供，则应该有鉴定机构在交换中提供合作的共享证据。
在第二个信息中，响应器显示了它允许安全联盟提议和转换有效载荷的一套保护。
此外被用作保证有效和防止重放攻击的随机信息也被转换。随机信息如果被两方提供，则应该有鉴定机构在交换中提供合作的共享证据。另外，响应器传输标识信息。所有这些信息都是在已经许可鉴定函数的保护下进行传输的。如果一套没有被提议的保护被承认，局部安全策略规定响应器操作。一个可能的操作是传送作为一个信息交换的部分的一个有效载荷的通告。
在第三个信息中，启动器传送鉴证信息。该信息在被许可的证明函数的保护下传输。如果在这些信息中出现一条错误信息，局部安全策略规定相关操作。一个可能的操作是传送作为一个信息交换的部分的一个有效载荷的通告。
4.7  主动交换
主动交换允许安全联盟，密钥交换和证明相关有效载荷的同时传输。结合安全联盟，密钥交换和相关证明信息在一个信息中的作法，减少了来回路径在不提供同一性保护时的消耗。同一性保护不被提供是因为同一性在一个普通共享密钥生成之前同一性被改变，因此同一性加密是不能成立。此外，主动交换企图在一个单一交换中建立所有安全相关信息。下面的图表说明了在每个信息中可能传送的有效载荷和证明唯一交换的实例。
主动交换
启动器
方向
响应器
注释
（1）HDR；SA；NONCE
=>

开始于ISAKMP-SA或流通代理以及密钥交换
（2）
<=
HDR; SA; NONCE;                                 IDir; AUTH
基于SA允许的由启动器检验的响应器恒等式
（3）HDR; IDii; AUTH
=>

由已确定的响应SA校验的启动器恒等式

在第一个信息中，启动器产生一个提议，对给定情形下的传输提供足够的保护。安全联盟建议并转换包括安全联盟有效载荷在内的有效载荷。这些仅仅是提供一个建议和一个转换（例如，无选择情况）来使主动交换运作。密钥材料通常为一些共享公共秘密和随机信息，而且被用作保证有效和防止重放攻击的随机信息也被转换。随机信息如果被两方提供，则应该有鉴定机构在交换中提供合作的共享证据。此外，启动器传输验证信息。
在第二个信息中，响应器显示了它允许安全联盟提议和转换有效载荷的一套保护。密钥材料通常为一些共享公共秘密和随机信息，而且被用作保证有效和防止重放攻击的随机信息也被转换。随机信息如果被两方提供，则应该有鉴定机构在交换中提供合作的共享证据。此外，响应器传输验证信息。所有这些信息都是在已经许可鉴定函数的保护下进行传输的。如果一套没有被提议的保护被承认，局部安全策略规定响应器操作。一个可能的操作是传送作为一个信息交换的部分的一个有效载荷的通告。在第三个信息中，启动器传输已经许可的证明函数结果。这个信息在共享秘密的保护下进行传输。如果在这些信息中有错误信息出现，局部安全策略会规定相关操作。一个可能的操作是传送作为一个信息交换的部分的一个有效载荷的通告。
4.8  信息交换
信息传输定义为单行道的信息传输，它被用做对安全联盟的管理。下面的图表说明了在每个信息中可能传送的有效载荷和证明唯一交换的实例。
信息传输
启动器
方向
响应器
注释
（1）HDR*；N/D
=>

错误报告或删除
在第一个信息中，启动器或响应器传送一个ISAKMP通报或删除有效载荷。
如果信息交换出现在当前ISAKMP第一阶段流通的密钥材料交换中时，将不对信息交换提供保护。一旦密钥材料发生交换或ISAKMP SA被建立，那么信息交换必须在由密钥材料或ISAKMP SA提供的保护下传输。
所有交换都类似于开始时的那些交换，并且必须存在同步加密。信息交换是一个交换，而不是ISAKMP信息。因为信息交换而生成的一个信息ID应该独立于另外进程通讯中的IVs 。这样将确保同步加密可以维持现有的通信以及信息交换能够适当的处理。唯一例外情况是在ISAKMP头的提交位被设置了。当提交位被设置时，信息交换的信息ID字段必须包括原始ISAKMP阶段2 SA流通的信息ID，而不是一个新信息ID（MID）。这样就确保有着连接通报信息的信息交换可以和正确的阶段2 SA相关联。有关提交位的描述，参看3.1节。
5  ISAKMP有效载荷处理
第三部分描述的ISAKMP有效载荷。这些有效载荷被用于交换的描述参看第四节，并且可以作为一个特殊DOI的交换定义。这一节描述了对于每一个有效载荷的处理。这节建议事件记载到一个系统审计文件上。这个操作由系统安全策略控制和实行，因此，仅仅是一个建议性操作。
5.1  普通信息处理
每一个ISAKMP信息有一个基本处理应用，以便确保协议的可靠性，将威胁最小化，例如服务的拒绝和重放攻击。所有的处理应该包括包裹的长度检查，用来确保接收的包裹长度至少为在ISAKMP头中的给予长度。如果ISAKMP信息长度与ISAKMP头的有效载荷长度字段中的值不同，那么ISAKMP信息必须被拒绝。接收的实体（启动器或响应器）必须进行如下操作：
1． 不同有效载荷长度事件可以记录在适当的系统审计文件上。
2． 包含不等有效载荷长度消息类型的有效载荷通告的信息交换可以被送到一个发送实体上去。该操作由系统安全策略规定。
在传送一个ISAKMP信息时，发送实体（启动器或响应器）必须进行如下操作：
1． 设置一个记时器，并初始化一个重复计数器。
注意：执行时不使用固定的记时器。相反的传输时间值应该基于标准的来回旅程时间进行动态调整。此外，相同包裹的连续重发应该有更长的时间间隔来隔离。（例如，指数补偿）。
2． 如果记时器终止，ISAKMP信息被重发并且重复计数器被消耗掉。
3． 如果重复计数器达到零，事件的重复限制范围可以记录在适当的系统审计文件中。
4． ISAKMP协议机制清空所有状态，并返回为空闲状态。
5.2  ISAKMP头操作
当生成一个ISAKMP信息时，发送实体（启动器或响应器）必须进行如下操作：
1． 生成相应的cookie。详细描述参看地2.5.3.
2． 确定相应的安全通信特性（例如，DOI和状态）
3． 如同3.1节描述的那样，生成一个带字段的ISAKMP头。
4． 依靠交换类型，生成其他ISAKMP有效载荷。
5． 像在5.1节描述的那样，发送信息到目的主机。
当接收到一个ISAKMP信息时，接收实体（启动器或响应器）必须进行如下操作：
1． 校验启动器和响应器的“cookies”。如果cookies校验失败，则信息将被丢弃，并进行如下操作：
(a) 无效cookie事件可以记录在适当的系统审计文件中。
(b) 包含无效cookie消息类型的通告有效载荷的信息交换可以被送到发送实体。该操作由系统安全策略规定。
2． 检测下一个有效载荷字段确定它是否有效。如果下一个有效载荷字段验证失败，信息将被丢弃，并进行如下操作：
(a) 无效的下一个有效载荷事件可以记录在适当的系统审计文件中。
(b) 包含非法有效载荷类型的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
3． 3．检查主要和次要的版本字段，确定它们是否正确（参看3.1节）。如果版本字段检查失败，信息将被丢弃，并进行如下操作：
(a) 无效的ISAKMP版本事件可以记录在适当的系统审计文件中。
(b) 包含无效主要版本或无效次要版本的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
4． 检查交换类型字段，确定是否有效。如果检查失败，信息将被丢弃，并进行如下操作：
(a) 无效交换类型事件可以记录在适当的系统审计文件中。
(b) 包含无效交换类型的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
5． 检查标志字段，确定它包含正确的数值。如果检查失败，信息将被丢弃，并进行如下操作：
(a) 无效标志事件可以记录在适当的系统审计文件中。
(b) 包含无效标志消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
6． 检查信息ID字段，确定是够包含正确的数值。如果检查失败，信息将被丢弃，并进行如下操作：
(a) 无效信息ID事件可以记录在适当的系统审计文件中。
(b) 包含无效信息ID的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
7． ISAKMP信息处理延续使用了在下一个有效载荷字段中的数值。
5.3  特殊有效载荷头处理
当通过3.15节生成一个在3.4节中描绘的任何一个ISAKMP有效载荷时，一个特殊有效载荷头被放置在这些有效载荷的开始端。当生成特殊有效载荷头时，发送实体（启动器或响应器）必须进行如下操作：
1． 将下一个有效载荷的值放置在下一个有效载荷字段中。这些值的描述在3.1节中。
2． 放置0值到保留字段中。
3． 将有效载荷长度（8位位组）放置到有效载荷长度字段中。
4． 如同在本节其他部分定义的那样，生成有效载荷。
当接收到任何ISAKMP有效载荷时，接收实体（启动器或响应器）必须进行如下操作：
1． 检查下一个有效载荷，确定它是否有效。如果失败，信息将被丢弃，并进行如下操作：
(a) 无效下一个有效载荷事件可以记录在适当的系统审计文件中。
(b) 包含非法有效载荷类型的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
2． 检查保留字段是否包含0值。如果没有，信息将被丢弃，并进行如下操作：
(a) 无效保留字段事件可以记录在适当的系统审计文件中。
(b) 包含BAD建议句法或畸形有效载荷的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
3． 如同下一有效载荷字段定义的那样，对剩余有效载荷进行处理。
5.4  安全联盟有效载荷处理
当生成一个安全联盟有效载荷时，发送实体（启动器或响应器）必须进行如下操作：
1． 确定这个流通正在施行的译码范围。
2． 确定这个流通正在实行的确定DOI的内部情形。
3． 确定在该情形内的提议和传输。详细描述分别参看3.5和3.6节。
4． 生成安全联盟有效载荷。
5． 如同5.1节中描述的那样，发送一个信息到接收实体（启动器或响应器）
当接收到一个安全联盟有效载荷时，接收实体（启动器或响应器）必须进行如下操作：
1． 确定是否支持其译码范围。如果不支持，信息将被丢弃，并进行如下操作：
(a) 无效DOI事件可以记录在适当的系统审计文件中。
(b) 包含不支持DOI消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
2． 确定是否给予的状态受到保护。如果没有，信息将被丢弃，并进行如下操作：
(a) 无效状态事件可以记录在适当的系统审计文件中。
(b) 包含不支持状态消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
3． 处理安全联盟有效载荷的剩余有效载荷（例如，提议，转换）。如果安全联盟有效载荷（同5.5和5.6 描述的那样）不被认同，那么进行如下操作.
(a) 无效提议事件可以记录在适当的系统审计文件中。
(b) 包含无选择建议的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
5.5  提议有效载荷处理
当生成一个提议有效载荷时，发送实体（启动器或响应器）必须进行以下操作：
1． 决定这些建议的草案。
2． 决定提供给这个协议草案的建议数目和每个建议的转换数目。关于转换的描述在3.6节。
3． 生成一个特殊的伪随机SPI。
4． 生成一个提议有效载荷。
当接收到一个提议有效载荷时，接收实体（启动器或响应器）必须进行如下操作：
1． 确定是否被草案支持。如果草案的ID字段是无效的，则有效载荷被丢弃，并执行下面的操作：
(a) 无效草案事件可以记录在适当的系统审计文件中。
(b) 包含无效草案ID消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
2． 确定SPI是否有效。如果无效，则有效载荷被丢弃，并执行下面的操作：
(a) 无效SPI事件可以记录在适当的系统审计文件中。
(b) 包含无效SPI消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
3． 确保草案按照3.5和4.2节给予的详细资料那样存在。如果草案没有正确的印版，则执行以下操作：
(a) BAD提议语法，无效提议等事件可以记录在适当的系统审计文件中。
(b) 包含BAD提议语法或畸形有效载荷的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
4． 如同下一有效载荷字段定义的那样，对提议和转换有效载荷进行处理。
5.6  转换有效载荷处理
当生成一个转换有效载荷时，发送实体（启动器或响应器）必须进行如下操作。
1． 确定因为这种转换的转换。
2． 确定为该提议提供的转换数目。关于转换的描述参看3.6 节。
3． 生成一个转换有效载荷。
当接收到一个转换有效载荷时，接收实体（启动器或想应器）必须执行下面操作：
1． 确定是否支持转换。如果转换ID字段包括一个未知或不支持的值，那么转换有效载荷必须被忽视，并且不可以引起一个无效转换事件的产生。如果转换ID字段是无效的，那么有效载荷将被丢弃，并执行以下操作：
(a) 无效转换事件可以记录在适当的系统审计文件中。
(b) 包含无效转换ID的消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
2．确保草案按照3.5和4.2节给予的详细资料那样存在。如果草案没有正确的印版，则执行以下操作：
(a) BAD提议语法，无效转换，无效特性等事件可以记录在适当的系统审计文件中。
(b) 包含BAD提议语法、畸形有效载荷或不支持特性等消息类型的通告有效载荷信息交换可以被送到发送实体。该操作由系统安全策略规定。
2． 如同下一有效载荷字段定义的那样对并发转换和提议有效载荷进行操作。处理这些有效载荷的实例在4.2.1节中给出。
5.7  密钥的交换有效负载的处理
当建立一个密钥的交换有效负载时，传送的实体(启动程序或应答器)必须采取如下措施：
1. 由 DOI 定义的，确定密钥交换使用。
2. 由 DOI 定义的，确定密钥交换数据域的用法。
3. 构造密钥交换的有效负载。
4. 在 5.1 节描述，传送消息到接收的实体。
当密钥的交换有效负载被接收时，接收的实体(启动程序或应答器)必须采取如下措施：
1. 决定密钥的交换是否被支持。如果密钥的交换确定失败，消息丢失，那么采取如下措施：
(a) 无效的密钥信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的密钥信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.8  鉴定有效负载的处理
当建立鉴定有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 由 DOI 定义的，决定鉴定信息用于 ( 和可能的状况 ) 。
2. 由 DOI 定义的，决定鉴定数据域的用法。
3. 构造鉴定有效负载。
4. 在 5.1 节描述了，传送消息到接收的实体。
当鉴定有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 决定鉴定类型是否被支持。这可以基于 DOI 和状况。如果鉴定确定失败，消息被丢失，那么采取如下措施：
(a) 无效的ID信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的ID信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.9  处理的证书有效负载
当建立证书有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 决定编码用于的证书。这可以被 DOI 指定。
2. 保证由编码的证书定义的，一张证书的存在被格式化。
3. 构造证书有效负载。
4. 在5.1节描述了，传送消息到接收的实体。
当证书有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 决定编码的证书是否被支持。如果编码的证书没被支持，有效负载被丢失，那么采取如下措施：
a) 无效的证书信息编码的事件，可能被存入适当的系统审计文件。
b) 包含无效的证书信息编码的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
2. 处理证书数据域。如果证书数据是无效的或不适当地格式化了，有效负载被丢失，那么采取如下措施：
a) 无效的证书信息的事件，可能被存入适当的系统审计文件。
b) 包含无效的证书信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.10  处理的证书请求有效负载
当建立证书请求有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 决定编码被请求的证书的类型。这可以被DOI指定。
2. 决定将被请求的一个可接受的证书权威的名字(如果适用) 。
3. 构造证书请求有效负载。
4. 在5.1节描述了，传送消息到接收的实体。
证书请求有效负载什么时候被接收，接收的实体(启动程序或应答器)采取如下措施：
1. 决定编码的证书是否被支持。如果编码的证书是无效的，有效负载被丢失，采取如下措施：
a) 无效的证书信息的事件，可能被存入适当的系统审计文件。
b) 包含无效的证书信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
如果编码的证书没被支持，有效负载被丢失，采取如下措施：
a) 未支持证书类型的事件，可能被存入适当的系统审计文件。
b) 包含未支持证书类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
2. 决定证书权威是否为编码的指定的证书被支持。如果证书权威是无效的或不适当地格式化了，有效负载被丢失，采取如下措施：
a) 无效的证书权威的事件，可能被存入适当的系统审计文件。
b) 包含无效的证书权威的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
3. 处理证书请求。如果有指定的证书权威的一种请求的证书类型不是可得到的，然后有效负载被丢失，采取如下措施：
(a) 无法使用的证书的事件，可能被存入适当的系统审计文件。
(b) 包含无法使用的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.11  哈希值有效负载的处理
当建立哈希值有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 由 SA 协商定义的，决定哈希函数用于。
2. 由 DOI 定义的，决定哈希值数据域的用法。
3. 构造哈希值有效负载。
4. 在5.1节描述了，传送消息到接收的实体。
当哈希值有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 决定哈希值是否被支持。如果哈希值确定失败，消息被丢失，那么采取如下措施：
(a) 无效的哈希值信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的哈希值信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
2. 当在 DOI 或密钥的交换协议文件被构画出，施行哈希函数。
如果哈希函数失败，消息被丢失，采取如下措施：
(a) 无效的哈希值信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的证书信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.12  签名有效负载的处理
当建立签名有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 由 SA 协商定义的，决定签名功能用于。
2. 定义的由，决定签名数据域的用法 DOI 。
3. 构造签名有效负载。
4. 在5.1节描述了，传送消息到接收的实体。
当签名有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 决定签名是否被支持。如果签名确定失败，消息被丢失，采取如下措施：
(a) 无效的签名信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的签名信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
2. 当在 DOI 或密钥的交换协议文件构画出了，施行签名功能。如果签名功能失败，消息被丢失，采取如下措施：
(a) 无效的签名值信息的事件，可能被存入适当的系统审计文件。
(b) 包含无效的证书信息的类型的消息，携带通知有效负载的信息交换，可能被发送到传送的实体。这个效应被系统安全策略口授。
5.13  目前有效负载的处理
当建立目前有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 建立唯一的随意的值作为目前用于。
2. 构造目前有效负载。
3. 在5.1节描述了，传送消息到接收的实体。
当目前有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 对于处理目前有效负载没有特定的过程。过程被交换类型定义(和可能的 DOI 和密钥交换描述) 。
5.14  通知有效负载的处理
在通讯期间错误可以发生，是可能的。参考的交换与通知有效负载提供通知一个同伴实体错误在处理的协议期间发生了的一个控制的方法。通知有效负载，这被推荐被放入分开的参考的交换而非添加通知有效负载到存在的交换。当建立通知有效负载时，传送的实体(启动程序或应答器)采取如下措施：
1. 这份通知决定 DOI 。
2. 这份通知决定 Protocol-ID 。
3. 基于 Protocol-ID 域决定 SPI 大小。因为不同的安全协议有不同的 SPI 大小，该域是必要的。例如， ISAKMP 联合启动程序和应答器小甜饼对 ( 十六位八进制 ) 作为SPI ，当时ESP和AH有四位八进制SPI 。
4. 决定基于错误或需要的地位消息通知消息类型。
5. 决定与这份通知被联系的 SPI 。
6. 决定附加的通知数据是否将被包括。这是 DOI 指定了的附加的信息。
7. 构造通知有效负载。
8. 在5.1节描述了，传送消息到接收的实体。
因为有通知有效负载的参考的交换是一条单向性的消息，重发将不被施行。本地的安全策略将为继续口授过程。
然而， 我们推荐那一个通知有效负载错误事件被登录由接收的实体的适当的系统审计文件。如果参考的交换在 ISAKMP 期间在 keying 材料的交换以前发生，阶段 1 协商将不是为参考的交换被提供了的保护在那里。 keying 材料被交换或 ISAKMP  SA 被建立， 参考的交换必须在 keying 提供了的保护下，传送材料或 ISAKMP  SA 。
当通知有效负载被接收时，接收的实体(启动程序或应答器)采取如下措施：
1. 决定参考的交换是否把任何保护由检查位和认证仅仅在 ISAKMP头中的位的加密适用于它。如果加密位被设置，即参考的交换被加密， 然后消息必须被解密使用 ( 进行中或完成 ) ISAKMP  SA 。当描述了在下面，一旦解密是完全的，处理能继续。如果认证仅仅位了被设置， 然后消息必须被证实使用 ( 进行中或完成 ) ISAKMP  SA 。一旦认证被完成，当在下面描述了，处理能继续。如果参考的交换没被加密或认证，当在下面描述了，处理的有效负载能继续。
2. 决定是否解释的域 ( DOI ) 被支持。如果 DOI 确定失败，有效负载被丢失，采取如下措施：
(a) 无效的DOI信息的事件，可能被存入适当的系统审计文件。
3. 决定 Protocol-Id 是否被支持。如果 Protocol-Id 确定失败，有效负载被丢，采取如下措施：
(a) 无效的PROTOCOL-ID信息的事件，可能被存入适当的系统审计文件。
4. 决定 SPI 是否是有效的。如果 SPI 是无效的，有效负载被丢失，采取如下措施：
(a) 无效的SPI信息的事件，可能被存入适当的系统审计文件。
5. 决定是否通知消息类型是有效的。如果通知消息类型是无效的， 有效负载被丢失，采取如下措施：
(a) 无效的消息类型的事件，可能被存入适当的系统审计文件。
6. 根据本地的安全策略，处理通知有效负载， 包括附加的通知数据和采取适当的行动。
5.15  删除有效负载的处理
在通讯期间主机可以被妥协或信息可以在传动期间被拦截，是可能的。决定这是否发生了不是一项容易的任务并且在这个备忘录的范围外面。然而， 如果传播正在被妥协，这被发现，然后建立新 SA 并且删除当前的 SA ，是必要的。
参考的交换与删除有效负载提供通知一个同伴实体传送的实体删除了 SA 的一个控制的方法。安全协会的删除必须总是在 ISAKMP  SA 的保护下面被施行。接收的实体应该清理它的本地的 SA 数据库。然而，接收删除 SA 在安全参数索引列出了的消息 ( SPI ) 域删除有效负载不能与传送的实体用于。 SA 建立过程必须被调用重建安全的通讯。
当建立时删除有效负载，传送的实体(启动程序或应答器) 采取如下措施：
1. 这删除决定 DOI 。
2. 这删除决定 Protocol-ID 。
3. 基于 Protocol-ID 域决定 SPI 大小。因为不同的安全协议有不同的 SPI 大小，这域是必要的。例如， ISAKMP 联合启动程序和应答器小甜饼对 ( 十六位八进制 )作为 SPI ，当时 ESP 和AH有四位八进制 SPI 。
4. 对于这个协议，# 决定被删除的 SPI 。
5. 决定是的 SPI () 与这删除联系了。
6. 构造删除有效负载。
7. 在5.1节描述，传送消息到接收的实体。
因为参考的交换与删除有效负载是重发将不被施行的一条单向性的消息。本地的安全策略将为继续口授过程。然而， 我们推荐那一删除事件被登录的有效负载错误由接收的实体的适当的系统审计文件。
如上所述， 参考的交换与删除有效负载必须在 ISAKMP  SA 提供了的保护下面被传送。
什么时候删除有效负载被接收，接收的实体(启动程序或应答器)采取如下措施：
1. 因为参考的交换被一些安全服务保护 ( 例如对于 Auth ，仅仅认证 SA ， 对于另外的交换的加密 )， 消息必须有服务使用了ISAKMP  SA 的这些安全。当在下面描述了，一旦处理的安全服务是完全的，处理能继续。当登记信息时，在处理的安全服务期间发生的任何错误将是明显的删除有效负载。由于处理错误的安全服务，本地的安全策略应该口授取消任何行动。
2. 决定是否解释的域 ( DOI ) 被支持。如果 DOI 确定失败，有效负载被丢失，采取如下措施：
(a) 无效的DOI的事件，可能被存入适当的系统审计文件。
3. 决定 Protocol-Id 是否被支持。如果 Protocol-Id 确定失败，有效负载被丢失，采取如下措施：
(a) 无效的PROTOCOL-ID的事件，可能被存入适当的系统审计文件。
4. 决定 SPI 是否为被包括了在的每 SPI 是有效的删除有效负载。对于无效 SPI ，采取如下措施：
(a) 无效的SPI信息的事件，可能被存入适当的系统审计文件。
5. 进程删除有效负载并且采取适当的行动， 根据本地的安全策略。如上所述， 一个适当的行动应该包括清理本地的 SA 数据库。
6  结论
因特网安全协会和密钥的管理协议 ( ISAKMP ) 一个好设计的协议在未来的因特网被瞄准。因特网的巨大的生长将在网络利用，通讯，安全要求，并且安全机制导致大差异。 ISAKMP 包含将为这被需要的所有的特征动态并且膨胀的通讯环境。
Isakmp 的安全协会 ( SA ) 特征结合了认证和建立提供安全和将为未来生长和差异被需要的灵活性的密钥。多重的密钥的交换技术，加密算法，认证机制，安全服务，并且安全属性的这安全差异将允许用户为他们的网络选择适当的安全， 通讯，并且安全需要。 SA 特征允许用户指定并且谈判有另外的用户的安全要求。在一个单个的协议支持多重的技术的附加的好处是当新技术被开发，他们能容易被加到协议。这为因特网安全服务的生长提供一条路径。 ISAKMP 支持公开或私下地定义的 SA ，对于管理，广告，和私人的通讯，使它理想化。
ISAKMP 提供能力为多重的安全协议和应用程序建立 SA 。这些协议和应用程序可以是会议面向的或 sessionless 。有支持多重的安全协议的一个 SA 建立协议消除需要为多重，将近相同的认证，密钥的交换和 SA 机构协议什么时候超过安全协议在使用或需要。就当 IP 为因特网提供了普通联网的层，如果安全是在因特网上成为现实，一个普通的安全建立协议被需要。 ISAKMP 提供允许所有的另外的安全协议互操作的普通的底。
    ISAKMP 跟随好安全设计原则。它没被联合到另外的不安的传输协议， 因此它不是脆弱的或由对另外的协议的攻击削弱了。另外，当更安全的传输协议被开发时， ISAKMP 能容易被移植到他们。ISAKMP 也对联系的协议提供保护攻击。该保护提供 SA 和建立的密钥，保证与需要的部分一起的而不与一个攻击者一起。
    ISAKMP 也跟随好协议设计原则。协议特定的信息仅仅在协议头，跟随 IPv6 的设计原则。协议搬运了的数据被分开成功能的有效负载。当因特网成长和演变， 支持新安全功能的新的有效负载能没有修改全部协议被增加。
A  ISAKMP 安全协会属性
A.1  背景 / 基本原理
在前面几节已详细说明了， ISAKMP 被设计为，建立和管理安全协会和密码的密钥，提供一个灵活并且可扩展的框架。 ISAKMP 提供的框架，由头和有效负载定义，指导消息和有效负载交换的交换类型，和普通处理指南组成。 ISAKMP 未定义将被用来建立和管理安全协会和密码的密钥在的机制证实和机密的方式。机制和他们的应用程序的定义是解释的单个的域的权限 ( DOI )。
这节描述因特网 IP安全 DOI 的 ISAKMP 值，支持的安全协议，和ISAKMP 阶段1的协商的鉴定值。因特网 IP 安全 DOI 是强制的为 IP 安全实现。[ Oakley ] 和 [ IKE ] 详细描述了，建立和管理IP安全的安全协会和密码密钥的机制和其应用程序。
A.2  因特网 IP 安全 DOI 的分配值
在 [ IPDOI ]描述了，因特网的IP 安全DOI的分配数字是一个(1)。
A.3  支持安全协议
支持的安全协议的值在“最新的分配的数字” RFC [ STD-2 ] 被指定。在下列表为协议发送了，由 ISAKMP 支持的因特网 IP 安全DOI安全协议的值。
                       协议分配的值
                       保留        0
                       ISAKMP    1
所有的 DOI 必须与 1 的 Protocol-ID 保留 ISAKMP 。在那 DOI 以内的所有的另外的安全协议将因此被标记。
安全协议值 2-15359 为未来使用被保留到 IANA 。值 15360-16383 永久地在互相同意之中为私人的使用被保留实现。
这样的私人的使用值是不大可能越过不同的实现可互操作。
A.4  ISAKMP 鉴定类型值
为鉴定的分配的值打域的下列表在一张通用的相期间发现了 1 交换在鉴定有效负载，它不为一个特定的协议。
                 ID 类型                   值
           ID_IPV4_ADDR                  0
           ID_IPV4_ADDR_SUBNET         1
           ID_IPV6_ADDR                  2
           ID_IPV6_ADDR_SUBNET         3
A.4.1  ID_IPV4_ADDR
ID_IPV4_ADDR 类型指定唯一的四位(4)八进制 IPv4 地址。
A.4.2  ID_IPV4_ADDR_SUBNET
ID_IPV4_ADDR_SUBNET 类型指定 IPv4 地址的一个范围， 由两个四位( 4 ) 八进制值代表。第一值是一个 IPv4 地址。第二是一个 IPv4 网络面具。注意那 ( 1s ) 在网络面具显示在地址的相应的位被修理，当零 ( 0s ) 时，显示一个“通配符”位。
A.4.3  ID_IPV6_ADDR
ID_IPV6_ADDR 类型指定唯一的十六位(16)八进制 IPv6 地址。
A.4.4  ID_IPV6_ADDR_SUBNET
ID_IPV6_ADDR_SUBNET 类型指定 IPv6 地址的一个范围，由 2:16 代表了 ( 16 ) 八进制值。第一值是一个 IPv6 地址。第二是一个 IPv6 网络面具。注意那 ( 1s ) 在网络面具显示在地址的相应的位被修理，当零(0s)时显示一个“通配符”位。
B定义新的解释域
因特网 DOI 足以的满足因特网社区的大部分的安全要求。然而，某些组可以有需要设定 DOI 的某些方面，可能是增加密码的算法的一个不同的集合，或者可能因为他们想要解除主机 id 或用户 id 以外基于某些其安全相关的决定。另外，一个特别的组可以有对一种新交换类型的需要，例如支持密钥的管理为多点传送组。
这节为定义新的 DOI 讨论指南。为因特网 DOI 的完整的说明能被发现在 [ IPDOI ] 。
定义新的 DOI 可能消费时间进程。如果根本可能，被推荐设计者开始存在的 DOI 和仅仅设定是不能接受的部分。
如果一个设计者选择启动，下列必须被定义：
* 一种“状况”：将被用来决定要求的安全的信息的集合满足。
* 必须被支持的安全策略的集合。
* 命名安全相关的信息的一个计划，包括加密算法，密钥的交换算法，等等。
* 满足建议的安全的说明的句法，归因，和认证当局。
* 各种各样的有效负载内容的特定的格式。
* 如果要求，附加的交换类型。
B.1  状况
状况是决定如何保护一条通讯隧道的基础。它必须包含SA中决定的，用于保护的类型和强度的所有数据。例如， 防卫 DOI 的一个美国部门可能使用未公布的算法和附加的特殊的属性谈判。这些附加的安全属性包括处于的状况之中。
B.2  安全策略
安全策略定义各种各样的信息的类型必须如何分类和保护。DOI 必须定义策略支持的安全的集合，因为在一个协商的两个聚会必须信任另外的部分理解一种状况，并且希望适当地保护信息，在传输并且在存储。在社团的设置，例如， 在一个协商的两个聚会必须同意条款的意思“以前他们能谈判的专利的信息”如何保护它。
注意，包括DOI中的请求安全策略仅说明，共享主机理解和实现完全系统框架的策略。
B.3  命名计划 
任何 DOI 必须定义一个一致的方法命名密码的算法，证书当局，等等。通常用IANA命名惯例实现，允许一些私人的扩展。
B.4  为指定安全服务的句法
除了简单地指定如何命名实体，DOI还必须为如何在一种给定的状况下保护流通量的完全的建议指定格式。
B.5  有效负载说明
DOI 必须指定有效负载类型的说有格式。对于有效负载类型，ISAKMP包括必须忽略所有DOI当前的域 ( 例如，证书有效负载的证书权威，或密钥的交换在密钥中的标识符交换有效负载 ) 。
B.6  定义新交换类型的
如果基本的交换类型不适合在DOI内满足要求，设计者可以在每个DOI中，定义13种额外的交换类型。设计者通过选择闲置的交换类型值，建立一种新交换类型，并且定义ISAKMP有效负载的字符串组成信息的顺序。
注意：任何新交换必须分析其危险性。由于太昂贵并且不能承担， 一种新交换类型应仅仅什么时候绝对需要才被建立。
安全考虑
密码的分析技术以稳定的步正在改进。持续的改进尽最大努力曾经做更现实主义的计算地禁止的密码的攻击。新的密码的算法和公钥产生技术也以稳定的步正在被开发。新安全服务和机制以加速的步正在被开发。从许多安全服务和机制并且到交换属性选择的一个一致的方法由机制要求了对在因特网的复杂的结构的安全重要。然而，锁自己进单个的密码的算法，密钥的交换技术，或机制将成为的安全的一个系统逐渐地脆弱当时间过去。
UDP 是一个不可靠的数据包协议并且因此它的在 ISAKMP 的使用介绍很多安全考虑。自从 UDP 是不可靠的，但是一个密钥的管理协议一定是可靠的， 可靠性被造进 ISAKMP 。当 ISAKMP 作为它的传输机制利用 UDP 时，它不依靠任何 UDP 信息 ( 例如检查和长度 ) 为它的处理。
必须在 ISAKMP 的开发被考虑的另外的问题是在协议上的防火墙的效果。许多防火墙外面过滤所有的 UDP 包， 在某个环境在 UDP 上使信赖可疑。
很多很重要的安全考虑被送在 [ SEC-ARCH ] 。一种负担的重复。一旦私人的会议密钥被建立，它必须安全地被存储。阻止到系统内部私人的密钥和外部的存取的失败，会废弃任何由 IP 安全提供的服务保护。
IANA 考虑
这个文件包含许多IANA 维持的“魔术”的数字。该节解释通过IANA使用的标准，在每个表中分配其它的数字。
解释域
解释的域(DOI)是一个32位的域，识别在安全联盟协会正在发生时的领域。请求新的DOI的任务，必须伴随描述特定的域的标准轨道RFC。
支持的安全协议
ISAKMP设计为提供安全连接协商和密钥管理的许多安全协议。附加的安全协议的标识符的请求必须伴随一个描述安全协议和ISAKMP关系的标准轨道RFC。
鸣谢
Cisco系统的Dan Harkins,Dave Carrel,和Derrell Piper提供[IKE]和[IPDOI]文件的协议和规范的设计与帮助。
Hilarie Orman，经过Oakley密钥交换协议，显著地影响ISAKMP的设计。
Marsha Gross，Bill Kutz，Mike Oehler，Pete Sell和Ruth Taylor为该文件提供重要的输入和核查。
Scott Carlson为使用ISAKMP原型移植TIS DNSSEC原型到FreeBSD。
Jeff Turner和Steve Smalley对于ESP和AH的原型发展和集成的贡献。
Mike Oehler和Pete Sell与其它的ISAKMP实现者执行的互操作性的测试。
感谢SPARTA公司的Carl Muckenhirn，提供LaTeX的帮助。
参考数目
   [ANSI]     ANSI, X9.42:  Public Key Cryptography for the Financial
              Services Industry -- Establishment of Symmetric Algorithm
              Keys Using Diffie-Hellman, Working Draft, April 19, 1996.

   [BC]       Ballardie, A., and J. Crowcroft, Multicast-specific
              Security Threats and Countermeasures, Proceedings of 1995
              ISOC Symposium on Networks & Distributed Systems Security,
              pp. 17-30, Internet Society, San Diego, CA, February 1995.

   [Berge]    Berge, N., "UNINETT PCA Policy Statements", RFC 1875,
              December 1995.

   [CW87]     Clark, D.D. and D.R. Wilson, A Comparison of Commercial
              and Military Computer Security Policies, Proceedings of
              the IEEE Symposium on Security & Privacy, Oakland, CA,
              1987, pp. 184-193.

   [DNSSEC]   D. Eastlake III, Domain Name System Protocol Security
              Extensions, Work in Progress.

   [DOW92]    Diffie, W., M.Wiener, P. Van Oorschot, Authentication and
              Authenticated Key Exchanges, Designs, Codes, and
              Cryptography, 2, 107-125, Kluwer Academic Publishers,
              1992.

   [IAB]      Bellovin, S., "Report of the IAB Security Architecture
              Workshop", RFC 2316, April 1998.

   [IKE]      Harkins, D., and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [IPDOI]    Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", RFC 2407, November 1998.

   [Karn]     Karn, P., and B. Simpson, Photuris:  Session Key
              Management Protocol, Work in Progress.

   [Kent94]   Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August
              10, 1994.

   [Oakley]   Orman, H., "The Oakley Key Determination Protocol",  RFC
              2412, November 1998.

   [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
              Mail:  Part II: Certificate-Based Key Management", RFC
              1422, February 1993.

   [RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC
              1949, May 1996.

   [RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Specification", RFC 2093, July 1997.

   [RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Architecture", RFC 2094, July 1997.

   [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Schneier] Bruce Schneier, Applied Cryptography - Protocols,
              Algorithms, and Source Code in C (Second Edition), John
              Wiley & Sons, Inc., 1996.

   [SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [STD-2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
              1700, October 1994.  See also:
              http://www.iana.org/numbers.html
作者地址
Douglas Maughan
   National Security Agency
   ATTN: R23
   9800 Savage Road
   Ft.  Meade, MD. 20755-6000
   Phone:  301-688-0847
   EMail:wdm@tycho.ncsc.mil

   Mark Schneider
   National Security Agency
   ATTN: R23
   9800 Savage Road
   Ft.  Meade, MD. 20755-6000
   Phone:  301-688-0851
   EMail:mss@tycho.ncsc.mil

   Mark Schertler
   Securify, Inc.
   2415-B Charleston Road
   Mountain View, CA 94043
   Phone:  650-934-9303
   EMail:mjs@securify.com

   Jeff Turner
   RABA Technologies, Inc.
   10500 Little Patuxent Parkway
   Columbia, MD. 21044
   Phone:  410-715-9399
   EMail:jeff.turner@raba.com
版权声明   
版权(C) 国际互联网社会（1998）。版权所有。
这个文档和它的翻译可能被拷贝和提供给别人，并且引出的工作关于评论或注释或帮助它执行可能被准备，拷贝，印刷和分配，不管是那一部分，没有任何的限制，提供上面的版权通知和文章中包含的图片以及大量的引出工作。但是，这个文章它自己不能以任何方式跟改，例如移走版权通知或提及因特网社会的参考书目或别的互联网组织，除了发展因特网标准的需要，在这种情况下，在因特网标准过程中定义的版权程序应该存在，或将它翻译成不同于英语的外国语的需要。
上面有限的许可是永久的，它不应该被互联网社会或它的接替者破坏。
 这个文件和包含在这里的信息作为基础来提供，互联网社会和这个互联网工程任务迫使它宣布所有的理由，不管是明指的还是推断的，包括但是不限制任何理由来使用信息不能破坏一些权利或一些推断出的授权购买或适合某一特定的目的。