本备忘录状态
本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进提出了讨论和建议。
请参考最新版本的"InternetOfficialProtocolStandards"(STD1)来获得本协议的标准化进程
和状态，此备忘录的发布不受任何限制。
版权注重
版权归因特网协会所有，保留一切权利。
摘要
本备忘录描述了在修订的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","MUSTNOT","REQUIRED","SHALL","SHALL
NOT","SHOULD",
"SHOULDNOT","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位值可以向在FRC2104中描述的那样删
减。为了在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需要多个密钥时（也就是说当一个ESPSA需要一个加密密钥和一个验
证密钥），[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.感谢
本文档部分源于JimHughes先前的工作，和Jim一起为组合DES/CBC+HMAC-MD5ESP
转换工作的人们，ANXbakeoff的参与者和IPsec工作组的成员。
我们也很兴奋感谢为本文档中的一些非凡内容提出意见和解释的HugoKrawczyk先生。
7.参考
[RFC-1321]Rivest,R.,"MD5DigestAlgorithm",RFC1321,April
1992.
[RFC-2104]Krawczyk,H.,Bellare,M.,andR.Canetti,"HMAC:
Keyed-HashingforMessageAuthentication",RFC2104,
February1997.
[RFC-1810]ToUCh,J.,"ReportonMD5Performance",RFC1810,June
1995.
[Bellare96a]Bellare,M.,Canetti,R.,andH.Krawczyk,"KeyingHash
FunctionsforMessageAuthentication",Advancesin
Cryptography,Crypto96Proceeding,June1996.
[ARCH]Kent,S.,andR.Atkinson,"SecurityArchitecturefor
theInternetProtocol",RFC2401,November1998.
[ESP]Kent,S.,andR.Atkinson,"IPEncapsulatingSecurity
Payload",RFC2406,November1998.
[AH]Kent,S.,andR.Atkinson,"IPAuthenticationHeader",
RFC2402,November1998.
[Thayer97a]Thayer,R.,Doraswamy,N.,andR.Glenn,"IPSecurity
DocumentRoadmap",RFC2411,November1998.
[RFC-2202]Cheng,P.,andR.Glenn,"TestCasesforHMAC-MD5and
HMAC-SHA-1",RFC2202,March1997.
[RFC-2119]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
8.编者地址
CherylMadson
CiscoSystems,Inc.
EMail:cmadson@cisco.com
RobGlenn
NIST
EMail:<rob.glenn@nist.gov>
TheIPsecworkinggroupcanbecontactedthroughthechairs:
RobertMoskowitz
ICSA
EMail:rgm@icsa.net
TedT'so
MassachusettsInstituteofTechnology
EMail:tytso@mit.edu
9.全部版权声明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
RFC2403——RFC2403TheUseofHMAC-MD5-96withinESPandAH
