rfc2404.txt

283个中文RFC文档

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


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

在ESP和AH中使用HMAC-SHA-1-96
（RFC2404——The Use of HMAC-SHA-1-96 within ESP and AH）

本备忘录状态

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

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

摘要
   本文档描述了在修订的IPSEC封装安全载荷[ESP]和验证头[AH]协议中，使用和SHA-1算法
[FIPS-180-1]相关联的HMAC算法[RFC-2104]作为验证机制。结合SHA-1的HMAC提供了数据
源的验证和完整性保护。
   有关ESP和AH实现所必须的其他部分的信息由[Thayer97a]提供。
目录
1. 导言	2
2. 算法和模式	2
2.1 性能	2
3. 密钥源	3
4. 与ESP加密机制的互操作性	3
5. 安全考虑	3
6. 感谢	4
7. 参考	4
8. 编者地址	5
9. 完全版权声明	5

1. 导言
   本备忘录描述了使用结合HMAC[RFC-2104]算法的SHA-1[FIPS-180-1]算法作为封装安全载
荷和验证头背景下的键控验证机制。HMAC-SHA-1-96的目的就是确保传送过程中包是可信的并
且不能被修改的。
   HMAC是一种隐秘的密钥验证算法。HMAC提供的数据完整性和数据源验证依赖隐秘密钥散布
的范围。如果只有数据源和目的地HMAC密钥，这就为在二者之间发送的数据包提供了数据源
验证和数据完整性。如果HMAC是正确的，就保证了它一定是由源添加的。
   在本备忘录中，HMAC-SHA-1-96被用在ESP和AH背景下。关于ESP的不同部分--包括机密
性机制--是如何合适的协作来提供安全服务的更多信息，参考[ESP]和[Thayer97a]。关于AH
的更多信息，参考[AH]和[Thayer97a]。
   在本文档中提及的关键词"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", 和 "OPTIONAL"在[RFC 2119]中做
了解释。

2. 算法和模式
   [FIPS-180-1]描述了基本的SHA-1算法，而[RFC-2104]描述了HMAC算法。HMAC算法提供
了插入不同的散列算法的框架，比如SHA-1。
   HMAC-SHA-1-96对64位的数据块进行操作。填充需求在[FIPS-180-1]中有详细的说明，而
且是SHA-1算法的一部分。如果你依照[FIPS-180-1]构建了SHA-1，你就不再需要添加任何附
加的填充，对于HMAC-SHA-1-96也是如此。关于在[AH]中定义的"implicit packet padding"，
没有固定包填充被需要。
   HMAC-SHA-1-96产生一个160位的验证值。这个160位的值能够被截短，就象在RFC2104
中描述的一样。对于ESP或AH的使用，使用高96位的截短值必须被支持。发送时，这个截短
值存储在验证区。接收时，完全的160位值被计算出来，取高96位和存储在验证区的值进行
比较。HMAC-SHA-1-96不支持其他的验证值长度。
   选择96位的原因是因为它是在满足[RFC-2104]描述的安全需要的情况下，[AH]指定的缺省
验证长度。

2.1 性能
   [Bellare96a]声明HMAC的性能从本质上讲就是基本散列函数的性能。所以对于SHA-1，
HMAC，或是HMAC和SHA-1是组合，都没有做详细的性能分析。
   [RFC-2104]概述了一种执行修改，在不影响互操作性的前提下，提高了每个包的性能。

3. 密钥源
   HMAC-SHA-1-96是一种隐秘密钥算法。虽然在[RFC-2104]中没有指定固定的密钥长度，但
和ESP或AH一起使用时，固定的160位的密钥必须被支持，不是160位的密钥一定不被支持
（也就是说，HMAC-SHA-1-96只能使用160位的密钥）。选择160位的密钥长度是在[RFC-2104]
中推荐的（也就是说，比验证器短的密钥长度减弱了安全强度，而比其长的密钥也不能明显的
增强安全强度）。
   [RFC-2104]对密钥源的需求做了讨论，包括对健壮的随机性需求的讨论。必须使用健壮的
伪随机函数来产生需要的160位密钥。
   在写作本文档时，还没有一种指定的不健壮密钥在HMAC中使用。这并不意味着暗示不健壮
的密钥不存在。如果在某些情况下，一套不健壮的密钥被证实在HMAC中使用了，必须拒绝这
些虚弱密钥的使用，然后重新请求交换密钥或是协商一个新的安全联盟。
   当一个单一的SA需要多个密钥时（也就是说，当一个ESP SA需要一个密钥用于机密性，
一个密钥用于验证时），[ARCH]描述了获得密钥源的常规机制。
   为了提供数据源验证，密钥分配机制必须确保唯一的密钥被分配，而且它们只能被分配给
通讯的参与者。
   关于更新密钥，[RFC-2104]做了下面的推荐。当前的攻击不能用作改变密钥频度的推荐参
考（就是说，不能因为没有受到攻击，就总是不更换密钥----译者注），因为这些攻击实际上
都是不可能的。然而定期的更改密钥是保证安全的基础，它帮助我们抵抗潜在的密钥和函数的
不健壮性，减少破译者可以利用的信息，限制由于密钥暴露而带来的危害。

4. 与ESP加密机制的互操作性
   写作本文档时，还没有一种已知的出版物，排除了和任何特定的加密算法一起使用
HMAC-SHA-1-96。

5. 安全考虑
   HMAC-SHA-1-96提供的安全性，主要是基于HMAC的健壮性，更短的使用周期和SHA-1的健
壮性。到写作本文档时为止，还没有一种实际的密码攻击攻破了HMAC-SHA-1-96。
   [RFC-2104]声明了对于“最小的合理散列函数（应该就是真正的伪随机散列函数----译者
注）”，“生日攻击”是不实际的。对于象HMAC-SHA-1-96这样的64位三列块，成功的处理2**80
个数据块的攻击是不可实现的，除非在处理2**30个块后一个潜在的散列冲突被发现。带有虚
弱抵抗冲突特性的这些散列通常认为是不使用的。
   考虑SHA-1从来没有发展为被用做键控散列函数也是很重要的，HMAC有来自攻击的那样的
标准。
   [RFC-2104]也讨论了潜在的附加安全性，包括由结果散列截断带来的安全性问题。包括HMAC
的规范强烈的鼓励使用这种截断散列。
   因为[RFC-2104]为HMAC结合不同的散列算法提供了框架，所以用其他算法象MD5代替
SHA-1是可能的。[RFC-2104]

对于HMAC算法的健壮性和虚弱性有详细的讨论。
   对于任何密码算法，它的健壮性来自算法实现的正确性，密钥管理机制和实现的安全性，
关联的隐秘密钥的健壮性以及所有参与者实现的正确性。[RFC-2202]中有测试向量和例程代码
用于帮助验证HMAC-SHA-1-96代码的正确性。

6. 感谢
   This document is derived in part from previous works by Jim Hughes,those people 
that worked with Jim on the combined DES/CBC+HMAC-MD5ESP transforms, the ANX bakeoff 
participants, and the members of the IPsec working group.
   We would also like to thank Hugo Krawczyk for his comments andrecommendations 
regarding someof the cryptographic specific text in this document.

7. 参考
   [FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,
                April 1995.
                http://csrc.nist.gov/fips/fip180-1.txt (ascii)
                http://csrc.nist.gov/fips/fip180-1.ps  (postscript)

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

   [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: [e-mail]


   Rob Glenn
   NIST

   EMail: [e-mail]

   The IPsec working group can be contacted through the chairs:

   Robert Moskowitz
   ICSA

   EMail: [e-mail]


   Ted T'so
   Massachusetts Institute of Technology

   EMail: [e-mail]

9. 完全版权声明
   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished toothers, 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  befollowed,  or as required to translate it into languages other than
English.

   The limited permissions granted above are perpetual and will not berevoked 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.


RFC2404——The Use of HMAC-SHA-1-96 within ESP and AH
                                                在ESP和AH中使用HMAC-SHA-1-96



1
RFC文档中文翻译计划