RFC2407 Internet IP 用于解释ISAKMP的安全域

因特网交换密钥
The Internet Key Exchange (IKE)
November 1998


















目录
1. 摘要 5
2. 介绍 5
3. 术语和定义 6
4．IPSEC 6
4.1 IPSEC命名方案 6
4.2  IPSEC 状况定义 6
4.2.1  SIT_IDENTITY_ONLY 6
4.2.2  SIT_SECRECY 7
4.2.3  SIT_INTEGRITY 7
4.3  IPSEC 安全策略要求 7
4.3.1  密钥管理问题 8
4.3.2  静态的密钥问题 8
4.3.3  主机策略问题 8
4.3.4  证书管理 9
4.4  IPSEC 分配数 9
4.4.1  IPSEC 安全协议标识符 9
4.4.2  IPSEC  ISAKMP 转变标识符 10
4.4.3  IPSEC AH转变标识符 11
4.4.4  IPSEC  ESP 转变标识符 12
4.4.5  IPSEC  IPCOMP 转变标识符 15
4.5  IPSEC 安全关联属性 16
4.5.1 要求的属性支持 18
4.5.2 分析要求的属性 ( 一生) 19
4.5.3 属性协商 19
4.5.4 一生通知 20
4.6  IPSEC 有效负载内容 20
4.6.1 安全关联有效负载 20
4.6.2 鉴定有效负载内容 23
4.6.3 IPSEC通报信息类型 26
4.7  IPSEC 密钥交换要求 29
5．安全考虑 29
6．IANA 需要考虑的事项 29
6.1 IPSEC位置定义 30
6.2 IPSEC 安全协议标识符 30
6.3 IPSEC ISAKMP 转移标志符 30
6.4 IPDEC AH 转移标识符 31
6.5 IPSEC ESP转移标识符 31
6.7 IPSEC安全相连属性 32
6.8 IPSEC 标签范围标识符 32
6.9 IPSEC 标识符类型 32
6.10 OPSEC通报信息类型 32
7．改变LOG 33
7.1 从V9中改变 33
7.2 从V8 中改变 33
7.3 从V7 中变化 33
7.4 从V6 中改变 34
7.5 从V5中变化 35
7.6 从V4中的变化 35
7.7 从V3 到V4的变化 36
致谢 36
参考书目 37
全部版权陈述 39

1. 摘要
因特网安全关联和关密钥的管理协议 ( ISAKMP ) 为因特网安全关联管理和密钥建立定义一个框架。这个框架由定义了的交换，有效负载，和在给定解释域(DOI )以内发生的处理指南组成。这个文件定义因特网 IP 安全 DOI ( IPSEC  DOI ), 它用具体例子说明IP 适合同 ISAKMP 一起使用,当 IP 使用 ISAKMP商定安全关联。
关于 IPSEC  DOI 的先前版本的变化的列表，请见7 节。
2. 介绍
在 ISAKMP 以内，解释的域被用来通过使用 ISAKMP 组织有联系的协议来商议安全关联。共享一个DOI 的安全协议选择安全协议和从一个普通的 ，名字空间转变的密码并且共享关密钥的交换协议标识符。他们也共享 DOI 特定的有效负载数据内容的普通解释, 包括安全关联和鉴定有效负载。
总的来说, ISAKMP 把下列要求放在一个 DOI 定义上：
o  为 DOI 特定的协议标识符定义命名方案
o  为状况域定义解释
o  定义适用的安全策略集合
o  为 DOI 特定的 SA 属性的定义句法( 阶段II ）
o  为 DOI 特定的有效负载内容定义句法
o  定义附加的密钥交换类型, 如果需要
o  定义附加的通知消息类型, 如果需要
这个文件的剩余部分为使用 IP 安全(IPSEC )协议提供认证, 完整性，或为 IP 包的机密在合作主机系统或防火墙之间送的请求,进行了详细实例化。
对于全面的 IPSEC 体系结构描述，见 [ARCH ],[AH ], 和 [ESP ] 。
3. 术语和定义
关键词必须, 不能, 要求, 将, 将不, 应该, 应该不, 推荐,可能和可选,当他们再文档中出现时,被解释成如[RFC 2119]所描述的。
4．IPSEC
4.1 IPSEC命名方案
在 ISAKMP 以内，所有的 Doi 的必须在“分配的数字” RFC [ STD-2 ]内同 IANA一起被登记。 IANA 为因特网IP 安全DOI ( IPSEC  DOI )分配的数字是一个 ( 1 ) 。在 IPSEC  DOI 以内，所有著名的标识符必须在 IPSEC  DOI 下面与 IANA 一起被登记。除非另外注明, 在这个文件以内的所有表参考为IPSEC  DOI而被分配数字的 IANA 。对于 IPSEC  DOI 联系到 IANA 注册表的进一步的信息,见节 6。
所有的多字节二进制代码值在网络字节顺序被存储。
4.2  IPSEC 状况定义
在 ISAKMP 以内，状况提供能被响应者用来作出一条关于怎么处理到来的安全关联信息请求策略的决定。对于IPSEC  DOI ，状况域是一个有下列值的4字节位掩码。
状况 值
--------------
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1  SIT_IDENTITY_ONLY
SIT_IDENTITY_ONLY类型指定,安全关联将被在联系的鉴定有效负载中提供的源身份信息所标记 。对于各种各样的鉴定的完全描述见节 4.6.2。所有的 IPSEC  DOI 实现必须支持SIT_IDENTITY_ONLY,由在至少一次阶段I Oakley 交换中包含鉴定有效负载 ([ IKE ], 节 5 ) ,并且必须放弃任何不包括鉴定的安装有效负载关联。
如果一个开始者既不支持 SIT_SECRECY 也不支持 SIT_INTEGRITY ，状况仅仅由 4 字节状况位图组成并且不包括标记的域标识符域 ( 图 1 , 节 4.6.1 ) 或任何随后的标签信息。相反的,如果开始者支持 SIT_SECRECY 或 SIT_INTEGRITY ，标记的域标识符必须在状况有效负载时被包括。
4.2.2  SIT_SECRECY
SIT_SECRECY类型指定安全关联在要求标记秘密的环境中正被商议。如果SIT_SECRECY 在状况位图中出现，状况域将被变量长度数据跟随,他们包括敏感级别和分隔空间位掩码。关于安全关联有效负载格式的完全的描述,见节4.6.1。
如果一个开始者不支持 SIT_SECRECY ， SIT_SECRECY状况位图不能被设置并且秘密级别或范畴位图将被包括。
如果一个应答者不支持 SIT_SECRECY ，环境不支持的标志信息有效负载应该被返回并且安全关联安装必须被放弃。
4.2.3  SIT_INTEGRITY
SIT_ INTEGRITY类型指定安全关联在要求标记完整性的环境中正被商议。如果 SIT_ INTEGRITY 在状况位图中出现，状况域将被变量长度数据跟随,他们包括完整级别和分隔空间位掩码。如果SIT_SECRECY也用于关联,完整信息立即遵从变长秘密级别和类别。关于安全关联有效负载格式的完全的描述,见节 4.6.1 。
如果一个开始者不支持 SIT_ INTEGRITY ， SIT_ INTEGRITY状况位图不能被设置并且无完整性级别或范畴位图将被包括。
如果一个应答者不支持 SIT_ INTEGRITY ，环境不支持的标志信息有效负载应该被返回并且安全关联安装必须被放弃。
4.3  IPSEC 安全策略要求
IPSEC  DOI 不在任何实现上强加特定的安全策略要求。主机系统策略问题将在这个文件的范围以外。
然而, 当设计一个 IPSEC  DOI 主机实现时，在下面的章节涉及的一些问题必须被考虑。这节自然应该被认为仅仅参考。
4.3.1  密钥管理问题
选择来实现 ISAKMP 的许多系统将努力为一个联合的 IKE 密钥管理新进程提供执行的保护域，这被期望。在保护模式多用户操作系统上，这个密钥管理进程将多半作为分开的特权进程存在。
在这个环境中，介绍密钥材料到 TCP/IP 核的形式化的API 可以是合乎需要的。 IP 安全体系结构不放任何结构要求,或在一个主机 TCP/IP核和它的密钥管理供应商之间流动。
4.3.2  静态的密钥问题
实现静态密钥的主机系统, 或由 IPSEC直接使用，或为认证目的 ( 见 [ IKE ] 节 5.4 ) ，当它不在保护的内存域或由TCP/IP 核使用时,应该采取步骤保护静态的密钥材料。
例如, 在一台膝上计算机上，一个人可能选择在一家配置存储器存储静态的密钥, 自己, 在一个私人的口令下面加密了。
依靠操作系统和安装的实用程序软件, 一旦静态的密钥装载进TCP/IP 核，他们被保护是不可能的，然而他们不能在没有满足一些附加形式的认证下而在起始的系统开始轻易重获
4.3.3  主机策略问题
假设 IPSEC 的转变在一夜间发生，是不现实的。主机系统必须准备实现灵活的策略表, 策略表描述哪个系统他们需要安全地通话和他们要求通话安全的系统。一些观点认为代理防火墙地址可以被要求。
一条最小的途径可能是 IP 地址，网络掩码，和安全要求标志或标志的一张静态表。
一个更灵活的实现可能由一列通配符 DNS 的命名 ( 例如 "*.foo.bar'),一个在里 / 外 位掩码 ，和一个可选的防火墙地址组成。通配符 DNS 名字将被用来匹配到来或出去的 IP 地址, 里 / 外位掩码将被用来决定安全是否将被使用,和哪个方向，并且可选的防火墙地址将被用来显示通道模式是否需要通过中间防火墙与目标系统谈话。
4.3.4  证书管理
实现一个基于证书的认证计划的主机系统将需要一个机制来获得和管理证书   数据库。
安全的 DNS 是是一个证书分发机制, 然而安全的 DNS 地区的普遍应用, 在短术语中，有许多值得怀疑的原因。更可能的是，主机将
需要进口他们通过的安全, out-of-band 机制获得证书的权能, 和出口自己的证书给另外的系统使用。
然而,手工证书管理不能被执行以便防止介绍动态的证书发现机制或协议的权能成为可行的。
4.4  IPSEC 分配数
下列节为 IPSEC  DOI 列出分配的数字：状况标识符, 协议标识符, 转变标识符，AH， ESP ，并且 IPCOMP 转变标识符, 安全协会属性类型值, 标记的域标识符， ID 有效负载类型值，和通知消息类型值。
4.4.1  IPSEC 安全协议标识符
ISAKMP 建议句法被特定的设计来允许多重的阶段 II 安全协议的同时协商在一个单个的协商内适用。作为结果，下面被列出了的协议组形成了能同时被协商的协议集合。它是决定什么协议能被协商在一起的一个主机策略决定。
下列表为IPSEC DOI而在ISAKMP建议有效负载中引用的安全协议标识符列出值的。
协议 ID 值
----------- -----
保留 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1  PROTO_ISAKMP
PROTO_ISAKMP类型指定在阶段I的ISAKMP协议期间要求的消息保护。在 IPSEC  DOI 中被使用的特定的保护机制在 [ IKE ]中被描述。在 IPSEC  DOI 以内的所有的实现必须支持PROTO_ISAKMP 。
NB ：  ISAKMP 保留该值一( 1 ), 越过所有的 DOI 定义。
4.4.1.2  PROTO_IPSEC_AH
PROTO_IPSEC_AH 类型指定 IP 包认证。缺省AH转变提供数据起源认证, 完整保护, 和重放探测。对于出口控制考虑，机密不能被任何 PROTO_IPSEC_AH转变所提供。
4.4.1.3  PROTO_IPSEC_ESP
PROTO_IPSEC_ESP 类型指定 IP 包机密。如果要求认证，必须作为 ESP 的部分被提供转变。缺省 ESP 转变包括数据起源认证,完整保护, 重放探测, 和机密性。
4.4.1.4  PROTO_IPCOMP
如在[ IPCOMP ]里面定义的, PROTO_IPCOMP类型指定 IP 有效负载压缩。
4.4.2  IPSEC  ISAKMP 转变标识符
作为一个 ISAKMP 阶段I协商的部分, 开始者的密钥的交换提供的选择被用来作一些主机系统策略描述。实际的密钥交换机制选择被用来做标准的 ISAKMP 建议有效负载。下列表格列出对于IPSEC  DOI 的为建议有效负载定义的ISAKMP 阶段I转变标识符。
转变 值
--------- -----
保留 0
KEY_IKE 1
在 ISAKMP 和 IPSEC  DOI 框架内除 IKE ( Oakley )以外定义密钥的建立协议，是可能的。这个文件的先前版本定义了基于一个通用密钥的分发中心( KDC )的使用的手工密钥和计划。这些标识符从当前的文件被移走了。
IPSEC  DOI 还能在以后被扩大到为附加的non-Oakley 密钥建立协议包括 关于ISAKMP 和 IPSEC的值, 例如 Kerberos [ RFC-1510 ]或组密钥管理协议( GKMP )[ RFC-2093 ] 。
4.4.2.1  KEY_IKE
KEY_IKE 类型指定混合的 ISAKMP/Oakley  Diffie-Hellman  密钥的交换 ( IKE ) ,如在 [ IKE ] 文件定义。在 IPSEC  DOI以内的所有的实现必须支持 KEY_IKE 。
4.4.3  IPSEC AH转变标识符
认证头协议 ( AH ) 定义一个强制的和若干可选的转变用于提供认证, 完整性, 和重放探测。下列表列出定义的AH转变标识符为IPSEC DOI的ISAKMP 建议有效负载。
注意： 认证算法属性必须被指定认明适当的H保护组。例如, AH_MD5最好能被想作使用 MD5的通用AH转变。为了AH请求 HMAC 构造, 一个人指定AH_MD5转变 ID,伴随着认证算法属性设置到 HMAC-MD5。这被显示使用 " Auth (HMAC-MD5 )" 标志在下列节。
转变 ID 值
----------- -----
保留 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
注意： 所有的 mandatory-to-implement 算法被列出作为必须实现 ( 例如 AH_MD5 ) 在下列节。所有另外的算法是可选的并且可能在任何特别的应用中被实现。
4.4.3.1  AH_MD5
AH_MD5 类型指定使用 MD5的通用AH转变。实际的保护组被决定与SA联系表一致。通用的 MD5 转变当前未定义。
在 IPSEC  DOI 内的所有的实现必须与 Auth 一起支持 AH_MD5 ( HMAC-MD5 ) 属性。这组被定义为 HMAC-MD5-96转变,如在 [ HMACMD5 ] 中描述的。
与 Auth 一起的 AH_MD5 类型 ( KPDK ) 属性指定了AH转变 ( 密钥 / 垫 / 数据 / 密钥 ) 描述在 RFC-1826。
有任何另外的认证算法的 AH_MD5 的使用属性值当前未定义。
4.4.3.2  AH_SHA
AH_SHA 类型指定使用 SHA-1的通用AH转变。实际的保护组决定为与联系的 SA属性表一致。通用的 SHA 转变当前未定义。
在 IPSEC  DOI 以内的所有的实现必须与 Auth 一起支持 AH_SHA ( HMAC-SHA ) 属性。这组被定义为描述在 [ HMACSHA ]中的 HMAC-SH A-1-96转变。
与任何另外的认证算法属性值一起使用的 AH_SHA当前未定义。
4.4.3.3  AH_DES
AH_ DES 类型指定使用DES的通用AH转变。实际的保护组决定为与联系的 SA属性表一致。通用的DES转变当前未定义。
IPSEC  DOI定义AH_DES和Auth(DES-MAC)属性为DES-MAC转变。实现不需要支持这种模式.
与任何另外的认证算法属性值一起使用的 AH_ DES当前未定义。
4.4.4  IPSEC  ESP 转变标识符
包含的安全有效负载 ( ESP ) 定义一个强制的和用于常提供数据机密可选的许多转变。下列表格列出定义的对于 IPSEC  DOI为 ISAKMP 建议有效负载的ESP 转变标识符。
注意： 什么时候认证, 完整保护, 和重放探测被要求, 认证算法属性必须被指定来认明适当的 ESP 保护组。例如,请求有3DES 的HMAC-MD5 认证，一个人指定 ESP_3DES属性转变 ID并且设置把认证算法属性设置为HMAC-MD5。对于附加处理的要求，见节4.5 （认证算法 ）。
转变 ID 值
------------ -----
保留 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
注意：在下列节中所有的 mandatory-to-implement 算法被列出作为必须实现  ( 例如 ESP_DES )。所有另外的算法是可选的并且可能在任何特别的应用中被实现。
4.4.4.1  ESP_DES_IV64
ESP_DES_IV64 类型指定定义在RFC-1827和使用一个 64 比特 IV中的RFC-1829 DES-CBC转变
4.4.4.2  ESP_DES
ESP_DES 类型指定使用 DES-CBC的一个通用的 DES 转变。实际的保护组定义得与SA属性表一致。一个通用转变当前未定义。
在 IPSEC  DOI内的所有实现必须与 Auth  ( HMAC-MD5 )一起支持ESP_DES 属性。这组被定义为 [ DES ] 转变,由 HMAC MD5 [ HMACMD5 ]提供认证和完整性了。
4.4.4.3  ESP_3DES
ESP_3DES 类型指定一个通用的 triple-DES 转变。实际的保护组定义得与SA属性表一致。通用转变当前未定义。
在 IPSEC  DOI 内的所有的实现强烈支持ESP_3DES和 Auth( HMAC-MD5 ) 属性。这组被定义为 [ ESPCBC ] 转变, 由 HMAC  MD5 [ HMACMD5 ] 提供认证和完整性。
4.4.4.4  ESP_RC5
ESP_RC5 类型指定 定义在[ ESPCBC ]RC5 的转变。
4.4.4.5  ESP_IDEA
ESP_IDEA 类型指定定义在 [ ESPCBC ]的IDEA转变。
4.4.4.6  ESP_CAST
ESP_CAST 类型指定定义在 [ ESPCBC ]的CAST转变。
4.4.4.7  ESP_BLOWFISH
ESP_BLOWFISH 类型指定定义在[ ESPCBC ]的 BLOWFISH 转变。
4.4.4.8  ESP_3IDEA
ESP_3IDEA 类型为 triple-IDEA 保留。
4.4.4.9  ESP_DES_IV32
ESP_DES_IV32 类型指定定义在 RFC-1827和使用一 32 位的 IV 的RFC-1829 的DES-CBC转变。
4.4.4.10  ESP_RC4
ESP_RC4 类型为 RC4 保留。
4.4.4.11  ESP_NULL
ESP_NULL类型没有指定任何机密被 ESP 提供。当 ESP 被用于仅仅要求认证,完整性,和重放探测的通道包时，ESP_NULL被使用。
在 IPSEC  DOI 内的所有实现必须支持 ESP_NULL 。ESP NULL转变在 [ ESPNULL ]中被定义。为得到关联ESP_NULL 使用的附加要求,见节 4.5 认证算法属性描述。
4.4.5  IPSEC  IPCOMP 转变标识符
IP 压缩 ( IPCOMP ) 转变定义了能被协商为 IP 有效负载压缩([ IPCOMP ])所提供的可选压缩算法  。下列表列出已定义的IPCOMP 内,为 ISAKMP 建议有效负载转变标识符
IPSEC  DOI
转变 ID 值
------------ -----
保留 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1  IPCOMP_OUI
IPCOMP_OUI 类型指定专利的压缩转变。IPCOMP_OUI类型必须由进一步认明特定供应商算法的属性伴随。
4.4.5.2  IPCOMP_DEFLATE
IPCOMP_DEFLATE 类型指定“ zlib ”缩小算法的使用如在 [ 降低 ]中指定。
4.4.5.3  IPCOMP_LZS
IPCOMP_LZS 类型指定 Stac电子学 LZS 算法的使用如在[ LZS ]中指定的。
4.5  IPSEC 安全关联属性
下列 SA 属性定义被使用在一个 IKE 协商的相 II。属性类型可以是基本 (B) 或可变的长度 (V) 。这些属性编码被定义在基层的 ISAKMP说明中。
描述为基本的属性不能被编码为变量。如果他们的值适合在两个字节中，可变的长度属性可以被编码为基本属性。属性上关于IPSEC  DOI的进一步信息编码见[ IKE ]。列出在 [ IKE ]的所有限制也适用于 IPSEC  DOI。
属性类型
类 值 类型
-------------------------------------------------
SA 生命类型 1 B
SA 生命持续时间 2 V
组描述 3 B
封装模式 4 B
认证算法 5 B
密钥长度 6 B
密钥 Rounds 7 B
压缩字典大小 8 B
压缩私人的算法 9 V
类值
SA 生命类型
SA 持续时间
为了全面安全关联而指定生命时间。当 SA 到期时，在关联下面协商所有的密钥( AH或 ESP ) 必须重新协商。生命类型值是：
保留 0
第二 1
K 字节 2
值 3-61439 被保留到 IANA中 。值 61440-65535 为私有使用。对于一种给定的生命类型，生命持续时间属性的值定义了部件一生的实际长度--或很多秒，或能被保护的很多 Kbytes 。
如果未特别指出，缺省值将被假定为28800 秒 ( 8小时 ) 。
SA 生命持续时间属性必须总是遵从描述持续时间单位的SA 生命类型。
对于一生通知联系的附加信息见节 4.5.4 。
组描述
指定在一个 PFS  QM 协商被使用的Oakley 组。关于支持值的列表，见附录一的 [ IKE ] 。
封装模式
保留 0
隧道 1
运输 2
值 3-61439 被保留到 IANA 。值 61440-65535 为私人使用。
如果未特别指出，缺省值将被假定为未特别指出 ( 主机依赖 ) 。
认证算法
保留 0
HMAC-MD5 1
HMAC-SHA 2
DES-MAC 3
KPDK 4
值 5-61439 被保留到 IANA 。值 61440-65535 为私人使用。
当它必须被指定来正确的认明适用的AH或 ESP 转变时, Auth 算法没有缺省值, 除了在下列情况中。
当协商的ESP时， Auth 算法属性不能被包括在建议中。
当协商没有机密的ESP时， Auth 算法属性必须被包括在建议中并且ESP转变的 ID 必须是 ESP_NULL 。
密钥的长度
保留 0
密钥长度没有缺省值, 如它必须为使用可变密钥长度的密码转变而被指定。对于固定长度的密码，密钥长度属性不能被传送。
密钥的 Rounds
保留 0
密钥的 Rounds 没有缺省值, 如它必须为使用rounds 变化数字密码的转变被指定。
压缩字典大小
保留 0
指定log2为字典大小的最大值。
字典大小没有缺省值。
压缩私人算法
指定私人供应商压缩算法。首先的 3 ( 3 ) 字节必须是被分配了的company_id 的一个 IEEE ( OUI ) 。下一个字节可以是供应商特定的压缩子类型,跟随着供应商零或更多字节的数据。
4.5.1 要求的属性支持
保证基本的互操作性, 所有的实现必须准备协商下列所有属性。
SA 生命类型
SA 持续时间
Auth 算法
4.5.2 分析要求的属性 ( 一生)
允许灵活的语义, IPSEC  DOI 要求一个遵守 ISAKMP 的实现必须正确分析包含相同属性类多重例子的属性表，只要不同的属性入口不与对方冲突。当前, 要求处理的唯一属性是生命类型和持续时间。
为了知道这为什么重要, 下列例子显示一个二进制 4 入口编码指定 100MB 或 24 小时的 SA 一生的属性表。（见节 3.3 [ISAKMP ] 为属性的完全描述编码格式。）
属性 #1 ：
0x80010001  （ AF = 1 , 类型 = SA 生命类型, 值 = 秒）
属性 #2 ：
0x00020004  ( AF = 0 , 类型 = SA 持续时间, 长度 = 4个字节 ) 0x00015180  值 = 0x15180 =86400 秒 = 24 小时)
属性 #3 ：
0x80010002  （ AF = 1 , 类型 = SA 生命类型, 值 = KB ）
属性 #4 ：
0x00020004  ( AF = 0 , 类型 = SA 持续时间, 长度 = 4个字节 ) 0x000186A0 ( 值 = 0x186A0 =100000KB = 100MB )
如果冲突属性被检测到, ATTRIBUTES-NOT-SUPPORTED 通知有效负载应该被返回并且安全关联安装必须被放弃。
4.5.3 属性协商
如果实现收到一个它不支持的定义了的 IPSEC  DOI 属性 ( 或属性值 ), 一个 ATTRIBUTES-NOT-SUPPORT 应该被发送并且安全关联安装必须被放弃的，除非属性值在保留的范围内。
如果实现在保留范围收到属性值，实现可能选择继续基于本地的策略。
4.5.4 一生通知
当一个开始者提供比应答者基于他们的本地的策略所需的大的 SA一生时，应答者有 3种选择： 1 )协商全部失败; 2 ) 完成协商但是使用比被提供的更短的一生; 3 ) 完成协商并且送一份建议通知到显示应答者真实一生的开始者。应答者实际上做的选择是实现特定的或基于本地的策略。
在后者情况中保证互操作性, 当应答者希望通知开始者时， IPSEC  DOI 仅仅要求下列：如果开始者提供的 SA 一生与应答者愿意接受的长，应答者应该在包括应答者 IPSEC  SA 有效负载的交换包括 ISAKMP 通知的有效负载。节 4.6.3.1 为必须被用于这个目的消息类型的RESPONDER-LIFETIME 通知定义有效负载布局。
4.6  IPSEC 有效负载内容
下列节描述其数据表示依赖于适用的 DOI 的那些 ISAKMP 有效负载。
4.6.1 安全关联有效负载
下列图表为 IPSEC  DOI 说明安全关联有效负载的内容。对于状况位图的描述见节 4.2 。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一个有效负载！  保留    ！       有效负载长度         ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！               解释的域 ( IPSEC ）               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！                      状况 ( 位图）                      ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！                   标记的域标识符                  ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密长度 ( 在字节）   ！          保留            ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        秘密级别                          
                                                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密连接。长度 ( 在位中 ) ！          保留            ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    秘密范畴位图                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！完整长度 ( 在字节）  ！          保留            ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       完整级别                         
                                                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ Integ 。连接。长度 ( 按位）  ！          保留            ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  完整范畴位图                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 1 ：安全关联有效负载格式
安全关联有效负载被定义如下：
o  下一个有效负载 ( 1 字节 )在消息中的下一个有效负载的有效负载类型标识符。如果当前的有效负载是在消息的最后，这域将是零 ( 0 ) 。
o  保留 ( 1 字节 )- 闲置, 必须是零 ( 0 ) 。
o  有效负载长度 ( 2 字节 )- 长度,字节，当前的有效负载，包括通用的头。
o  解释的域 ( 4 字节 )- 指定 IPSEC  DOI , 它被分配了值一( 1 ) 。
o  状况 ( 4 字节 )- 位掩码过去常解释安全关联有效负载的剩余部分。关于值的完全表见节 4.2 。
o  标记过的域标识符 ( 4 字节 )- 被分配了数字的 IANA被用来解释秘密和完整性信息。
o  密文长度 ( 2个字节)- 在字节上,指定秘密级别标识符长度，排除垫位。
o  保留 ( 2 个字节 )-闲置, 必须是零 ( 0 ) 。
o  秘密级别 ( 可变长度 )- 指定要求的强制秘密级别。秘密级别必须填 ( 0 ) 来在下一条 32 位边界上排列。
o  秘密类别长度 ( 2 个字节 )- 指定长度, 按位，秘密类别 ( 分隔空间 ) 位图, 排除垫位。
o  保留 ( 2 个字节 )- 闲置, 必须是零 ( 0 ) 。
o  秘密类别位图 ( 可变长度 )- 一个位图被用来指明被要求的秘密类别( 分隔空间 )。位图必须填 ( 0 ),在下一条 32 位边界上排列。
o  完整长度 ( 2 个字节 )- 指定长度, 按字节，完整级别标识符，排除垫位。
o  保留 ( 2 个字节 )- 闲置, 必须是零 ( 0 ) 。
o  完整级别 ( 可变长度 )- 指定要求的强制完整级别。完整级别必须填 ( 0 ) 在下一条 32 位的边界上排列。
o  完整类别长度 ( 2 个字节 )- 指定长度, 按位，完整类别 ( 分隔空间 ) 位图, 排除垫位。
o  保留 ( 2 字节 )- 闲置, 必须是零 ( 0 ) 。
o  完整类别位图 ( 可变长度 )- 一个位图被用来指明被要求的完整类别 ( 分隔空间 )。位图必须填 ( 0 ),在下一条 32 位的边界上排列。
4.6.1.1  IPSEC 标记了的域标识符
下列表列出标记域标识符域的分配的值,它被包含在关联有效负载的安全状况域中。
域 值
------ -----
保留 0
4.6.2 鉴定有效负载内容
鉴定有效负载被用来认明安全关联的开始者。开始者的身份应该被应答者使用来决定关联要求的正确主机系统安全策略。例如,一台主机可能选择没有要求从某个集合IP 地址机密认证和完整性,和另一范围IP 地址地完全机密性认证。鉴定有效负载提供能被应答者用来作出决定的信息。
在阶段期I协商期间， ID 端口和协议域必须被设置为零或上到500 的 UDP。如果实现收到任何另外的值，这必须被当作一个错误并且安安全关联装必须被放弃。这个事件应该是 auditable 。
下列图表说明鉴定有效负载的内容。
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 类型     ！协议 ID  ！            端口              ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     鉴定数据                       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 2 ：鉴定有效负载格式
鉴定有效负载域被定义如下：
o  下一个有效负载 ( 1 字节 )-在消息中关于下一个有效负载的有效负载类型标识符。如果当前的有效负载是消息的最后一个，这域将是零 ( 0 ) 。
o  保留 ( 1 字节 )- 闲置, 必须是零 ( 0 ) 。
o  有效负载长度 ( 2 字节 )- 长度, 按字节，鉴定数据，包括通用头。
o  鉴定类型 ( 1 字节 )- 描述在鉴定数据域发现的身份信息值。
o  协议 ID ( 1 字节 )- 指定一个联系的 IP 值协议 ID (例如 UDP/TCP ) 。零值意味着协议 ID 域应该被忽略。
o  端口 ( 2 字节 )- 指定一个联系的端口值。零值意味着协议 ID 域应该被忽略。
o  鉴定数据 ( 可变长度 )- 值,如由鉴定类型显示的。
4.6.2.1  鉴定类型值
下列表格列出了鉴定有效负载中为鉴定类型域分配的值。
ID 类型 值
------- -----
保留 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
对于ID 实体是可变长度的类型， ID实体的大小在 ID 有效负载头中以大小被计算。
当 IKE 交换被证实使用证书时 ( 任何格式 ),任何被用来输入到本地策略决定的Id必须被包含在交换用来认证的证书中。
4.6.2.2  ID_IPV4_ADDR
ID_IPV4_ADDR 类型指定单个 4 ( 4 ) 字节的 IPv4 地址。
4.6.2.3  ID_FQDN
ID_FQDN 类型指定一个完全合格的域名字符串。一个 ID_FQDN 例子是，“ foo.bar.com ”。字符串不能包含任何终止符。
4.6.2.4  ID_USER_FQDN
这个ID_USER_FQDN 类型指定一个有很高权限的用户名字符串，ID_USER_FQDN的一个例子是"piper@foo.bar.com".这个字符串不应该包含任何界限。
4.6.2.5  ID_IPV4_ADDR_SUBNET
这个ID_IPV4_ADDR_SUBNET类型详细说明IPV4地址的排列，它表现为两个四位的八位位组值。第一个值是IPV4的地址。第二个值是IPV4的网络面具。特别注意这个网络面具中的ones(1s)指示的相应的位被固定，而zeros(0s)指示一个通配符位。
4.6.2.6  ID_IPV6_ADDR
这个ID_IPV6_ADDR类型指定一个单一的16位八位位组Ipv6地址。
4.6.2.7  ID_IPV6_ADDR_SUBNET
这个ID_IPV6_ADDR_SUBNET类型详细说明Ipv6地址的排列，它被描绘为两个16位的八位位组的值。第一个值是一个Ipv6的地址。第二个值是Ipv6的网络面具。特别注意网络面具中的ones（1s）指示地址中的相应位被固定，而zeros(0s)指示一个通配符位。
4.6.2.8  ID_IPV4_ADDR_RANGE
这个ID_IPV4_ADDR_RANGE类型详细说明一个IPV4地址的排列，它表现为两个四位的八位位组值。第一个值开始于Ipv4地址，第二值结束于IPV4的地址。在两个指定地址中的所有地址被认为在这个列表之中。
4.6.2.9  ID_IPV6_ADDR_RANGE
这个ID_IPV6_ADDR_RANGE 类型详细说明Ipv6地址的排列，它表现为两个16位的八位位组值。第一个值开始于IPV6地地址，第二个值结束IPV6地址。在两个指定地址中的所有地址被认为在这个列表之中。
4.6.2.10 ID_DER_ASN1_DN
这个ID_DER_ASN1_DN类型详细说明二进制的DER，它是以ASN.1 X.500来编码的，它的证书被交换来建立这个SA.
4.6.2.11 ID_DER_ASN1_GN
这个4.6.2.11 ID_DER_ASN1_GN类型详细说明二进制的DER，它是以ASN.1 X.500来编码的，它的证书被交换来建立SA。
4.6.2.12 ID_KEY_ID
这个ID_KEY_ID类型详细说明不透明的字节流，它可能被用来通过指定必须的的卖主信息来鉴别哪一个共享的密钥应被用来鉴别侵权的谈判模式。
4.6.3 IPSEC通报信息类型
ISAKMP定义两块通报信息代码，一个是错误的，另一个是状态信息。ISAKMP也分配每块中的一部分在DOL里作为私有用途。这个IPSEC  DOI为自己的用途定义下列私有信息。
       通报信息 - 错误类型       值
       -----------------------------       -----
       保留的                            8192

       通报信息 - 状态类型      值
       ------------------------------      -----
       RESPONDER-LIFETIME                  24576
       REPLAY-STATUS                       24577
       INITIAL-CONTACT                     24578

通知状态信息MUST送到ISAKMP SA的保护下：在最后主要交换模式里任何一个作为有效载荷；在主要模式下的分离的信息交换或侵权的模式过程是完成的；或在任何快的模式交换里作为有效载荷。这些信息不应该被送到侵权的模式交换中，因为侵权模式不提供必须的保护来约束通报状态信息交换。
特别注意：一个通报的有效载荷仅仅在快的模式下被完全保护，在那儿整个有效载荷被包含在HASH（n）分类中。在主要模式立，当通报信息被加密了，它不是普遍的包含在这个HASH(n)分类历。结果，在主模式密文里，一个积极的攻击能引起通报信息类型被改动。（这是真的，一般的，对于任何主模式交换里的最后的信息）当这个风险很小时，一个跟改过的通报信息可能引起接收者中断整个谈判，他想到发送者遇到了一个致命的错误。
4.6.3.1  RESPONDER-LIFETIME
这个RESPONDER-LIFETIME状态信息可能被用来协调由接受者选择的IPSEC SA lifetime。
当它存在时，通报有效载荷应该有下列格式：
   。有效载荷长度－发送有效载荷的长度＋数据大小（var）
   。DOI-发送到IPSEC DOI(1)
   。ID协议－从选择的SA发送到选择的协议ID
   。SPI大小-发送16（两个eight-octet ISAKMP cookies)或4（一个IPSEC SPI）
   。通报信息类型－发动RESPONDER-LIFETIME (Section 4.6.3)
   。SPI-发送两个ISAKMP cookies或者道发送者的IPSEC SPI
   。告示数据－包含一个ISAKMP属性列表,这个列表带有回答者实际的SA lifetime(s)
执行时注意：通知数据领域包含一个属性列表，它说明通知数据域有零长度并且通报有效载荷有相连的属性列表。
4.6.3.2  REPLAY-STATUS
这个REPLAY-STATUS状态信息可能被用来对接受者的选择作肯定证实，看他是否实现anti-replay的发现。
当它出现时，这个通知有效载荷应该有下列格式：
   o  有效载荷长度 - 设定有效载荷的长度+ 数据的大小( 4 ）
   o   DOI - 设定到 IPSEC  DOI ( 1 ）
   o  协议 ID - 从选择的 SA 选择了协议 ID集合
   o   SPI 大小 - 设定到任何一个 16 ( 16 )( 2 个 8 字节ISAKMP cookies) 或 4 ( 4 )( 一 IPSEC  SPI )
   o  通知消息类型 - 到 REPLAY-STATUS 的集合
   o   SPI - 设定到 2 个 ISAKMP cookies或到发送者的入站IPSEC  SPI
   o  通知数据 - 4 字节值：
          0 = 不可重放探测
          1 = 启用重放探测
4.6.3.3  INITIAL-CONTACT
   当一个方面希望通知其它方这是这是同遥远系统建立的第一个 SA 时， INITIAL-CONTACT 状态消息可以被使用。这条通知消息的接收装置然后可能选择删除任何存在的 Sa ，它在传送系统时重新启动，并且假设不再为传送系统的原有 Sa存取与他们联系的密钥材料。当使用时，通知数据域的内容应该为空( 即有效载荷长度应该被设置为被通知有效载荷的固定长度 ) 。

   当前，通知有效载荷必须有下列格式：

     o  有效载荷长度 - 设定有效载荷的长度 + 数据的大小( 0）
     o   DOI - 设定到 IPSEC  DOI ( 1 ）
     o  协议 ID - 从选择的 SA 选择了协议 ID 集合
     o   SPI 大小 - 设定到 16 ( 16 )( 2 个 8 字节ISAKMP cookies)
     o  通知消息类型 - 到 INITIAL-CONTACT 的集合
     o   SPI - 设定到 2 个 ISAKMP cookies
     o  通知数据 -<不被包括>
4.7  IPSEC 密钥交换要求
    IPSEC  DOI 不介绍附加的密钥交换类型。
5．安全考虑
整个备忘录属于因特网密钥交换协议（IKE）, 它以一种安全的并且好鉴定的方式，联合ISAKMP([ISAKMP])和[OAKLEY]来提供密钥材料来源。各种各样的安全协议和文件中转换鉴别的特别讨论能在相关的基础文件和密码参考书目中找到。
6．IANA 需要考虑的事项
这个文件包含一些需要IANA来维持的“魔法”数字。这个章节解释由IANA来使用的标准，用这个标准在每一个这些列表中分配附加数字。在前面章节中没有明确说明的所有值对IANA来说是保留的。
6.1 IPSEC位置定义
 这个位置定义是一个32位bitmask，它描绘IPSEC SA的建议和商谈被实现的环境。请求分配新位置应该由一个RFC来完成，这个RFC由关联位来解释。
如果这个RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和转化标识符被指派之前被明确的回复或被IESG认可。
这个上层的两位在合作系统中被保留用作私有用途。
6.2 IPSEC 安全协议标识符
这个安全协议标识符适合一个8位值，它标识一个正需要讨论的安全协议 。请求分配一个新的安全协议标识符应该由一个RFC来实现，它描叙了这个需要的安全协议。[AH]和[ESP]是这个安全协议文件中的例子。
如果这个RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在这个RFC被公开和这个转化被指岀之前明确的评论和由IESG来认可。
这些值249-255在合作系统中被保留作为私有用途。
6.3 IPSEC ISAKMP 转移标志符
这个IPSEC ISAKMP 转移标志符是一个8位的值，它标识一个用来流通的密钥交换协议。
请求分配新的ISAKMP转移标志符应该由RFC来完成，它描叙这个需要的密钥交换协议。[IKE]是一个这种文件中的例子。
如果RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前明确的指出和通过IESG来证实。
在合作系统中保留249－255这些值作为私有用途来使用。
6.4 IPDEC AH 转移标识符
这个IPSEC AH 转移标识符是一个8位值，它鉴别一个特定的算法法则来为AH提供完整保护。请求分配一个新的AH 转移标识符应该由一个RFC来协助完成。这个RFC描绘了怎样在AH框架中用这个运算法则。
如果这个RFC不是在这个标准轨迹上（也就是说,它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
在合作系统中保留这些值249－255来作为私有用途。
6.5 IPSEC ESP转移标识符
这个IPSEC ESP转移标识符是一个8位的值，它鉴别一个特定的运算法则用来为ESP提供一个秘密保护。请求分配一个新的ESP转移标识符应该由RFC来协作完成。这个RFC描叙了在ESP框架中怎样用这个算法.
如果这个RFC不在这个标准轨迹上（也就是说，它不是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
在合作系统中保留这些值249－255来作为私有用途。
6.6 IPSEC IPCOMP 转移标识符
这个IPSEC IPCOMP转移标识符是一个8位的值，在ESP之前它标识一个特定的运算法则用来提供IP层压缩。请求分配一个新的IPCOMP转移标识符应该由一个RFC来协作完成，它描叙了在IPCOMP框架（[IPCOMP]）中怎样使用运算法则。另外，这个需要的运算法则应该被公开，并且在公共范围内。
如果这个RFC不在这个标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
因为RFC已被批准出版，这些值1－47就用来保存作运算法则。在合作系统中这些值48－63被保留作为私有用途。这些值64－255被保留作为将来扩展。
6.7 IPSEC安全相连属性
这个IPSEC安全相连属性由16位类型和其相连的值组成。OPSEC SA 属性用来在ISAKMP之间传递各种各样的值。请求分配一个新的OPSEC  SA属性应该由因特网草案来完成。它描叙了属性代码（基础的/可变长度的）和它的合法值。这个文档中的第4.5章提供了一个这样描叙的例子。
在合作系统中这些值32001－32767被保留作为私有用途。
6.8 IPSEC 标签范围标识符
IPSEC 标签范围标识符是一个32位的值，它鉴别一个namespace，在namespace里秘密层，完整层和各种值都存在。请求分配一个新的OPSEC标签范围标识符应该得到满足。不需要合作文件，尽管在适当的时候因特网草案可以得到鼓励。
在合作系统中这些值0x80000000-0xffffffff被保留作为私有用途。
6.9 IPSEC 标识符类型
这个IPSEC标识符类型是一个8 位的值，它被用来作为一个解释各种长度有效载荷的判别式。请求分配新的OPSEC鉴定类型应该由RFC来完成，它描叙了在OPSEC里怎样使用这个鉴定。
如果RFC不是在标准轨迹上（也就是说，它是一个报告的或实验的RFC），在RFC被公开和这个转移标识符被分配之前，它应该明确的指出和由IESG来证实。
在合作系统中这些值249－255被保留作为私有用途。
6.10 OPSEC通报信息类型 
OPSEC 通报信息类型是一个16位的值。这个值来自ISAKMP为每个DOL保留的值的变化。有一个错误信息的变动（8192－16383）和一个不同的状态信息的变动（24576－32767）。请求分配新的通报信息类型应该由因特网草案来实现，在IPSEC里它描叙了怎样用这个鉴定类型。
在合作系统中这些值16001－16383 和这些值32001－32767 被保留作为私有用途。

7．改变Log
7.1 从V9中改变
 。为[IPCOMP], [DEFLATE], 和[LZS]增加明显的参考书目。
 。因为ISAKMP "SPI"，允许RESPONDER-LIFETIME 和REPLAY-STATUS在IPSEC SPI 中直接指出。
 。附加的填料排除秘密和完整地长度正文。
 。可以向前参考第4.5章和第4.4.4章。
 。更新文件参考书目。

7.2 从V8 中改变
 。更新IPCOMP标识符变化来更好地反映OPCOMP 草案。
 。更新IANA考虑的每个Jeff/Ted's暗示的正文。
 。除去DES-MAC ID ([DESMAC])的参考书目。
 。更正通报章节中的bug；ISAKMP通报值是16位的。
  
7.3 从V7 中变化
 。更正IPCOMP (IP 有效载荷压缩)的名字。
 。更正[ESPCBC]的参考书目。
 。在图1中附加不可见的秘密层和完整层。
 。移出涉及到PF_KEY和ARCFOUR的ID。
 。更新基础的/ 各种各样的正文来排列[IKE].
 。更新参考文件并且为[ARCH] 增加引子指示。
 。更新通知需求；移出一些侵权的参考书目。
 。额外的澄清对通报有效载荷的保护。
 。恢复RESERVED到ESP 转移ID的位置；移出ESP_NULL.
 。额外需要ESP_NULL的支持和[ESPNULL]的参考。
 。附加的用AH/ESP来澄清Auth Alg。
 。附加的约束来反对用冲突的AH/Auth联合体。
 
7.4 从V6 中改变
 下列这些改变是相对于IPSEC DOI V6的。
。附加IANA需要考虑的章节
。移出多数IANA数到IANA需要考虑的章节。
。附加禁止发送(V)代码属性（B）.
。附加禁止为固定的长度的密码(例如DES)发送密钥长度属性.
。用IKE取代涉及到ISAKMP/Oakley的参考书目。
。从ESP_ARCFOUR 到 ESP_RC4进行重命名。
。更新安全考虑章节。
。更新文档参考书目。

7.5 从V5中变化
 下列变化与IPSEC DOI V5有关系：
 。在通知正文中改变SPI的大小
 。改变REPLAY-ENABLED 到 REPLAY-STATUS
 。从第4.5.4章到第4.6.3.1章中移动RESPONDER-LIFETIME 有效载荷的定义
 。为第4.6.3.3章附加明确的有效载荷规划
 。附加执行记录到第4.6.3章中的介绍
 。如果MD5成立，改变AH_SHA 正文到需要的SHA-1
 。更新文档参考书目

7.6 从V4中的变化
下列变化与IPSEC DOI V4有关：
 。从AH转移ID到鉴定算法标识符中移动具有兼容性的AH KPDK的鉴定方法
 。每一个结构附加REPLAY-ENABLED通知信息类型
 。每个列表附加INITIAL-CONTACT通知信息类型
 。附加内容来确信保护通报状态信息
 。附加属性解析章节永久资格
 。附加地澄清永久通知是任选的
 。移开私有团体描叙列表（现在指向[IKE]）
 。用指向RFC-2119的指针来取代这个术语
 。更新HMAC MD5 和 SHA-1 ID参考书目
 。更新章节1（抽象的）
 。更新章节4.4 （IPSEC 分配的数）
 。在第一个阶段附加ID端口/协议值的约束
  
7.7 从V3 到V4的变化
 下列变化与IPSEC DOI V3 有关，这个对IPSEC邮寄优于MUNICH IETF 的列表来说是很有用的：
 。为空和ARCFOUR附加转移标识符
 。重新命名HMAC运算法则到AUTH运算法则来进行协调DES-MAC和ESP可选的鉴定/完整性
 。附加AH 和ESP DES-MAC 运算法则标识符
 。移动DEY_MANUAL和KEY_KDC标识符定义
 。附加永久MUST随从属性到SA类型和SA属性定义
 。附加永久通知何IPSEC DOI 信息类型表格
 。附加可选的鉴定和机密性约束到MAC 运算法则属性定义
 。更正属性解析例子（习惯的过时的属性）
 。更正多个因特网草案文件参考书目
 。对每个ipsec 列表讨论（18－Mar－97）附加ID_KEY _ID 
 。为PFS QM ([IKE] MUST)移动默认团体描叙

致谢
这个文件部分起源于以下人的工作：Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,和 Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, 和 Ran Atkinson在很多种案例和正文中也提出了他们的建议。
参考书目
   [AH]      Kent, S., and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

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

   [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
             2394, August 1998.

   [ESP]     Kent, S., and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

   [ESPCBC]  Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
             Algorithms", RFC 2451, November 1998.

   [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
             Its Use With IPsec", RFC 2410, November 1998.

   [DES]     Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
             Algorithm With Explicit IV", RFC 2405, November 1998.

   [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
             and AH", RFC 2403, November 1998.

[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
             ESP and AH", RFC 2404, November 1998.

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

   [IPCOMP]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
             Payload Compression Protocol (IPComp)", RFC 2393, August
             1998.

   [ISAKMP]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

   [LZS]     Friend, R., and R. Monsour, "IP Payload Compression Using
             LZS", RFC 2395, August 1998.

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

   [X.501]   ISO/IEC 9594-2, "Information Technology - Open Systems
             Interconnection - The Directory:  Models", CCITT/ITU
             Recommendation X.501, 1993.

   [X.509]   ISO/IEC 9594-8, "Information Technology - Open Systems
             Interconnection - The Directory:  Authentication
             Framework", CCITT/ITU Recommendation X.509, 1993.

Author's Address

   Derrell Piper
   Network Alchemy
   1521.5 Pacific Ave
   Santa Cruz, California, 95060
   United States of America

   Phone: +1 408 460-3822
   EMail: ddp@network-alchemy.com

全部版权陈述
 版权（C）因特网社会（1998）。版权所有
这个文章和它的翻译可能被复制和提供给别人，并且引出一些评论或者解释它或援助它执行可能被准备，拷贝，出版和分配，不管是整体的还是局部的，没有任何限制，提供这上面的版权告示和包含所有拷贝和起源工作的章节。但是，这个文章它自己本身不能以任何方式修改，例如通过移走版权告示或因特网团体或别的因特网组织的参考书目，除了发展因特网标准的需要，在这种情况下，定义在因特网标准过程中的版权程序应该要有，或者需要翻译成不同于英语的别的语言。
这个受限的许可同意以上的声明是永久的，并且它将不会被因特网团体或它的继任者或设计者废除。
包含在这儿的这个文件和通知作为一个基础来提供。
这个因特网团体和这个因特网工程任务迫使它宣布所有的授权，表达或隐含，包括但是不限制任何授权，在这儿信息的用途不破坏任何权利或任何隐含的购买授权或一个特别的目的。
RFC 2407  The Internet Key Exchange (IKE)                                         因特网交换密钥

第 1 页