1.摘要
因特网安全关联和关密钥的治理协议(ISAKMP)为因特网安全关联治理和密钥建立定义一个框架。这个框架由定义了的交换，有效负载，和在给定解释域(DOI)以内发生的处理指南组成。这个文件定义因特网IP安全DOI(IPSECDOI),它用具体例子说明IP适合同ISAKMP一起使用,当IP使用ISAKMP商定安全关联。
关于IPSECDOI的先前版本的变化的列表，请见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.术语和定义
要害词必须,不能,要求,将,将不,应该,应该不,推荐,可能和可选,当他们再文档中出现时,被解释成如[RFC2119]所描述的。
4．IPSEC
4.1IPSEC命名方案
在ISAKMP以内，所有的Doi的必须在“分配的数字”RFC[STD-2]内同IANA一起被登记。IANA为因特网IP安全DOI(IPSECDOI)分配的数字是一个(1)。在IPSECDOI以内，所有闻名的标识符必须在IPSECDOI下面与IANA一起被登记。除非另外注明,在这个文件以内的所有表参考为IPSECDOI而被分配数字的IANA。对于IPSECDOI联系到IANA注册表的进一步的信息,见节6。
所有的多字节二进制代码值在网络字节顺序被存储。
4.2IPSEC状况定义
在ISAKMP以内，状况提供能被响应者用来作出一条关于怎么处理到来的安全关联信息请求策略的决定。对于IPSECDOI，状况域是一个有下列值的4字节位掩码。
状况 值
--------------
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
4.2.1SIT_IDENTITY_ONLY
SIT_IDENTITY_ONLY类型指定,安全关联将被在联系的鉴定有效负载中提供的源身份信息所标记。对于各种各样的鉴定的完全描述见节4.6.2。所有的IPSECDOI实现必须支持SIT_IDENTITY_ONLY,由在至少一次阶段IOakley交换中包含鉴定有效负载([IKE],节5),并且必须放弃任何不包括鉴定的安装有效负载关联。
假如一个开始者既不支持SIT_SECRECY也不支持SIT_INTEGRITY，状况仅仅由4字节状况位图组成并且不包括标记的域标识符域(图1,节4.6.1)或任何随后的标签信息。相反的,假如开始者支持SIT_SECRECY或SIT_INTEGRITY，标记的域标识符必须在状况有效负载时被包括。
4.2.2SIT_SECRECY
SIT_SECRECY类型指定安全关联在要求标记秘密的环境中正被商议。假如SIT_SECRECY在状况位图中出现，状况域将被变量长度数据跟随,他们包括敏感级别和分隔空间位掩码。关于安全关联有效负载格式的完全的描述,见节4.6.1。
假如一个开始者不支持SIT_SECRECY，SIT_SECRECY状况位图不能被设置并且秘密级别或范畴位图将被包括。
假如一个应答者不支持SIT_SECRECY，环境不支持的标志信息有效负载应该被返回并且安全关联安装必须被放弃。
4.2.3SIT_INTEGRITY
SIT_INTEGRITY类型指定安全关联在要求标记完整性的环境中正被商议。假如SIT_INTEGRITY在状况位图中出现，状况域将被变量长度数据跟随,他们包括完整级别和分隔空间位掩码。假如SIT_SECRECY也用于关联,完整信息立即遵从变长秘密级别和类别。关于安全关联有效负载格式的完全的描述,见节4.6.1。
假如一个开始者不支持SIT_INTEGRITY，SIT_INTEGRITY状况位图不能被设置并且无完整性级别或范畴位图将被包括。
假如一个应答者不支持SIT_INTEGRITY，环境不支持的标志信息有效负载应该被返回并且安全关联安装必须被放弃。
4.3IPSEC安全策略要求
IPSECDOI不在任何实现上强加特定的安全策略要求。主机系统策略问题将在这个文件的范围以外。
然而,当设计一个IPSECDOI主机实现时，在下面的章节涉及的一些问题必须被考虑。这节自然应该被认为仅仅参考。
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.4IPSEC分配数
下列节为IPSECDOI列出分配的数字：状况标识符,协议标识符,转变标识符，AH，ESP，并且IPCOMP转变标识符,安全协会属性类型值,标记的域标识符，ID有效负载类型值，和通知消息类型值。
4.4.1IPSEC安全协议标识符
ISAKMP建议句法被特定的设计来答应多重的阶段II安全协议的同时协商在一个单个的协商内适用。作为结果，下面被列出了的协议组形成了能同时被协商的协议集合。它是决定什么协议能被协商在一起的一个主机策略决定。
下列表为IPSECDOI而在ISAKMP建议有效负载中引用的安全协议标识符列出值的。
协议ID 值
----------- -----
保留 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
4.4.1.1PROTO_ISAKMP
PROTO_ISAKMP类型指定在阶段I的ISAKMP协议期间要求的消息保护。在IPSECDOI中被使用的特定的保护机制在[IKE]中被描述。在IPSECDOI以内的所有的实现必须支持PROTO_ISAKMP。
NB：ISAKMP保留该值一(1),越过所有的DOI定义。
4.4.1.2PROTO_IPSEC_AH
PROTO_IPSEC_AH类型指定IP包认证。缺省AH转变提供数据起源认证,完整保护,和重放探测。对于出口控制考虑，机密不能被任何PROTO_IPSEC_AH转变所提供。
4.4.1.3PROTO_IPSEC_ESP
PROTO_IPSEC_ESP类型指定IP包机密。假如要求认证，必须作为ESP的部分被提供转变。缺省ESP转变包括数据起源认证,完整保护,重放探测,和机密性。
4.4.1.4PROTO_IPCOMP
如在[IPCOMP]里面定义的,PROTO_IPCOMP类型指定IP有效负载压缩。
4.4.2IPSECISAKMP转变标识符
作为一个ISAKMP阶段I协商的部分,开始者的密钥的交换提供的选择被用来作一些主机系统策略描述。实际的密钥交换机制选择被用来做标准的ISAKMP建议有效负载。下列表格列出对于IPSECDOI的为建议有效负载定义的ISAKMP阶段I转变标识符。
转变 值
--------- -----
保留 0
KEY_IKE 1
在ISAKMP和IPSECDOI框架内除IKE(Oakley)以外定义密钥的建立协议，是可能的。这个文件的先前版本定义了基于一个通用密钥的分发中心(KDC)的使用的手工密钥和计划。这些标识符从当前的文件被移走了。
IPSECDOI还能在以后被扩大到为附加的non-Oakley密钥建立协议包括关于ISAKMP和IPSEC的值,例如Kerberos[RFC-1510]或组密钥治理协议(GKMP)[RFC-2093]。
4.4.2.1KEY_IKE
KEY_IKE类型指定混合的ISAKMP/OakleyDiffie-Hellman密钥的交换(IKE),如在[IKE]文件定义。在IPSECDOI以内的所有的实现必须支持KEY_IKE。
4.4.3IPSECAH转变标识符
认证头协议(AH)定义一个强制的和若干可选的转变用于提供认证,完整性,和重放探测。下列表列出定义的AH转变标识符为IPSECDOI的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.1AH_MD5
AH_MD5类型指定使用MD5的通用AH转变。实际的保护组被决定与SA联系表一致。通用的MD5转变当前未定义。
在IPSECDOI内的所有的实现必须与Auth一起支持AH_MD5(HMAC-MD5)属性。这组被定义为HMAC-MD5-96转变,如在[HMACMD5]中描述的。
与Auth一起的AH_MD5类型(KPDK)属性指定了AH转变(密钥/垫/数据/密钥)描述在RFC-1826。
有任何另外的认证算法的AH_MD5的使用属性值当前未定义。
4.4.3.2AH_SHA
AH_SHA类型指定使用SHA-1的通用AH转变。实际的保护组决定为与联系的SA属性表一致。通用的SHA转变当前未定义。
在IPSECDOI以内的所有的实现必须与Auth一起支持AH_SHA(HMAC-SHA)属性。这组被定义为描述在[HMACSHA]中的HMAC-SHA-1-96转变。
与任何另外的认证算法属性值一起使用的AH_SHA当前未定义。
4.4.3.3AH_DES
AH_DES类型指定使用DES的通用AH转变。实际的保护组决定为与联系的SA属性表一致。通用的DES转变当前未定义。
IPSECDOI定义AH_DES和Auth(DES-MAC)属性为DES-MAC转变。实现不需要支持这种模式.
与任何另外的认证算法属性值一起使用的AH_DES当前未定义。
4.4.4IPSECESP转变标识符
包含的安全有效负载(ESP)定义一个强制的和用于常提供数据机密可选的许多转变。下列表格列出定义的对于IPSECDOI为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.1ESP_DES_IV64
ESP_DES_IV64类型指定定义在RFC-1827和使用一个64比特IV中的RFC-1829DES-CBC转变
4.4.4.2ESP_DES
ESP_DES类型指定使用DES-CBC的一个通用的DES转变。实际的保护组定义得与SA属性表一致。一个通用转变当前未定义。
在IPSECDOI内的所有实现必须与Auth(HMAC-MD5)一起支持ESP_DES属性。这组被定义为[DES]转变,由HMACMD5[HMACMD5]提供认证和完整性了。
4.4.4.3ESP_3DES
ESP_3DES类型指定一个通用的triple-DES转变。实际的保护组定义得与SA属性表一致。通用转变当前未定义。
在IPSECDOI内的所有的实现强烈支持ESP_3DES和Auth(HMAC-MD5)属性。这组被定义为[ESPCBC]转变,由HMACMD5[HMACMD5]提供认证和完整性。
4.4.4.4ESP_RC5
ESP_RC5类型指定定义在[ESPCBC]RC5的转变。
4.4.4.5ESP_IDEA
ESP_IDEA类型指定定义在[ESPCBC]的IDEA转变。
4.4.4.6ESP_CAST
ESP_CAST类型指定定义在[ESPCBC]的CAST转变。
4.4.4.7ESP_BLOWFISH
ESP_BLOWFISH类型指定定义在[ESPCBC]的BLOWFISH转变。
4.4.4.8ESP_3IDEA
ESP_3IDEA类型为triple-IDEA保留。
4.4.4.9ESP_DES_IV32
ESP_DES_IV32类型指定定义在RFC-1827和使用一32位的IV的RFC-1829的DES-CBC转变。
4.4.4.10ESP_RC4
ESP_RC4类型为RC4保留。
4.4.4.11ESP_NULL
ESP_NULL类型没有指定任何机密被ESP提供。当ESP被用于仅仅要求认证,完整性,和重放探测的通道包时，ESP_NULL被使用。
在IPSECDOI内的所有实现必须支持ESP_NULL。ESPNULL转变在[ESPNULL]中被定义。为得到关联ESP_NULL使用的附加要求,见节4.5认证算法属性描述。
4.4.5IPSECIPCOMP转变标识符
IP压缩(IPCOMP)转变定义了能被协商为IP有效负载压缩([IPCOMP])所提供的可选压缩算法。下列表列出已定义的IPCOMP内,为ISAKMP建议有效负载转变标识符
IPSECDOI
转变ID 值
------------ -----
保留 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
4.4.5.1IPCOMP_OUI
IPCOMP_OUI类型指定专利的压缩转变。IPCOMP_OUI类型必须由进一步认明特定供给商算法的属性伴随。
4.4.5.2IPCOMP_DEFLATE
IPCOMP_DEFLATE类型指定“zlib”缩小算法的使用如在[降低]中指定。
4.4.5.3IPCOMP_LZS
IPCOMP_LZS类型指定Stac电子学LZS算法的使用如在[LZS]中指定的。
4.5IPSEC安全关联属性
下列SA属性定义被使用在一个IKE协商的相II。属性类型可以是基本(B)或可变的长度(V)。这些属性编码被定义在基层的ISAKMP说明中。
描述为基本的属性不能被编码为变量。假如他们的值适合在两个字节中，可变的长度属性可以被编码为基本属性。属性上关于IPSECDOI的进一步信息编码见[IKE]。列出在[IKE]的所有限制也适用于IPSECDOI。
属性类型
类 值 类型
-------------------------------------------------
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。
组描述
指定在一个PFSQM协商被使用的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分析要求的属性(一生)
答应灵活的语义,IPSECDOI要求一个遵守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属性协商
假如实现收到一个它不支持的定义了的IPSECDOI属性(或属性值),一个ATTRIBUTES-NOT-SUPPORT应该被发送并且安全关联安装必须被放弃的，除非属性值在保留的范围内。
假如实现在保留范围收到属性值，实现可能选择继续基于本地的策略。
4.5.4一生通知
当一个开始者提供比应答者基于他们的本地的策略所需的大的SA一生时，应答者有3种选择：1)协商全部失败;2)完成协商但是使用比被提供的更短的一生;3)完成协商并且送一份建议通知到显示应答者真实一生的开始者。应答者实际上做的选择是实现特定的或基于本地的策略。
在后者情况中保证互操作性,当应答者希望通知开始者时，IPSECDOI仅仅要求下列：假如开始者提供的SA一生与应答者愿意接受的长，应答者应该在包括应答者IPSECSA有效负载的交换包括ISAKMP通知的有效负载。节4.6.3.1为必须被用于这个目的消息类型的RESPONDER-LIFETIME通知定义有效负载布局。
4.6IPSEC有效负载内容
下列节描述其数据表示依靠于适用的DOI的那些ISAKMP有效负载。
4.6.1安全关联有效负载
下列图表为IPSECDOI说明安全关联有效负载的内容。对于状况位图的描述见节4.2。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一个有效负载！保留！有效负载长度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！解释的域(IPSEC）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！状况(位图）！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！标记的域标识符！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密长度(在字节）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密级别
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！秘密连接。长度(在位中)！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~秘密范畴位图~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！完整长度(在字节）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整级别
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！Integ。连接。长度(按位）！保留！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~完整范畴位图~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图1：安全关联有效负载格式
安全关联有效负载被定义如下：
o下一个有效负载(1字节)在消息中的下一个有效负载的有效负载类型标识符。假如当前的有效负载是在消息的最后，这域将是零(0)。
o保留(1字节)-闲置,必须是零(0)。
o有效负载长度(2字节)-长度,字节，当前的有效负载，包括通用的头。
o解释的域(4字节)-指定IPSECDOI,它被分配了值一(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.1IPSEC标记了的域标识符
下列表列出标记域标识符域的分配的值,它被包含在关联有效负载的安全状况域中。
域 值
------ -----
保留 0
4.6.2鉴定有效负载内容
鉴定有效负载被用来认明安全关联的开始者。开始者的身份应该被应答者使用来决定关联要求的正确主机系统安全策略。例如,一台主机可能选择没有要求从某个集合IP地址机密认证和完整性,和另一范围IP地址地完全机密性认证。鉴定有效负载提供能被应答者用来作出决定的信息。
在阶段期I协商期间，ID端口和协议域必须被设置为零或上到500的UDP。假如实现收到任何另外的值，这必须被当作一个错误并且安安全关联装必须被放弃。这个事件应该是auditable。
下列图表说明鉴定有效负载的内容。
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！下一个有效负载！保留！有效负载长度！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！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.2ID_IPV4_ADDR
ID_IPV4_ADDR类型指定单个4(4)字节的IPv4地址。
4.6.2.3ID_FQDN
ID_FQDN类型指定一个完全合格的域名字符串。一个ID_FQDN例子是，“foo.bar.com”。字符串不能包含任何终止符。
4.6.2.4ID_USER_FQDN
这个ID_USER_FQDN类型指定一个有很高权限的用户名字符串，ID_USER_FQDN的一个例子是"piper@foo.bar.com".这个字符串不应该包含任何界限。
4.6.2.5ID_IPV4_ADDR_SUBNET
这个ID_IPV4_ADDR_SUBNET类型具体说明IPV4地址的排列，它表现为两个四位的八位位组值。第一个值是IPV4的地址。第二个值是IPV4的网络面具。非凡注重这个网络面具中的ones(1s)指示的相应的位被固定，而zeros(0s)指示一个通配符位。
4.6.2.6ID_IPV6_ADDR
这个ID_IPV6_ADDR类型指定一个单一的16位八位位组Ipv6地址。
4.6.2.7ID_IPV6_ADDR_SUBNET
这个ID_IPV6_ADDR_SUBNET类型具体说明Ipv6地址的排列，它被描绘为两个16位的八位位组的值。第一个值是一个Ipv6的地址。第二个值是Ipv6的网络面具。非凡注重网络面具中的ones（1s）指示地址中的相应位被固定，而zeros(0s)指示一个通配符位。
4.6.2.8ID_IPV4_ADDR_RANGE
这个ID_IPV4_ADDR_RANGE类型具体说明一个IPV4地址的排列，它表现为两个四位的八位位组值。第一个值开始于Ipv4地址，第二值结束于IPV4的地址。在两个指定地址中的所有地址被认为在这个列表之中。
4.6.2.9ID_IPV6_ADDR_RANGE
这个ID_IPV6_ADDR_RANGE类型具体说明Ipv6地址的排列，它表现为两个16位的八位位组值。第一个值开始于IPV6地地址，第二个值结束IPV6地址。在两个指定地址中的所有地址被认为在这个列表之中。
4.6.2.10ID_DER_ASN1_DN
这个ID_DER_ASN1_DN类型具体说明二进制的DER，它是以ASN.1X.500来编码的，它的证书被交换来建立这个SA.
4.6.2.11ID_DER_ASN1_GN
这个4.6.2.11ID_DER_ASN1_GN类型具体说明二进制的DER，它是以ASN.1X.500来编码的，它的证书被交换来建立SA。
4.6.2.12ID_KEY_ID
这个ID_KEY_ID类型具体说明不透明的字节流，它可能被用来通过指定必须的的卖主信息来鉴别哪一个共享的密钥应被用来鉴别侵权的谈判模式。
4.6.3IPSEC通报信息类型
ISAKMP定义两块通报信息代码，一个是错误的，另一个是状态信息。ISAKMP也分配每块中的一部分在DOL里作为私有用途。这个IPSECDOI为自己的用途定义下列私有信息。
通报信息-错误类型值
----------------------------------
保留的8192
通报信息-状态类型值
-----------------------------------
RESPONDER-LIFETIME24576
REPLAY-STATUS24577
INITIAL-CONTACT24578
通知状态信息MUST送到ISAKMPSA的保护下：在最后主要交换模式里任何一个作为有效载荷；在主要模式下的分离的信息交换或侵权的模式过程是完成的；或在任何快的模式交换里作为有效载荷。这些信息不应该被送到侵权的模式交换中，因为侵权模式不提供必须的保护来约束通报状态信息交换。
非凡注重：一个通报的有效载荷仅仅在快的模式下被完全保护，在那儿整个有效载荷被包含在HASH（n）分类中。在主要模式立，当通报信息被加密了，它不是普遍的包含在这个HASH(n)分类历。结果，在主模式密文里，一个积极的攻击能引起通报信息类型被改动。（这是真的，一般的，对于任何主模式交换里的最后的信息）当这个风险很小时，一个跟改过的通报信息可能引起接收者中断整个谈判，他想到发送者碰到了一个致命的错误。
4.6.3.1RESPONDER-LIFETIME
这个RESPONDER-LIFETIME状态信息可能被用来协调由接受者选择的IPSECSAlifetime。
当它存在时，通报有效载荷应该有下列格式：
。有效载荷长度－发送有效载荷的长度＋数据大小（var）
。DOI-发送到IPSECDOI(1)
。ID协议－从选择的SA发送到选择的协议ID
。SPI大小-发送16（两个eight-octetISAKMPcookies)或4（一个IPSECSPI）
。通报信息类型－发动RESPONDER-LIFETIME(Section4.6.3)
。SPI-发送两个ISAKMPcookies或者道发送者的IPSECSPI
。告示数据－包含一个ISAKMP属性列表,这个列表带有回答者实际的SAlifetime(s)
执行时注重：通知数据领域包含一个属性列表，它说明通知数据域有零长度并且通报有效载荷有相连的属性列表。
4.6.3.2REPLAY-STATUS
这个REPLAY-STATUS状态信息可能被用来对接受者的选择作肯定证实，看他是否实现anti-replay的发现。
当它出现时，这个通知有效载荷应该有下列格式：
o有效载荷长度-设定有效载荷的长度+数据的大小(4）
oDOI-设定到IPSECDOI(1）
o协议ID-从选择的SA选择了协议ID集合
oSPI大小-设定到任何一个16(16)(2个8字节ISAKMPcookies)或4(4)(一IPSECSPI)
o通知消息类型-到REPLAY-STATUS的集合
oSPI-设定到2个ISAKMPcookies或到发送者的入站IPSECSPI
o通知数据-4字节值：
0=不可重放探测
1=启用重放探测
4.6.3.3INITIAL-CONTACT
当一个方面希望通知其它方这是这是同遥远系统建立的第一个SA时，INITIAL-CONTACT状态消息可以被使用。这条通知消息的接收装置然后可能选择删除任何存在的Sa，它在传送系统时重新启动，并且假设不再为传送系统的原有Sa存取与他们联系的密钥材料。当使用时，通知数据域的内容应该为空(即有效载荷长度应该被设置为被通知有效载荷的固定长度)。
当前，通知有效载荷必须有下列格式：
o有效载荷长度-设定有效载荷的长度+数据的大小(0）
oDOI-设定到IPSECDOI(1）
o协议ID-从选择的SA选择了协议ID集合
oSPI大小-设定到16(16)(2个8字节ISAKMPcookies)
o通知消息类型-到INITIAL-CONTACT的集合
oSPI-设定到2个ISAKMPcookies
o通知数据-<不被包括>
4.7IPSEC密钥交换要求
IPSECDOI不介绍附加的密钥交换类型。
5．安全考虑
整个备忘录属于因特网密钥交换协议（IKE）,它以一种安全的并且好鉴定的方式，联合ISAKMP([ISAKMP])和[OAKLEY]来提供密钥材料来源。各种各样的安全协议和文件中转换鉴别的非凡讨论能在相关的基础文件和密码参考书目中找到。
6．IANA需要考虑的事项
这个文件包含一些需要IANA来维持的“魔法”数字。这个章节解释由IANA来使用的标准，用这个标准在每一个这些列表中分配附加数字。在前面章节中没有明确说明的所有值对IANA来说是保留的。
6.1IPSEC位置定义
这个位置定义是一个32位bitmask，它描绘IPSECSA的建议和商谈被实现的环境。请求分配新位置应该由一个RFC来完成，这个RFC由关联位来解释。
假如这个RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和转化标识符被指派之前被明确的回复或被IESG认可。
这个上层的两位在合作系统中被保留用作私有用途。
6.2IPSEC安全协议标识符
这个安全协议标识符适合一个8位值，它标识一个正需要讨论的安全协议。请求分配一个新的安全协议标识符应该由一个RFC来实现，它描叙了这个需要的安全协议。[AH]和[ESP]是这个安全协议文件中的例子。
假如这个RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在这个RFC被公开和这个转化被指岀之前明确的评论和由IESG来认可。
这些值249-255在合作系统中被保留作为私有用途。
6.3IPSECISAKMP转移标志符
这个IPSECISAKMP转移标志符是一个8位的值，它标识一个用来流通的密钥交换协议。
请求分配新的ISAKMP转移标志符应该由RFC来完成，它描叙这个需要的密钥交换协议。[IKE]是一个这种文件中的例子。
假如RFC不在标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前明确的指出和通过IESG来证实。
在合作系统中保留249－255这些值作为私有用途来使用。
6.4IPDECAH转移标识符
这个IPSECAH转移标识符是一个8位值，它鉴别一个特定的算法法则来为AH提供完整保护。请求分配一个新的AH转移标识符应该由一个RFC来协助完成。这个RFC描绘了怎样在AH框架中用这个运算法则。
假如这个RFC不是在这个标准轨迹上（也就是说,它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
在合作系统中保留这些值249－255来作为私有用途。
6.5IPSECESP转移标识符
这个IPSECESP转移标识符是一个8位的值，它鉴别一个特定的运算法则用来为ESP提供一个秘密保护。请求分配一个新的ESP转移标识符应该由RFC来协作完成。这个RFC描叙了在ESP框架中怎样用这个算法.
假如这个RFC不在这个标准轨迹上（也就是说，它不是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
在合作系统中保留这些值249－255来作为私有用途。
6.6IPSECIPCOMP转移标识符
这个IPSECIPCOMP转移标识符是一个8位的值，在ESP之前它标识一个特定的运算法则用来提供IP层压缩。请求分配一个新的IPCOMP转移标识符应该由一个RFC来协作完成，它描叙了在IPCOMP框架（[IPCOMP]）中怎样使用运算法则。另外，这个需要的运算法则应该被公开，并且在公共范围内。
假如这个RFC不在这个标准轨迹上（也就是说，它是一个报告的或实验的RFC），它应该在RFC被公开和这个转移标识符被分配之前被明确的指出和通过IESG来证实。
因为RFC已被批准出版，这些值1－47就用来保存作运算法则。在合作系统中这些值48－63被保留作为私有用途。这些值64－255被保留作为将来扩展。
6.7IPSEC安全相连属性
这个IPSEC安全相连属性由16位类型和其相连的值组成。OPSECSA属性用来在ISAKMP之间传递各种各样的值。请求分配一个新的OPSECSA属性应该由因特网草案来完成。它描叙了属性代码（基础的/可变长度的）和它的合法值。这个文档中的第4.5章提供了一个这样描叙的例子。
在合作系统中这些值32001－32767被保留作为私有用途。
6.8IPSEC标签范围标识符
IPSEC标签范围标识符是一个32位的值，它鉴别一个namespace，在namespace里秘密层，完整层和各种值都存在。请求分配一个新的OPSEC标签范围标识符应该得到满足。不需要合作文件，尽管在适当的时候因特网草案可以得到鼓励。
在合作系统中这些值0x80000000-0xffffffff被保留作为私有用途。
6.9IPSEC标识符类型
这个IPSEC标识符类型是一个8位的值，它被用来作为一个解释各种长度有效载荷的判别式。请求分配新的OPSEC鉴定类型应该由RFC来完成，它描叙了在OPSEC里怎样使用这个鉴定。
假如RFC不是在标准轨迹上（也就是说，它是一个报告的或实验的RFC），在RFC被公开和这个转移标识符被分配之前，它应该明确的指出和由IESG来证实。
在合作系统中这些值249－255被保留作为私有用途。
6.10OPSEC通报信息类型
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在IPSECSPI中直接指出。
。附加的填料排除秘密和完整地长度正文。
。可以向前参考第4.5章和第4.4.4章。
。更新文件参考书目。
7.2从V8中改变
。更新IPCOMP标识符变化来更好地反映OPCOMP草案。
。更新IANA考虑的每个Jeff/Ted"s暗示的正文。
。除去DES-MACID([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来澄清AuthAlg。
。附加的约束来反对用冲突的AH/Auth联合体。
7.4从V6中改变
下列这些改变是相对于IPSECDOIV6的。
。附加IANA需要考虑的章节
。移出多数IANA数到IANA需要考虑的章节。
。附加禁止发送(V)代码属性（B）.
。附加禁止为固定的长度的密码(例如DES)发送密钥长度属性.
。用IKE取代涉及到ISAKMP/Oakley的参考书目。
。从ESP_ARCFOUR到ESP_RC4进行重命名。
。更新安全考虑章节。
。更新文档参考书目。
7.5从V5中变化
下列变化与IPSECDOIV5有关系：
。在通知正文中改变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中的变化
下列变化与IPSECDOIV4有关：
。从AH转移ID到鉴定算法标识符中移动具有兼容性的AHKPDK的鉴定方法
。每一个结构附加REPLAY-ENABLED通知信息类型
。每个列表附加INITIAL-CONTACT通知信息类型
。附加内容来确信保护通报状态信息
。附加属性解析章节永久资格
。附加地澄清永久通知是任选的
。移开私有团体描叙列表（现在指向[IKE]）
。用指向RFC-2119的指针来取代这个术语
。更新HMACMD5和SHA-1ID参考书目
。更新章节1（抽象的）
。更新章节4.4（IPSEC分配的数）
。在第一个阶段附加ID端口/协议值的约束
7.7从V3到V4的变化
下列变化与IPSECDOIV3有关，这个对IPSEC邮寄优于MUNICHIETF的列表来说是很有用的：
。为空和ARCFOUR附加转移标识符
。重新命名HMAC运算法则到AUTH运算法则来进行协调DES-MAC和ESP可选的鉴定/完整性
。附加AH和ESPDES-MAC运算法则标识符
。移动DEY_MANUAL和KEY_KDC标识符定义
。附加永久MUST随从属性到SA类型和SA属性定义
。附加永久通知何IPSECDOI信息类型表格
。附加可选的鉴定和机密性约束到MAC运算法则属性定义
。更正属性解析例子（习惯的过时的属性）
。更正多个因特网草案文件参考书目
。对每个ipsec列表讨论（18－Mar－97）附加ID_KEY_ID
。为PFSQM([IKE]MUST)移动默认团体描叙
致谢
这个文件部分起源于以下人的工作：DouglasMaughan,MarkSchertler,MarkSchneider,JeffTurner,DanHarkins,和DaveCarrel.MattThomas,RoyPereira,GregCarter,和RanAtkinson在很多种案例和正文中也提出了他们的建议。
参考书目
[AH]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",RFC
2402,November1998.
[ARCH]Kent,S.,andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.
[DEFLATE]Pereira,R.,"IPPayloadCompressionUsingDEFLATE",RFC
2394,August1998.
[ESP]Kent,S.,andR.Atkinson,"IPEncapsulatingSecurity
Payload(ESP)",RFC2406,November1998.
[ESPCBC]Pereira,R.,andR.Adams,"TheESPCBC-ModeCipher
Algorithms",RFC2451,November1998.
[ESPNULL]Glenn,R.,andS.Kent,"TheNULLEncryptionAlgorithmand
ItsUseWithIPsec",RFC2410,November1998.
[DES]Madson,C.,andN.Doraswamy,"TheESPDES-CBCCipher
AlgorithmWithEXPlicitIV",RFC2405,November1998.
[HMACMD5]Madson,C.,andR.Glenn,"TheUseofHMAC-MD5withinESP
andAH",RFC2403,November1998.
[HMACSHA]Madson,C.,andR.Glenn,"TheUseofHMAC-SHA-1-96within
ESPandAH",RFC2404,November1998.
[IKE]Harkins,D.,andD.Carrel,D.,"TheInternetKeyExchange
(IKE)",RFC2409,November1998.
[IPCOMP]Shacham,A.,Monsour,R.,Pereira,R.,andM.Thomas,"IP
PayloadCompressionProtocol(IPComp)",RFC2393,August
1998.
[ISAKMP]Maughan,D.,Schertler,M.,Schneider,M.,andJ.Turner,
"InternetSecurityAssociationandKeyManagementProtocol
(ISAKMP)",RFC2408,November1998.
[LZS]Friend,R.,andR.Monsour,"IPPayloadCompressionUsing
LZS",RFC2395,August1998.
[OAKLEY]Orman,H.,"TheOAKLEYKeyDeterminationProtocol",RFC
2412,November1998.
[X.501]ISO/IEC9594-2,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Models",CCITT/ITU
RecommendationX.501,1993.
[X.509]ISO/IEC9594-8,"InformationTechnology-OpenSystems
Interconnection-TheDirectory:Authentication
Framework",CCITT/ITURecommendationX.509,1993.
Author"sAddress
DerrellPiper
NetworkAlchemy
1521.5PacificAve
SantaCruz,California,95060
UnitedStatesofAmerica
Phone:+1408460-3822
EMail:ddp@network-alchemy.com
全部版权陈述
版权（C）因特网社会（1998）。版权所有
这个文章和它的翻译可能被复制和提供给别人，并且引出一些评论或者解释它或援助它执行可能被预备，拷贝，出版和分配，不管是整体的还是局部的，没有任何限制，提供这上面的版权告示和包含所有拷贝和起源工作的章节。但是，这个文章它自己本身不能以任何方式修改，例如通过移走版权告示或因特网团体或别的因特网组织的参考书目，除了发展因特网标准的需要，在这种情况下，定义在因特网标准过程中的版权程序应该要有，或者需要翻译成不同于英语的别的语言。
这个受限的许可同意以上的声明是永久的，并且它将不会被因特网团体或它的继任者或设计者废除。
包含在这儿的这个文件和通知作为一个基础来提供。
这个因特网团体和这个因特网工程任务迫使它公布所有的授权，表达或隐含，包括但是不限制任何授权，在这儿信息的用途不破坏任何权利或任何隐含的购买授权或一个非凡的目的。