Network Working Group T. Li
Request for Comments: 5304 Redback Networks, Inc.
Obsoletes: 3567 R. Atkinson
Updates: 1195 Extreme Networks, Inc.
Category: Standards Track October 2008
Network Working Group T. Li
Request for Comments: 5304 Redback Networks, Inc.
Obsoletes: 3567 R. Atkinson
Updates: 1195 Extreme Networks, Inc.
Category: Standards Track October 2008
IS-IS Cryptographic Authentication
IS-IS加密身份验证
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.
本文件描述了使用RFC 2104中的哈希消息认证码-消息摘要5（HMAC-MD5）算法对中间系统到中间系统（IS-IS）协议数据单元（PDU）的认证。IS-IS在国际标准化组织（ISO）10589中有规定，其扩展支持RFC 1195中描述的Internet协议版本4（IPv4）。基本规范包括一种允许多种身份验证算法的身份验证机制。基本规范仅指定明文密码的算法。本文件取代RFC 3567。
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.
本文档提出了对该规范的扩展，允许将HMAC-MD5认证算法与现有认证机制结合使用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
2.1. Implementation Considerations . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5
3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Key Configuration . . . . . . . . . . . . . . . . . . . . . 6
3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 7
3.5. Future Directions . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
2.1. Implementation Considerations . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. Security Limitations . . . . . . . . . . . . . . . . . . . 5
3.2. Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Key Configuration . . . . . . . . . . . . . . . . . . . . . 6
3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 7
3.5. Future Directions . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
The IS-IS protocol, as specified in [ISO-10589], provides for the authentication of Link State Protocol Data Units (LSPs) through the inclusion of authentication information as part of the LSP. This authentication information is encoded as a Type-Length-Value (TLV) tuple. The use of IS-IS for IPv4 networks is described in [RFC1195].
如[ISO-10589]所述，IS-IS协议通过将认证信息作为LSP的一部分包括在内，提供链路状态协议数据单元（LSP）的认证。此身份验证信息编码为类型长度值（TLV）元组。[RFC1195]中描述了IS-IS在IPv4网络中的使用。
The type of the TLV is specified as 10. The length of the TLV is variable. The value of the TLV depends on the authentication algorithm and related secrets being used. The first octet of the value is used to specify the authentication type. Type 0 is reserved, type 1 indicates a cleartext password, and type 255 is used for routing domain private authentication methods. The remainder of the TLV value is known as the Authentication Value.
TLV的类型指定为10。TLV的长度是可变的。TLV的值取决于所使用的身份验证算法和相关机密。值的第一个八位字节用于指定身份验证类型。类型0是保留的，类型1表示明文密码，类型255用于路由域私有身份验证方法。TLV值的其余部分称为身份验证值。
This document extends the above situation by allocating a new authentication type for HMAC-MD5 and specifying the algorithms for the computation of the Authentication Value. This document also describes modifications to the base protocol to ensure that the authentication mechanisms described in this document are effective.
本文档通过为HMAC-MD5分配新的身份验证类型并指定用于计算身份验证值的算法，扩展了上述情况。本文档还描述了对基本协议的修改，以确保本文档中描述的身份验证机制有效。
This document is a publication of the IS-IS Working Group within the IETF. This document replaces [RFC3567], which is an Informational RFC. This document is on the Standards Track. This document has revised Section 3, with the significant addition of a discussion of recent attacks on MD5 in Section 3.2. This document has also added a substantive "IANA Considerations" section to create a missing codepoint registry.
本文件是IETF内is-is工作组的出版物。本文件取代[RFC3567]，后者是一种信息性RFC。本文件已进入标准轨道。本文件修订了第3节，在第3.2节中增加了对最近MD5攻击的讨论。本文档还添加了实质性的“IANA注意事项”部分，以创建丢失的代码点注册表。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The authentication type used for HMAC-MD5 is 54 (0x36). The length of the Authentication Value for HMAC-MD5 is 16, and the length field in the TLV is 17.
HMAC-MD5使用的身份验证类型为54（0x36）。HMAC-MD5的身份验证值的长度为16，TLV中的长度字段为17。
The HMAC-MD5 algorithm requires a key K and text T as input [RFC2104]. The key K is the password for the PDU type, as specified in ISO 10589. The text T is the IS-IS PDU to be authenticated with the Authentication Value field (inside of the Authentication Information TLV) set to zero. Note that the Authentication Type is set to 54 and the length of the TLV is set to 17 before authentication is computed. When LSPs are authenticated, the
HMAC-MD5算法需要密钥K和文本T作为输入[RFC2104]。密钥K是ISO 10589中规定的PDU类型的密码。文本T是要进行身份验证的is-is PDU，身份验证值字段（在身份验证信息TLV内）设置为零。注意，在计算认证之前，认证类型设置为54，TLV的长度设置为17。当LSP经过身份验证时
Checksum and Remaining Lifetime fields are set to zero (0) before authentication is computed. The result of the algorithm is placed in the Authentication Value field.
在计算身份验证之前，校验和和和剩余生存期字段设置为零（0）。算法的结果放置在“身份验证值”字段中。
When calculating the HMAC-MD5 result for Sequence Number PDUs, Level 1 Sequence Number PDUs SHALL use the Area Authentication string as in Level 1 Link State PDUs. Level 2 Sequence Number PDUs SHALL use the domain authentication string as in Level 2 Link State PDUs. IS-IS Hello PDUs SHALL use the Link Level Authentication String, which MAY be different from that of Link State PDUs. The HMAC-MD5 result for the IS-IS Hello PDUs SHALL be calculated after the packet is padded to the MTU size, if padding is not disabled. Implementations that support the optional checksum for the Sequence Number PDUs and IS-IS Hello PDUs MUST NOT include the Checksum TLV.
当计算序列号PDU的HMAC-MD5结果时，1级序列号PDU应使用1级链路状态PDU中的区域认证字符串。2级序列号PDU应使用2级链路状态PDU中的域身份验证字符串。IS-IS Hello PDU应使用链路级认证字符串，该字符串可能不同于链路状态PDU的认证字符串。如果未禁用填充，则应在将数据包填充到MTU大小后计算IS-IS Hello PDU的HMAC-MD5结果。支持序列号PDU和IS-IS Hello PDU可选校验和的实现不得包括校验和TLV。
To authenticate an incoming PDU, a system should save the values of the Authentication Value field, the Checksum field, and the Remaining Lifetime field, set these fields to zero, compute authentication, and then restore the values of these fields.
要对传入PDU进行身份验证，系统应保存身份验证值字段、校验和字段和剩余生存期字段的值，将这些字段设置为零，计算身份验证，然后恢复这些字段的值。
An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect.
如果身份验证值不正确，则实现HMAC-MD5身份验证并接收HMAC-MD5身份验证信息的实现必须丢弃PDU。
An implementation MAY have a transition mode where it includes HMAC-MD5 Authentication Information in PDUs but does not verify the HMAC-MD5 Authentication Information. This is a transition aid for networks in the process of deploying authentication.
实现可能具有转换模式，其中在PDU中包括HMAC-MD5身份验证信息，但不验证HMAC-MD5身份验证信息。这是部署身份验证过程中网络的过渡辅助工具。
An implementation MAY check a set of passwords when verifying the Authentication Value. This provides a mechanism for incrementally changing passwords in a network.
在验证身份验证值时，实现可以检查一组密码。这提供了一种在网络中增量更改密码的机制。
An implementation that does not implement HMAC-MD5 authentication MAY accept a PDU that contains the HMAC-MD5 Authentication Type. ISes (routers) that implement HMAC-MD5 authentication and initiate LSP purges MUST remove the body of the LSP and add the authentication TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept unauthenticated purges. ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. These restrictions are necessary to prevent a hostile system from receiving an LSP, setting the Remaining Lifetime field to zero, and flooding it, thereby initiating a purge without knowing the authentication password.
未实现HMAC-MD5身份验证的实现可以接受包含HMAC-MD5身份验证类型的PDU。实现HMAC-MD5身份验证并启动LSP清除的ISE（路由器）必须移除LSP主体并添加身份验证TLV。实现HMAC-MD5身份验证的ISE不得接受未经验证的清除。ISE不得接受包含认证TLV以外的TLV的清除。这些限制对于防止恶意系统接收LSP、将剩余生存期字段设置为零并将其淹没，从而在不知道身份验证密码的情况下启动清除是必要的。
There is an implementation issue that occurs just after password rollover on an IS-IS router and that might benefit from additional commentary. Immediately after password rollover on the router, the router or IS-IS process may restart. If this happens, this causes the LSP Sequence Number to restart from the value 1 using the new password. However, neighbors will reject those new LSPs because the Sequence Number is smaller. The router cannot increase its own LSP Sequence Number because it fails to authenticate its own old LSP that neighbors keep sending to it. So the router cannot update its LSP Sequence Number to its neighbors until all the neighbors time out all of the original LSPs. One possible solution to this problem is for the IS-IS process to detect if any inbound LSP with an authentication failure has the local System ID and also has a higher Sequence Number than the IS-IS process has. In this event, the IS-IS process SHOULD increase its own LSP Sequence Number accordingly and re-flood the LSPs. However, as this scenario could also be triggered by an active attack by an adversary, it is recommended that a counter be kept on this case to mitigate the risk from such an attack.
在is-is路由器上的密码翻转之后，会出现一个实现问题，这可能会从其他注释中受益。路由器上的密码翻转后，路由器或IS-IS进程可能会立即重新启动。如果发生这种情况，这将导致LSP序列号使用新密码从值1重新启动。但是，邻居将拒绝这些新的LSP，因为序列号较小。路由器无法增加自己的LSP序列号，因为它无法验证邻居一直发送给它的自己的旧LSP。因此，在所有邻居超时所有原始LSP之前，路由器无法将其LSP序列号更新到其邻居。此问题的一个可能解决方案是is-is进程检测任何身份验证失败的入站LSP是否具有本地系统ID，并且序列号是否高于is-is进程。在这种情况下，IS-IS进程应相应地增加其自身的LSP序列号，并重新填充LSP。但是，由于这种情况也可能由对手的主动攻击触发，因此建议在这种情况下保留一个计数器，以降低此类攻击的风险。
This document enhances the security of the IS-IS routing protocol. Because a routing protocol contains information that need not be kept secret, privacy is not a requirement. However, authentication of the messages within the protocol is of interest in order to reduce the risk of an adversary compromising the routing system by deliberately injecting false information into that system.
本文档增强了IS-IS路由协议的安全性。因为路由协议包含不需要保密的信息，所以不需要保密。然而，为了降低敌方故意向路由系统中注入虚假信息而危及路由系统的风险，需要对协议中的消息进行身份验证。
The technology in this document provides an authentication mechanism for IS-IS. The mechanism described here is not perfect and does not need to be perfect. Instead, this mechanism represents a significant increase in the work function of an adversary attacking the IS-IS protocol, while not causing undue implementation, deployment, or operational complexity. It provides improved security against passive attacks, as defined in [RFC1704], when compared to cleartext password authentication.
本文档中的技术为IS-IS提供了一种身份验证机制。这里描述的机制并不完美，也不需要完美。相反，该机制代表了攻击IS-IS协议的对手的工作功能的显著增加，同时不会导致不适当的实现、部署或操作复杂性。与明文密码认证相比，它提供了改进的针对被动攻击的安全性，如[RFC1704]中所定义。
This mechanism does not prevent replay attacks; however, in most cases, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information. Denial-of-service attacks are not generally preventable in a useful networking protocol [DoS].
这种机制不能防止重播攻击；然而，在大多数情况下，此类攻击会触发IS-IS协议中的现有机制，从而有效地拒绝旧信息。在有用的网络协议[DoS]中，拒绝服务攻击通常是不可预防的。
The mechanisms in this document do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions that affect the whole routing domain. The reader is encouraged to consult [RFC4593] for a more comprehensive description of threats to routing protocols.
本文档中的机制不提供针对受损、故障或错误配置路由器的保护。这种路由器可能会意外或故意导致影响整个路由域的故障。鼓励读者参考[RFC4593]，以获得对路由协议威胁的更全面描述。
Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in all communicating IS-IS implementations. This mechanism also depends on the IS-IS Authentication Key being kept confidential by all parties. If any of these are incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism.
用户需要了解，该机制提供的安全性的质量完全取决于所实现的身份验证算法的强度、所使用的密钥的强度以及所有通信IS-IS实现中安全机制的正确实现。该机制还取决于各方对IS-IS认证密钥保密。如果其中任何一项不正确或不够安全，则不会为该机制的用户提供真正的安全性。
Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were first published a dozen years ago, there have been growing concerns about the effectiveness of the compression function within MD5. More recent work by Wang and Yu [WY05] accentuates these concerns. However, despite these research results, there are no published attacks at present on either Keyed-MD5 or HMAC-MD5. A recent paper by Bellare [Bell06a] [Bell06b] provides new proofs for the security of HMAC that require fewer assumptions than previous published proofs for HMAC. Those proofs indicate that the published issues with MD5 (and separately with SHA-1) do not create an attack on HMAC-MD5 (or HMAC SHA-1). Most recently, Fouque and others [FLN07] have published new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5. However, their attacks are non-trivial computationally, and they have not found an equivalent attack on HMAC-MD5. So, despite the published issues with the MD5 algorithm, there is currently no published attack that applies to HMAC-MD5 as used in this IS-IS specification. As with any cryptographic technique, there is the possibility of the discovery of future attacks against this mechanism.
自从十几年前Dobbertin对MD5[Dobb96a][Dobb96b][Dobb98]的攻击首次发表以来，人们越来越担心MD5中压缩功能的有效性。王和余最近的工作[WY05]强调了这些担忧。然而，尽管有这些研究结果，目前还没有针对Keyed-MD5或HMAC-MD5的公开攻击。Bellare[Bell06a][Bell06b]最近发表的一篇论文为HMAC的安全性提供了新的证明，与之前发表的HMAC证明相比，该证明需要更少的假设。这些证据表明，MD5（以及单独与SHA-1）发布的版本不会对HMAC-MD5（或HMAC SHA-1）造成攻击。最近，Fouque和其他[FLN07]发布了针对NMAC-MD4、HMAC-MD4和NMAC-MD5的新攻击。然而，他们的攻击在计算上是不平凡的，并且他们还没有在HMAC-MD5上发现等价的攻击。因此，尽管MD5算法存在公开的问题，但目前还没有公开的攻击适用于本is-is规范中使用的HMAC-MD5。与任何加密技术一样，未来可能会发现针对该机制的攻击。
It should be noted that the key configuration mechanism of routers may restrict the possible keys that may be used between peers. It is strongly recommended that an implementation be able to support, at minimum, a key composed of a string of printable ASCII of 80 bytes or less, as this is current practice.
应当注意，路由器的密钥配置机制可以限制对等方之间可能使用的密钥。强烈建议实现至少能够支持由80字节或更少的可打印ASCII字符串组成的键，因为这是当前的做法。
Changes to the authentication mechanism described here (primarily: to add a Key-ID field such as that of OSPFv2 and RIPv2) were considered at some length, but ultimately were rejected. The mechanism here was already widely implemented in 1999. As of this writing, this mechanism is fairly widely deployed within the users interested in cryptographic authentication of IS-IS. The improvement provided by the proposed revised mechanism was not large enough to justify the change, given the installed base and lack of operator interest in deploying a revised mechanism.
此处描述的认证机制的更改（主要是：添加密钥ID字段，如OSPFv2和RIPv2的密钥ID字段）经过了一定的考虑，但最终被拒绝。该机制已于1999年广泛实施。在撰写本文时，该机制在对is-is加密身份验证感兴趣的用户中得到了相当广泛的部署。考虑到安装基数和运营商对部署经修订的机制缺乏兴趣，拟议的经修订的机制所提供的改进不够大，不足以证明这一改变是合理的。
If and when a key management protocol appears that is both widely implemented and easily deployed to secure routing protocols such as IS-IS, a different authentication mechanism that is designed for use with that key management schema could be added if desired.
如果出现广泛实施且易于部署到安全路由协议（如is-is）的密钥管理协议，如果需要，可以添加设计用于该密钥管理模式的不同身份验证机制。
If a stronger authentication were believed to be required, then the use of a full digital signature [RFC2154] would be an approach that should be seriously considered. It was rejected for this purpose at this time because the computational burden of full digital signatures is believed to be much higher than is reasonable, given the current threat environment in operational commercial networks.
如果认为需要更强的认证，那么使用完整数字签名[RFC2154]将是一种值得认真考虑的方法。鉴于商业运营网络中当前的威胁环境，人们认为完整数字签名的计算负担远远高于合理的计算负担，因此，目前拒绝了该方案。
If and when additional authentication mechanisms are defined (for example, to provide a cryptographically stronger hash function), it will also be necessary to define mechanisms that allow graceful transition from the existing mechanisms (as defined in this document) to any future mechanism.
如果定义了其他身份验证机制（例如，提供加密更强的哈希函数），则还需要定义允许从现有机制（如本文档中所定义）到任何未来机制的优雅过渡的机制。
IANA has created a new codepoint registry to administer the Authentication Type codepoints for TLV 10. This registry is part of the existing IS-IS codepoints registry as established by [RFC3563] and [RFC3359]. This registry is managed using the Designated Expert policy as described in [RFC5226] and is called "IS-IS Authentication Type Codes for TLV 10".
IANA已经创建了一个新的代码点注册表来管理TLV 10的认证类型代码点。此注册表是[RFC3563]和[RFC3359]建立的现有is-is代码点注册表的一部分。该注册表使用[RFC5226]中所述的指定专家策略进行管理，称为“TLV 10的is-is认证类型代码”。
The values in the "IS-IS Authentication Type Codes for TLV 10" registry should be recorded in decimal and should only be approved after a designated expert, appointed by the IESG area director, has been consulted. The intention is that any allocation will be accompanied by a published RFC. However, the designated expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the
“TLV 10 IS-IS认证类型代码”注册表中的值应以十进制记录，并且只有在咨询了IESG区域总监指定的专家后，才应予以批准。其目的是，任何分配都将附带公布的RFC。但是，一旦确定RFC将发布，指定专家可以批准分配，允许在发布之前分配值
document being approved for publication as an RFC. New items should be documented in a publicly and freely available specification. We should also allow external specifications to allocate and use the IS-IS Authentication Type Codes maintained by this registry.
批准作为RFC发布的文件。新项目应记录在公开和免费提供的规范中。我们还应该允许外部规范分配和使用此注册表维护的IS-IS身份验证类型代码。
Initial values for the "IS-IS Authentication Type Codes for TLV 10" registry are given below; future assignments are to be made through Expert Review. Assignments consist of an authentication type name and its associated value.
“TLV 10 IS-IS认证类型代码”注册表的初始值如下所示；未来的任务将通过专家评审完成。分配由身份验证类型名称及其关联值组成。
+---------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+---------------------------------------------+-------+-------------+
| Reserved | 0 | [ISO-10589] |
| Cleartext Password | 1 | [ISO-10589] |
| ISO 10589 Reserved | 2 | [ISO-10589] |
| HMAC-MD5 Authentication | 54 | RFC 5304 |
| Routeing Domain private authentication | 255 | [ISO-10589] |
| method | | |
+---------------------------------------------+-------+-------------+
+---------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+---------------------------------------------+-------+-------------+
| Reserved | 0 | [ISO-10589] |
| Cleartext Password | 1 | [ISO-10589] |
| ISO 10589 Reserved | 2 | [ISO-10589] |
| HMAC-MD5 Authentication | 54 | RFC 5304 |
| Routeing Domain private authentication | 255 | [ISO-10589] |
| method | | |
+---------------------------------------------+-------+-------------+
The authors would like to thank (in alphabetical order) Stephen Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their comments and suggestions on this document.
作者要感谢（按字母顺序排列）斯蒂芬·法雷尔、戴夫·卡茨、史蒂文·梁、托尼·普齐吉恩达、沈乃明和亨克·斯密特对本文件的评论和建议。
[ISO-10589] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589:2002, Second Edition, 2002.
[ISO-10589]ISO，“与提供无连接模式网络服务协议（ISO 8473）一起使用的中间系统到中间系统域内路由信息交换协议”，国际标准10589:2002，第二版，2002年。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Bell06a] Bellare, M., "New Proofs for NMAC and HMAC: Security without Collision-Resistance", Preliminary Version, in Proceedings of Crypto 2006, Lecture Notes in Computer Science, Vol. 4117, August 2006.
[Bell06a]Bellare，M.，“NMAC和HMAC的新证明：无抗碰撞的安全性”，初步版本，载于《2006年密码会议录》，计算机科学讲稿，第41172006年8月。
[Bell06b] Bellare, M., "New Proofs for NMAC and HMAC: Security without Collision-Resistance", August 2006, <http:// www-cse.ucsd.edu/users/mihir/papers/hmac-new.html>.
[Bell06b]Bellare，M.，“NMAC和HMAC的新证明：无冲突的安全性”，2006年8月，<http://www.cse.ucsd.edu/users/mihir/papers/HMAC New.html>。
[DoS] Voydock, V. and S. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys Vol. 15, No. 2, June 1983.
[DoS]Voydock，V.和S.Kent，“高级网络中的安全机制”，ACM计算调查第15卷，第2期，1983年6月。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt Rump Session 1996, May 1996.
[Dobb96a]Dobbertin，H.，“MD5压缩的密码分析”，EuroCrypt Rump Session 1996，1996年5月。
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes, Vol. 2, No. 2, 1996.
[Dobb96b]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes，第2卷，第2期，1996年。
[Dobb98] Dobbertin, H., "Cryptanalysis of MD4", Journal of Cryptology, Vol. 11, No. 4, 1998.
[Dobb98]Dobbertin，H.，“MD4的密码分析”，《密码学杂志》，第11卷，第4期，1998年。
[FLN07] Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of Crypto 2007, August 2007.
[FLN07]Fouke，P.，Leurent，G.和P.Nguyen，“对HMAC/NMAC-MD5和NMAC-MD5的全密钥恢复攻击”，加密程序2007年，2007年8月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704]Haller，N.和R.Atkinson，“互联网认证”，RFC17041994年10月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
[RFC3359]Przygienda，T，“中间系统到中间系统中的保留类型、长度和值（TLV）码点”，RFC 3359，2002年8月。
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 3563, July 2003.
[RFC3563]Zinin，A.“ISO/IETF和ISO/IEC联合技术委员会1/第6分委员会（JTC1/SC6）之间关于IS-IS路由协议开发的合作协议”，RFC 3563，2003年7月。
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC3567]Li，T.和R.Atkinson，“中间系统到中间系统（IS-IS）加密认证”，RFC 3567，2003年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[WY05] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science, Vol. 3494, 2005.
[WY05]Wang，X.和H.Yu，“如何破解MD5和其他哈希函数”，《EuroCrypt 2005年论文集》，计算机科学课堂讲稿，第34942005卷。
Authors' Addresses
作者地址
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks，Inc.美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
Phone: +1 408 750 5160
EMail: tony.li@tony.li
Phone: +1 408 750 5160
EMail: tony.li@tony.li
R. Atkinson Extreme Networks, Inc. 3585 Monroe St. Santa Clara, CA 95051 USA
R.阿特金森极端网络公司，美国加利福尼亚州圣克拉拉门罗街3585号，邮编95051
Phone: +1 408 579 2800
EMail: rja@extremenetworks.com
Phone: +1 408 579 2800
EMail: rja@extremenetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.