|
RFC文档中文翻译计划（http://www./compters/emook/aboutemook.htm）
E-mail：http://www.360doc.com/mailto:ouyang@ 译者：piex（piex http://www.360doc.com/mailto:jintao@bigfoot.com） 译文发布时间：2002-01-18 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。 Network Working Group R. Atkinson IP封装安全载荷（ESP） 本备忘录的状态
1 介绍 1． 1综述 在共享系统中使用此规范会增长IP协议处理的代价。使用此规范也会增长信息通讯的延迟时间。延迟时间的增长主要是由包含在一个ESP中的每个IP数据包都需要的加密和解密过程引起的。 在隧道模式的ESP中，原始的IP数据包被放置于ESP的被加密部分，然后将完整的ESP帧放入一个数据包内，此数据包有一个未加密的IP报头。未加密的IP数据报头中的信息被用来将安全数据包从源地址发送到目的地址。一个未加密的IP路由报头可以被包括在IP报头和ESP之间。 在传输模式的ESP中，ESP头被插入到IP数据包中传输层协议报头（例如，TCP,UDP,或者 ICMP）的前面。在此模式下，因为没有加密的IP报头或者IP选项所以带宽被保护。 在IP中，一个IP认证头可以用来作为一个未加密信息报的头部或者在一个传输模式的ESP信息报中位于IP报头和ESP报头之间，也可以作为一个报头位于一个隧道模式的ESP信息报的加密部分。当一个AH同时出现在纯文本的IP报头和单个信息包的隧道模式ESP头之内时，未加密的IPv6认证主要被用于向未加密的IP头的内容提供保护，加密的认证头被用于向加密的IP信息包提供报头验证。本文稍后详述。 IP封装安全载荷的组织结构与别的IP有效载荷有很大不同。ESP有效载荷的第一个成分是有效载荷的未加密域。第二个部分是加密的数据。未加密 ESP报头的域通知预期的接收者怎样合适的解密和处理加密的数据。被加密的数据部分包括用于安全协议的受保护域以及加密封装的IP数据包。 安全联合的概念是ESP的重要的基础部分。它在相关文档“Security Architecture for the Internet Protocol” 被详细的描述。执行者应该在读此篇文档之前读那篇文档。 1．2 需求的术语定义 －MUST（必须） －SHOULD(应该) －MAY（可以） 2 密钥管理 3 封装安全有效载荷的语法 封装安全有效载荷（ESP）可能出现在IP头之后和最后传输层协议之前的任何地方。IANA（Internet Assigned Numbers Authority，负责全球Internet的IP地址编号分配的机构）已经分配了协议号50给ESP[STD-2]。ESP 头前的那个报头总是在它的NEXT Header（IPV6）或者协议（IPV4）域中写入值50。ESP由一个未加密的报头和加密的数据部分组成。加密的数据既包括被保护的ESP 头也包括被保护的用户数据。而用户数据或者是一个完整的IP 数据包，也可能仅仅是一个上层协议部分（例如： TCP 或者 UDP）。一个安全数据包的高层图表如下所示：
ESP报头的更详细的图表如下所示 +-------------+--------------------+------------+---------------------+
3．1 封装安全有效载荷的域 SPI 是一个32位的伪随机值，它用来确定数据包的安全关联。如果不建立安全关联，SPI 域的值就应该是0x00000000。一个SPI 类似于别的安全协议中的SAID。因为 在此处SPI 的语意和别的安全协议中的SAID不是完全相同，所以名字不一样。 SPI的值的集合中，从0x00000001到 0x000000FF 是被保留给 IANA 的，以用于将来的使用。除非在一篇 RFC 中公开的说明一个特定的被保留的 SPI 值已经被分配，否则保留的 SPI 值通常不能被分配。 3．2 ESP 的安全标记 4 封装安全协议的处理过程 此节描述了当 ESP 在两个互连的实体间使用时实施的步骤。多播与单播的仅在密钥管理上不同（细节请看看上面的 SPI定义）。ESP 有两种使用模式。第一种被称做隧道模式，在ESP内封装一个完整的 IP数据包。第二个模式称为传输模式，在ESP内封装一个传输层的帧（如UDP,TCP）。术语传输模式一定不能被误解仅限于TCP 和UDP。例如，一个IMCP 消息在不同环境下既可以通过传输模式发送也可以通过隧道模式发送。ESP 的处理过程发生在发送时的 IP 分割之前以及接受时的IP重新组合之后。此节描述了两种模式的协议处理过程。 4．1 隧道模式下的 ESP 隧道模式下的 ESP报头跟随在所有的端到端的报头之后（例如，认证头，如果在明文中呈现的话），在它后面就紧接着一个被隧道化的 IP数据包。发送方将原始的IP数据包封装进ESP，至少使用发送方的用户ID以及目的地址来定位正确的安全关联，然后运用合适的加密变换。如果使用基于主机的密钥产生机制，那么对于一个特定的目的地址来说，一个给定系统上所有的发送用户拥有相同的安全关联。如果没有任何一个密钥已经被建立，那么密钥管理机制要为这个连接会话产生一个加密密钥，此过程要在ESP被使用之前发生。此后，（加密的）ESP作为最终的有效载荷被封装入一个未加密的IP数据包。如果执行严格的红黑分割，那么可选的载荷和明文IP数据报头中的地址以及其他的信息可能会和包含在原始数据包（现在已经被加密和封装了）中的值有所不同。 接收方剥去明文IP报头以及明文的可选IP载荷（如果有）并且丢弃它们。接下来，接受方结合使用目的地址和SPI值来定位这个信息包的正确的会话密钥，然后使用这个密钥来解密这个ESP。 如果对于此会话不存在一个合法的安全关联（例如，接受方没有密钥），接受方必须丢弃这个加密的ESP 并且这个错误必须被记录在系统日志或者审核日志当中。这个系统日志或审核日志应该包括SPI的值，时间，明文的发送地址，明文的目的地址，以及明文的信息流的ID。日志条目也可以包括别的认证数据。接受方可能不想立即通知发送方有错，因为这样极有可能被拒绝服务攻击模式所利用。 如果解密成功，原始的IP数据包被从ESP（已被解密）移出。然后，这个原始的数据包就按照通常的IP协议规范来处理。在要求提供多级安全安全的系统中（例如，一个B1级或分割模式的工作站）,基于接受进程的安全级别以及与安全关联相关的安全级别，附加的合适强制访问控制必须被实施。如果这些强制访问控制失败了，那么这个信息包应该被丢弃，同时应该使用特定的实施过程将错误录入日志。 4．2 传输模式下的ESP 发送者将原始的传输层（例如：UDP,TCP,ICMP）帧封装入ESP，至少使用发送的用户ID和目的地址来定位合适的安全关联，然后运用合适的加密变换。如果使用基于主机的密钥产生机制，那么对于一个特定的目的地址来说，一个给定系统上所有的发送用户拥有相同的安全关联。如果没有任何一个密钥已经被建立，那么密钥管理机制要为这个连接会话产生一个加密密钥，此过程要在ESP被使用之前发生。此后，（加密的）ESP作为最终的有效载荷被封装入一个未加密的IP数据包。 接收方的处理明文IP头和明文的可选IP 头（如果有）并且暂时存储相关信息（例如，源地址和目的地址，信息流ID，路由选项头），接受方结合使用目的地址和SPI值来定位这个信息包的正确的会话密钥，然后使用已为此次通信而建立的会话密钥将ESP 解密。 如果没有用于此会话的密钥或者解密的尝试失败，接受方必须丢弃这个加密的ESP 并且这个错误必须被记录在系统日志或者审核日志当中。如果如此的一个失败发生，这个系统日志或审核日志应该包括SPI的值，接受时间，明文的发送地址，明文的目的地址，以及明文的信息流的ID。日志条目也可以包括别的关于失败的信息包的信息。如果某些原因的存在而导致解密无法正常工作，那么由此而来的数据就无法被实施中的协议引擎所分析。因此，失败的机密通常是可以被检测到的。 如果解密成功，原来的传输层（例如，UDP,TCP,ICMP）帧从ESP （已被解密）中移出。明文IP 头信息和传输层头被结合起来判别数据一个被送往哪一个应用程序。然后数据就象按照一般的IP 协议规范那样被送给合适的应用程序。在要求提供多级安全安全的系统中（例如，一个B1级或分割模式的工作站）,基于接受进程的安全级别以及与安全关联相关的安全级别，附加的合适强制访问控制必须被实施。 4．3 认证 在第一种方法中，被接受的数据包整个被认证，包括它的加密部分和未加密部分。而只有ESP报头之后的数据是机密的。在此方法中，，发送方首先运用 ESP 封装被保护的数据，然后将明文的IP报头置于ESP报头和加密的数据之前。最后，按照通常的方法利用已得出的数据包计算出IP 认证报头。接收时，接收者首先使用通常的IP 认证头处理过程对整个数据包进行身份认证。然后，如果身份认证成功，那么就使用通常的IP ESP 处理过程来进行解密。如果解密成功，那么得到的数据就被传递给上一层。
如果认证报头被封装在一个隧道模式的 ESP报头之内并且两个报头都有与它们相关联的安全分类级别，而这两个安全分类级别不是相同的，那么一个错误就会发生。这个错误应该被上面描述的程序过程记录在系统日志或者审核日志中。一个认证报头定位在ESP报头之外的时候，如果它们有不同的安全分类级别并不一定是个错误。这可能是合理的因为在数据被 ESP加密之后，明文的IP 报头可能有一个不同的分类级别。 5 一致性要求 6 安全考虑 对于一个使用分组链接算法并且缺乏一个健壮的完整性机制的ESP来说，它的加密变换在受到cut-and-paste攻击（见Bellovin的描述文章）时是脆弱的，除非认证报头总是出现在使用ESP变换的信息包之内，否则不应该被使用。[Bel95] 使用者需要明白此规格提供的安全品质完全依赖于所采用的加密算法的强度和实现时的正确性，以及密钥管理机制的安全性和它实现时的安全性，还依赖于密钥自身的强度以及在所有相关系统中ESP 和IP实施的正确性。 如果这些假定的条件有一些不满足，就不会有真正的安全可言。在IP 封装安全有效载荷中推荐使用高可靠性的的开发技术。 如果用户想在受到流量分析时保护数据，他可能用到一个恰当的链接加密方法。链接加密的描述和规格不在此篇文章的论述范围之内。 即使不使用面向用户的密钥，当前使用的算法对于所有的选择明文攻击方法来说都应该是牢固的。对DES的选择明文攻击在[BS93]和[Mat94] 中被描述。面向用户的密钥的被推荐使用，因为它可以排除各种选择明文攻击并且使解密更困难。就像在IP Security Architecture[AtK95a]描述的那样，在实现的时候应该使用面向用户的密钥。
承谢 本文的许多概念源于美国政府的SP3安全协议规格，ISO/IEC的NLSP规格，以及提议中的swIPe安全协议 [SDNS89,ISO92a,IB93,IBK93,ISO92b]或是受到它们的影响。用于保密的DES的使用在论述SNMPv2的文章中已经被严整的建模[GM93]。Steve Deering,Dave Michelcic,Hilarie Orman提供了对此篇备忘录早期版本的可靠的评论。
[Atk95a] Atkinson, R., "Security Architecture for the Internet [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP [Bel95] Steven M. Bellovin, Presentation at IP Security Working [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the [CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data: [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode [GM93] Galvin J., and K. McCloghrie, "Security Protocols for [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6) [IB93] John Ioannidis & Matt Blaze, "Architecture and Implementation [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC [Ken91] Kent, S., "US DoD Security Options for the Internet [KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC [Mat94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", [NIST77] US National Bureau of Standards, "Data Encryption Standard", [NIST80] US National Bureau of Standards, "DES Modes of Operation" [NIST81] US National Bureau of Standards, "Guidelines for Implementing [NIST88] US National Bureau of Standards, "Data Encryption Standard", [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
本文的观点和规格代表作者本人，海军研究实验室还没有对本文的价值（如果有的话）作出判断。本文作者以及作者的雇主对于由于正确或者错误的实施使用此规格而引起的问题不负任何责任。 作者地址 Phone: (202) 404-7090 |
|
|
