封装安全有效载荷.docx

1、封装安全有效载荷Network Working Group S. KentRequest for Comments: 2406 BBN CorpObsoletes: 1827 R. AtkinsonCategory: Standards Track Home Network November 1998IP 封装平安有效载荷 (ESP)(RFC 2406 IP Encapsulating Security Payload (ESP)本文档状态： This document specifies an Internet standards track protocol for the Interne

2、t community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.版权声明 Copyright (C) The Internet Society (19

3、98). All Rights Reserved.目录列表 1. 介绍.2 2. 封装平安有效载荷分组格式.3 2.1 平安参数索引.4 2.2 序列号 .4 2.3 有效载荷数据.5 2.4 填充供加密使用.5 2.5 填充长度.7 2.6 下一个头.7 2.7 验证数据.7 3. 封装平安协议处理.7 3.1 ESP头定位.7 3.2 算法.10 3.2.1 加密算法.10 3.2.2 验证算法.10 3.3 出站分组处理.10 3.3.1 SA查找.11 3.3.2 分组加密.11 3.3.3 序列号产生.12 3.3.4 完整性校验值计算.12 3.3.5 分片.13 3.4 入站分组

4、处理.13 3.4.1 重组.13 3.4.2 SA查找.13 3.4.3 序列号确认.14 3.4.4 完整性校验值确认.15 3.4.5 分组解密.16 4. 审核.17 5. 一致性要求.18 6. 平安考虑事项.18 7. 与 RFC 1827的不同.18 致谢.19 参考书目.19 Disclaimer.20 作者信息.21 版权声明.221. 介绍 封装平安有效载荷头在IPv4和IPv6中提供一种混合的平安效劳。ESP可以单独应用，与IP验证头(AH)结合使用，或者采用嵌套形式，例如，隧道模式的应用(参看 Security Architecture for the Internet

5、 Protocol KA97a，下面使用“平安架构文档代替)。平安效劳可以在一对通信主机之间，一对通信的平安网关之间，或者一个平安网关和一台主机之间实现。在各种网络环境中如何使用ESP和AH的详细细节，参看平安架构文档。 ESP头可以插在IP头之后、上层协议头之前(传送模式)，或者在封装的IP头之前(隧道模式)。下面将详细介绍这些模式。 ESP提供机密性、数据源验证、无连接的完整性、抗重播效劳(一种局部序列完整性的形式)和有限信息流机密性。提供的这组效劳由SA建立时选择的选项和实现的位置来决定，机密性的选择与所有其他效劳相独立。但是，确保机密性而不保证完整性/验证(在ESP或者单独在AH中)可

6、能使信息易受到某种活动的、破坏机密性效劳的攻击(参看Bel96)。数据源验证和无连接的完整性(下面统一称作“验证引用它们)是相互关联的效劳，它们作为一个选项与机密性(可选择的)结合提供应用户。只有选择数据源验证时才可以选择抗重播效劳，由接收方单独决定抗重播效劳的选择。尽管默认要求发送方增加抗重播效劳使用的序列号，但只有当接收方检查序列号，服务才是有效的。信息流机密性要求选择隧道模式，如果在平安网关上实现信息流机密性是最有效的，这里信息聚集能够掩饰真正的源-目的模式。注意尽管机密性和验证是可选的，但它们中必须至少选择一个。 假定读者熟悉平安架构文档中描述的术语和概念。特别是，读者应该熟悉ESP和

7、AH提供的平安效劳的定义，SA定义，ESP可以和验证AH头结合使用的方式，以及ESP和AH使用的不同密钥管理选项。至于最后一项，ESP和AH要求的当前密钥管理选项是通过IKE进行的手工建立密钥和自动建立密钥HC98。 关键字MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD NOT, RECOMMENDED, MAY,和OPTIONAL, 当它们出现在本文档时，由RFC2119中的描述解释它们的含义Bra97。2. 封装平安有效载荷分组格式 ESP头紧紧跟在协议头IPv4，IPv6，或者扩展之后，协议头的协议字段IPv4将是50，

8、或者协议的下一个头(IPv6，扩展)字段STD-2值是50。 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| 平安参数索引 (SPI) | Auth.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| 序列号 | |erage+-+-+-+-+-+-+-+-+-+-+-+-

9、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -| 有效载荷数据* (可变的) | | | | | |Conf.+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | 填充 (0-255 bytes) | |erage*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 填充长度 | 下一个头 | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10、-+-+ -| 验证数据 (可变的) | | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *如果加密同步数据，例如初始化向量IV，参看2.3节，包含在有效载荷字段中，通常它本身并不加密，虽然常常把它作为密文的一局部。 下面小节定义了头格式中的字段。“可选项意味着如果没有选择它，该字段被忽略。即它既不被包含在传送的分组中，也不会在完整性校验值(ICV，参看2.7)计算中出现。建立SA时决定是否选择某个选项，因此ESP分组的格式对于给定的SA是确定的，整个SA存活期间也是确定的。相对而言，“强制性字段总是出现

11、在ESP分组格式中，对所有SA均如此。 2.1 平安参数索引SPI SPI是一个任意的32位值，它与目的IP地址和平安协议ESP结合，唯一地标识这个数据报的SA。从1至255的这组SPI值是由Internet Assigned Numbers Authority (IANA)保存给将来使用的；除了分配的SPI值的使用由RFC指定，否那么，一般IANA不会分配保存的SPI值。通常在建立SA时目的系统选择SPI详细内容请参看平安架构文档。SPI字段是强制性的。 SPI的值为0是保存给本地、特定实现使用的，不允许在线路上发送。例如，密钥管理实现可以使用SPI的0值表示当IPsec实现要求它的密钥管理

12、实体建立新SA，但SA仍然没有建立时，“没有SA存在。2.2 序列号Sequence Number 这个无符号的、32位字段包含一个单调递增的计数器值序列号。它是强制性的，即使接收方没有选择激活一个特定SA的抗重播效劳，它也总是存在。序列号字段由接收方处理，即发送方必须总是传输这个字段，但接收方不需要对其操作参看下面“入站分组处理中序列号确认的讨论。 发送方的计数器和接收方的计数器在一个SA建立时被初始化为0。使用给定SA发送的第一个分组的序列号1；序列号如何产生的细节参看3.3.3节如果激活抗重播效劳默认地，传送的序列号必须决不允许循环。因此，在SA上传送第2的32次方个分组之前，发送方计数

13、器和接收方计数器必须重新置位通过建立新SA和获取新密钥2.3 有效载荷数据Payload Data 有效载荷数据是变长字段，它包含下一个头字段描述的数据。有效载荷数据字段是强制性的，它的长度是字节的整数倍。如果加密有效载荷的算法要求加密同步数据，例如初始化向量IV，那么这个数据可以明确地装载在有效载荷字段。任何要求这样明确的、每分组同步数据的加密算法必须指出同步数据的长度、结构和位置，这是指定ESP中算法如何使用的某个RFC的一局部。如果这种同步数据是隐式的，派生数据的算法必须是RFC的一局部。 注意关于确保IV存在时实际密文对齐： o 对于一些基于IV模式的操作，接收方把IV作为密文的开始，

14、直接把IV传给算法。这些模式中，实际密文是否开始对齐对于接收方并不重要。 o 某些情况下，接收方从密文中单独读入IV。此时，算法标准必须解决实际密文对齐如何实现。2.4 填充(供加密使用) 几种因素要求或者激活填充字段的使用。 o 如果采用的加密算法要求明文是某个数量字节的倍数，例如块密码block cipher的块大小，使用填充字段填充明文包含有效载荷数据、填充长度和下一个头字段，以及填充以到达算法要求的长度。 o 不管加密算法要求如何，也可以要求填充字段来确保结果密文以4字节边界终止。特别是，填充长度字段和下一个头字段必须在4字节字内右对齐，如上图所示的ESP分组格式，从而确保验证数据字段

15、如果存在以4字节边界对齐。 o除了算法要求或者上面提及的对齐原因之外，填充字段可以用于隐藏有效载荷实际长度，支持局部信息流机密性。但是，包含这种额外的填充字段占据一定的带宽，因而小心使用。 发送方可以增加0至255个字节的填充。ESP分组的填充字段是可选的，但是所有实现必须支持填充字段的产生和消耗。 a. 为了确保加密位是算法块大小上面第一个加重号的倍数，填充计算应用于除IV之外的有效载荷数据、填充长度和下一个头字段。 b. 为了确保验证数据以4字节边界对齐上面第二个加重号，填充计算应用于包含IV的有效载荷数据、填充长度和下一个头字段。 如果需要填充字节，但是加密算法没有指定填充内容，那么必须

16、采用以下默认处理。填充字节使用一系列无符号、1字节整数值初始化。附加在明文之后的第一个填充字节为1，后面的填充字节按单调递增：1,2,3,。当采用这种填充方案时，接收方应该检查填充字段。选择这种方案是由于它相对简单，硬件实现容易。在没有其他完整性措施实施情况下，如果接收方检查解密的填充值，这种方案粉碎了某种形式的“剪切和粘贴攻击，提供有限的保护。 任何要求填充字段但不同于上述默认方法的加密算法，必须在一个指定ESP中算法如何使用的RFC中定义填充字段内容例如，0或者随机数和所有要求接收方对这些填充字节的处理。这种情况下，填充字段的内容将由相应算法RFC中定义和选择的加密算法和模式决定。相关的算

17、法RFC可以指定接收方必须检查填充字段或者接收方必须通知发送方接收方如何处理填充字段。2.5 填充长度Pad Length 填充长度字段指明紧接其前的填充字节的个数。有效值范围是0至255，0说明没有填充字节。填充长度字段是强制性的。2.6 下一个头 下一个头是一个8位字段，它标识有效载荷字段中包含的数据类型，例如，IPv6中的扩展头或者上层协议标识符。该字段值从Internet Assigned Numbers Authority (IANA)最新“Assigned Numbers STD-2 RFC 定义的IP协议号集当中选择。下一个头字段是强制性的。2.7 验证数据 验证数据是可变长字段

18、，它包含一个完整性校验值ICV，ESP分组中该值的计算不包含验证数据本身。字段长度由选择的验证函数指定。验证数据字段是可选的，只有SA选择验证效劳，才包含验证数据字段。验证算法标准必须指定ICV长度、验证的比拟规那么和处理步骤。 3. 封装平安协议处理3.1 ESP 头定位 类似于AH，ESP 有两种使用方式：传送模式或者隧道模式。前者仅在主机中实现，提供对上层协议的保护，不提供对IP头的保护。传送模式中，注意平安架构文档中定义的“堆栈中的块或者“线路中的块实现，入站和出站IP分片可能要求IPsec实现执行额外的IP重组/分片，以便遵照这个标准，提供透明IPsec支持。当存在多个接口时，在这些

19、实现内部执行这些操作要特别小心。 传送模式中，ESP插在IP头之后，上层协议之前，例如TCP，UCP，ICMP等，或者在任何已经插入的IPsec头之前。IPv4中，意指把ESP放在IP头和它包含的任何其他选项之后, 但是在上层协议之前。注意术语“传输模式不应该曲解为把它的应用限制在TCP和UDP中。例如ICMP报文可能使用“传输模式或者“隧道模式发送。下面数据报图示了典型IPv4分组中ESP传送模式位置，以“表示出外形上锋利对照为根底。“ESP尾部包含所有填充，加填充长度和下一个头字段。 ESP应用前 - IPv4 |原始IP头 | | | |(所有选项) | TCP | 数据 | - ESP

20、应用后 - IPv4 |原始IP头 | ESP | | | ESP | ESP| |(所有选项 )| 头部| TCP | 数据 | 尾部 |验证| - | | IPv6中，ESP被看作端到端的有效载荷，因而应该出现在逐跳，路由和分片扩展头之后。目的选项扩展头既可以在ESP头之前，也可以在ESP头之后，这由期望的语义决定。但是，因为ESP仅保护ESP之后的字段，通常它可能愿意把目的选项头放在ESP头之后。下面数据报图示了典型IPv6分组中ESP传送模式位置。 ESP应用前 - IPv6 | | 如果有 | | | | 原始IP头 |扩展头 | TCP | 数据 | - ESP应用后 - IPv6

21、 | 原始 |逐跳， 目的* | |目的 | | | ESP | ESP| |IP 头 |路由，分片 |ESP|选项*|TCP|数据|尾部 |验证| - | | * =如果存在，应该在ESP之前，ESP之后，或者ESP和AH头以各种模式组合。IPsec架构文档描述了必须支持的SA组合。 隧道模式ESP可以在主机或者平安网关上实现。ESP在平安网关保护用户传输流量实现时必须采用隧道模式。隧道模式中，“内部IP头装载最终的源和目的地址，而“外部IP头可能包含不同的IP地址，例如平安网关地址。ESP保护整个内部IP分组，其中包括整个内部IP头。相对于外部IP头，隧道模式的ESP位置与传送模式中ESP

22、位置相同。下面数据报图示了典型IPv4和IPv6分组中ESP隧道模式的位置。 - IPv4 | 新IP头* | | 原始IP头 * | | | ESP | ESP| |(所有选项) | ESP | (所有选项) |TCP|数据|尾部 |验证| - | | - IPv6 | 新 * |新 扩展 | | 原始*|原始扩展 | | | ESP | ESP| |IP 头 | 头 * |ESP|IP 头 | 头 * |TCP|数据|尾部 |验证| - | | * = 如果存在，外部IP头/扩展的结构和内部IP头/扩展的修改在下面讨论。3.2 算法 强制实现算法在第5节描述，“一致性要求。但也可以支持其他

23、算法。注意尽管机密性和验证是可选的，但是至少要从这两种效劳中选择其一，因此相应的两种算法不允许同时为NULL。3.2.1 加密算法 采用的加密算法由SA指定。ESP使用对称加密算法。因为到达的IP分组可能失序，每个分组必须携带所有要求的数据，以便允许接收方为解密建立加密同步。这个数据可能明确地装载在有效载荷字段，例如作为IV上面描述的，或者数据可以从分组头推导出来。因为ESP准备了明文填充，ESP采用的加密算法可以显示块或者流模式特性。注意因为加密机密性是可选的，这个算法可以为“NULL。 3.2.2 验证算法 ICV计算使用的验证算法由SA指定。点对点通信时，适宜的验证算法包括基于对称加密算

24、法例如DES的或者基于单向散列函数例如MD5或SHA-1的键控消息鉴别码MAC。对于多点传送通信，单向散列算法与不对称数字签名算法结合使用比拟适宜，虽然目前性能和空间的考虑阻止了这种算法的使用。注意验证是可选的，这个算法可以是“NULL。3.3 出站分组处理 传送模式中，发送方把上层协议信息封装在ESP头/尾中，保存了指定的IP头和IPv6中所有IP扩展头。隧道模式中，外部和内部IP头/扩展头以各种方式相关。封装处理期间外部IP头/扩展头的构建在平安架构文档中描述。如果平安策略要求不止一个IPsec头扩展，平安头应用的顺序必须由平安策略定义。3.3.1 SA查找 只有当IPsec实现确定与某个调用ESP处理的SA相关联时，ESP才应用于一个出站分组。确定对出站分组采取哪些IPsec处理的过程在平安架构文档中描述。3.3.2 分组加密 在本节中，由于格式化的含意，我们依据经常采用的加密算法来讲述。需要理解采用NULL加密算法提供的“没有机密性。因此发送方： 1. 封装到ESP有效载荷字段：