rfc2407.txt

RFC文档

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！完整长度 ( 在字节）  ！          保留            ！
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                       完整级别                         
                                                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
！ 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的一个例子是"[e-mail]".这个字符串不应该包含任何界限。
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]）中怎样使用运算法则。另外，这个需要的运算法则应该被公开，并且在公共范围内。