RFC2403 在ESP和AH中使用HMAC-MD5-96

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者  wangh（Javen_wang  ykilyfe@china.com）
译文发布时间：2001-7-1
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。

Network Working Group                                          C. Madson
Request for Comments: 2403                            Cisco Systems Inc.
Category: Standards Track                                       R. Glenn
                                                                    NIST
                                                           November 1998

在ESP和AH中使用HMAC-MD5-96
(RFC2403 The Use of HMAC-MD5-96 within ESP and AH)

本备忘录状态
   本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建议。
请参考最新版本的\"Internet Official Protocol Standards\" (STD 1) 来获得本协议的标准化进程
和状态，此备忘录的发布不受任何限制。

版权注意
   版权归因特网协会所有，保留一切权利。

摘要
   本备忘录描述了在修订的IPSEC封装安全净荷协议（ESP）和IPSEC验证头协议（AH）
中，使用和MD5算法[RFC-1321]关联的HMAC算法[RFC-2104]作为验证机制。HMAC-MD5
提供数据源验证和完整性保护。
   关于运行ESP和AH所需其他组件的更多信息由[Thayer97a]提供。
目录
1、介绍 2
2、算法和模式 2
2.1 性能 3
3. 密钥源 3
4. 与ESP密码机制的互操作性 3
5. 安全考虑 4
6. 感谢 4
7. 参考 5
8. 编者地址 5
9.全部版权声明 6


1、介绍
   本备忘录描述了在封装安全净荷和验证头中使用和HMAC[RFC-2104]相关联的
MD5[RFC-1321]的键控验证机制。HMAC-MD5-96的目的是确保数据包是可信的而且在传输
过程中没有被修改。
   HMAC是一种秘密的密钥验证算法。HMAC提供的数据完整性和源身份验证完全取决于
秘密密钥分配的范围。如果只有发起者和接收者知道HMAC密钥，那么这就对两者间发送
的数据提供了源身份验证和完整
性保证。如果HMAC是正确的那就证明它一定是真正的发送者添加的。
    在本备忘录中，HMAC-MD5-96被用在ESP和AH中。关于不同的ESP片（包括机密
性机制）是如何组合在一起提供安全服务的跟多信息，请参照[ESP] and [Thayer97a]。关于
AH的更多信息请参照[AH] and [Thayer97a]。
    本文档中的关键字\"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL
NOT\",\"SHOULD\",
 \"SHOULD NOT\", \"RECOMMENDED\",  \"MAY\",和 \"OPTIONAL\"的解释在[RFC-2119]中
有描述。

2、算法和模式
  
   [RFC-1321]描述了基本MD5算法，而[RFC-2104]描述了HMAC算法。HMAC算法为插
入象MD5这样的各种散列算法提供了一种框架。

   HMAC-MD5-96在64位的数据块上运行。对填充的需要在[RFC-1321]中有描述而且填充
是MD5算法一部分。如果依照[RFC-1321]对MD5进行构建，那么相关的HMAC-MD5-96
就不需要添加任何额外的添充。对于在[AH]中定义的“固定包填充”不是必须的。
  
   HMAC-MD5-96产生128位的验证值。这128位值可以向在FRC 2104中描述的那样删
减。为了在SEP或AH中使用，被删节的验证数据必须使用前部的96位。在发送端，这种
删节了的数据存储在验证区。在接收端，完全的128位值被计算出来，并和验证区的96位
值比较。HMAC-MD5-96不支持其它的验证值长度。

   选择96位是因为这是[AH]中描述的默认验证长度并且能满足[RFC-2104]中对安全需要
的描述。

2.1 性能
 
   [Bellare96a]的声明“（HMAC的性能本质上就是根散列函数的性能”。[RFC-1810]提供了
一些在Internet协议中使用MD5的性能分析和推荐。但在它里面没有HMAC或是
HMAC-MD5的性能分析。

   [RFC-2104]中概述了一种执行修正，可以在不影响互操作性的前提下提高每个包的性能。

3. 密钥源

   HMAC-MD5-96是一种秘密密钥算法。在[RFC-2104]中没有描述固定的密钥长度，但为
了在ESP或AH中使用，固定的128位密钥长度必须被支持。而其他不同于128位的密钥
长度一定不被支持（也就是说HMAC-MD5-96只能使用128位密钥）。根据[RFC-2104]的推
荐选择128位密钥长度（也就是说密钥长度比验证值短会减弱安全的健壮性，而比验证值长
的也不会明显的增强安全的健壮性）。

   [RFC-2104]讨论了对密钥源的需求，包括对健壮的随机性的需求的讨论。必须的128位
密钥必须由一个健壮的伪随机函数产生。

   在讨论本文档时，还没有一种虚弱的密钥在HMAC上使用。这不意味着暗示虚弱的密钥
不存在。在某个意义上，如果一套HMAC使用的虚弱的密钥被鉴别，那么这些虚弱密钥的
使用必须被丢弃，然后发送重新安排密钥或一次新的安全联盟协商请求。

   当一个单一的SA需要多个密钥时（也就是说当一个ESP SA需要一个加密密钥和一个验
证密钥），[ARCH]为获得密钥源描述了一个通用的机制。

   为了提供数据源验证，密钥分配机制必须确保唯一的密钥对被分配，而且只分配给通信
的参与者。

   [RFC-2104]对于密钥的重新分配提出了以下建议。并不能因为当前的攻击实际上是不可
行的就认为这些攻击并可以预示一个特殊的被推荐的密钥使用时间。无论如何，定期的密钥
更新是一种基本的安全习惯，这可以帮助抵抗函数和密钥潜在的弱点，减少对于一个破译者
的信息可用性，限制了由于密钥暴露引起的危害。

4. 与ESP密码机制的互操作性

   在写作本文档时，还没有一种已知的出版物排除了HMAC-MD5-96算法和其它任何特殊
的密码算法公用的可能。

5. 安全考虑

   HMAC-MD5-96提供的安全性依靠HMAC的健壮性，更少的使用频度，MD5的健壮性。
[RFC-2104]主张HMAC不只是依靠健壮的抵抗冲突的性质，考虑评估MD5的使用也是重要
的，在当前的审查下已有的算法比最初所考虑的有更差的抗冲突性。在写作本文档时，还没
有一种实际的密文攻击可以攻破HMAC-MD5-96。

   [RFC-2104]声明对于“最小合理的散列函数”和“生日攻击”，这些最强的最HMAC的
攻击是不实际的。对于一个进行了HMAC-MD5-96运算的64字节的数据块，包括成功的处
理2**64个块是不实际的，除非在处理2**30个块后发现潜在的散列冲突。有弱抗冲突特性
的散列被认为是不可用的。

   认为被使用的MD5是不完善的键控散列算法也是重要的，HMAC有来自攻击的标准。
当在数据安全策略中使用MD5正在经受再审议时，HMAC和MD5的组合算法已经拦截了
对密文的详细审查。

   [RFC-2104]也讨论了由于结果散列的是删节所带来的潜在的附加安全问题。包括HMAC
的规范强烈推荐执行这种散列删节。

   正象[RFC-2104]为合并各种散列算法和HMAC提供了框架，使用其他算法象SHA-1取
代MD5是可能的。[RFC-2104]包含一个关于HMAC算法健壮性和虚弱性的详细的讨论。

   对于任何的密文算法，它的健壮性在于算法执行的正确性，密钥管理机制和它的执行的
安全性，关联的秘密密钥的健壮性，各个参与系统执行的正确性。[RFC-2202]包含测试向量
和实例代码用于帮助核查HMAD-MD5-96代码的正确性。

6. 感谢

   本文档部分源于Jim Hughes先前的工作，和Jim一起为组合DES/CBC+HMAC-MD5 ESP
转换工作的人们，ANX bakeoff的参与者和IPsec工作组的成员。

   我们也很高兴感谢为本文档中的一些特殊内容提出意见和解释的Hugo Krawczyk先生。

7. 参考

   [RFC-1321]   Rivest, R., \"MD5 Digest Algorithm\", RFC 1321, April
                1992.

   [RFC-2104]   Krawczyk, H., Bellare, M., and R. Canetti, \"HMAC:
                Keyed-Hashing for Message Authentication\", RFC 2104,
                February 1997.

   [RFC-1810]   Touch, J., \"Report on MD5 Performance\", RFC 1810, June
                1995.

   [Bellare96a] Bellare, M., Canetti, R., and H. Krawczyk, \"Keying Hash
                Functions for Message Authentication\", Advances in
                Cryptography, Crypto96 Proceeding, June 1996.

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

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

   [AH]         Kent, S., and R. Atkinson, \"IP Authentication Header\",
                RFC 2402, November 1998.

   [Thayer97a]  Thayer, R., Doraswamy, N., and R. Glenn, \"IP Security
                Document Roadmap\", RFC 2411, November 1998.

   [RFC-2202]   Cheng, P., and R. Glenn, \"Test Cases for HMAC-MD5 and
                HMAC-SHA-1\", RFC 2202, March 1997.

   [RFC-2119]   Bradner, S., \"Key words for use in RFCs to Indicate
                Requirement Levels\", BCP 14, RFC 2119, March 1997.

8. 编者地址

   Cheryl Madson
   Cisco Systems, Inc.

   EMail: cmadson@cisco.com


   Rob Glenn
   NIST

   EMail: <rob.glenn@nist.gov>

    The IPsec working group can be contacted through the chairs:

   Robert Moskowitz
   ICSA

   EMail: rgm@icsa.net


   Ted T\'so
   Massachusetts Institute of Technology

   EMail: tytso@mit.edu

9.全部版权声明

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   \"AS IS\" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2403――RFC2403 The Use of HMAC-MD5-96 within ESP and AH
                                                在ESP和AH中使用HMAC-MD5-96


7
RFC文档中文翻译计划