Network Working Group M. Bhatia
Request for Comments: 5310 Alcatel-Lucent
Category: Standards Track V. Manral
IP Infusion
T. Li
Redback Networks Inc.
R. Atkinson
Extreme Networks
R. White
Cisco Systems
M. Fanto
Aegis Data Security
February 2009
Network Working Group M. Bhatia
Request for Comments: 5310 Alcatel-Lucent
Category: Standards Track V. Manral
IP Infusion
T. Li
Redback Networks Inc.
R. Atkinson
Extreme Networks
R. White
Cisco Systems
M. Fanto
Aegis Data Security
February 2009
IS-IS Generic 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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.
本文件提出了对中间系统到中间系统（IS-IS）的扩展，以允许在基本规范和RFC 5304中描述的已记录的认证方案之外使用任何加密认证算法。IS-IS在国际标准化组织（ISO）10589中有规定，其扩展支持RFC 1195中描述的Internet协议版本4（IPv4）。
Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.
尽管本文档是专门为使用哈希消息认证码（HMAC）构造以及加密哈希函数的安全哈希算法（SHA）系列而编写的，但本文档中描述的方法是通用的，可用于扩展is-is以支持将来的任何加密哈希函数。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IS-IS Security Association ......................................3
3. Authentication Procedures .......................................4
3.1. Authentication TLV .........................................4
3.2. Authentication Process .....................................5
3.3. Cryptographic Aspects ......................................5
3.4. Procedures at the Sending Side .............................7
3.5. Procedure at the Receiving Side ............................8
4. Security Considerations .........................................8
5. Acknowledgments .................................................9
6. IANA Considerations ............................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IS-IS Security Association ......................................3
3. Authentication Procedures .......................................4
3.1. Authentication TLV .........................................4
3.2. Authentication Process .....................................5
3.3. Cryptographic Aspects ......................................5
3.4. Procedures at the Sending Side .............................7
3.5. Procedure at the Receiving Side ............................8
4. Security Considerations .........................................8
5. Acknowledgments .................................................9
6. IANA Considerations ............................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
The Intermediate System to Intermediate System (IS-IS) specification ([ISO], [RFC1195]) allows for authentication of its Protocol Data Units (PDUs) via the authentication TLV 10 that is carried as a part of the PDU. The base specification has provision for only cleartext passwords and RFC 5304 [RFC5304] augments this to provide the capability to use Hashed Message Authentication Code - Message Digest 5 (HMAC-MD5) authentication for its PDUs.
中间系统到中间系统（IS-IS）规范（[ISO]、[RFC1195]）允许通过作为PDU一部分携带的认证TLV 10对其协议数据单元（PDU）进行认证。基本规范仅提供明文密码，RFC 5304[RFC5304]对此进行了扩展，以提供对其PDU使用哈希消息认证代码-消息摘要5（HMAC-MD5）认证的能力。
The first octet of the value field of TLV 10 specifies the type of authentication to be carried out. Type 0 is reserved, Type 1 indicates a cleartext password, Type 54 indicates HMAC MD5, and Type 255 is used for routing domain private authentication methods. The remainder of the value field contains the actual authentication data, determined by the value of the authentication type.
TLV 10的值字段的第一个八位字节指定要执行的身份验证类型。类型0是保留的，类型1表示明文密码，类型54表示HMAC MD5，类型255用于路由域私有身份验证方法。值字段的其余部分包含由身份验证类型的值确定的实际身份验证数据。
This document proposes a new authentication type to be carried in TLV 10, called the generic cryptographic authentication (CRYPTO_AUTH). This can be used to specify any authentication algorithm for authenticating and verifying IS-IS PDUs.
本文件提出了TLV 10中的一种新认证类型，称为通用加密认证（CRYPTO_AUTH）。这可用于指定用于验证和验证IS-IS PDU的任何验证算法。
This document also explains how HMAC-SHA authentication can be used in IS-IS.
本文档还解释了如何在IS-IS中使用HMAC-SHA身份验证。
By definition, HMAC ([RFC2104], [FIPS-198]) requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 [FIPS-180-3] to authenticate the IS-IS PDUs.
根据定义，HMAC（[RFC2104]，[FIPS-198]）需要加密哈希函数。我们建议使用SHA-1、SHA-224、SHA-256、SHA-384或SHA-512[FIPS-180-3]中的任何一种来验证IS-IS PDU。
We propose to do away with the per-interface keys and instead have Key IDs that map to unique IS-IS Security Associations (SAs).
我们建议取消每个接口的密钥，而是使用映射到唯一IS-IS安全关联（SA）的密钥ID。
While at the time of this writing there are no openly published attacks on the HMAC-MD5 mechanism, some reports ([Dobb96a], [Dobb96b]) create concern about the ultimate strength of the MD5 cryptographic hash function.
虽然在撰写本文时，没有公开发布对HMAC-MD5机制的攻击，但一些报告（[Dobb96a]、[Dobb96b]）引起了对MD5加密哈希函数极限强度的担忧。
The mechanism described in this document does not provide confidentiality, since PDUs are sent in the clear. However, the objective of a routing protocol is to advertise the routing topology, and confidentiality is not normally required for routing protocols.
本文档中描述的机制不提供机密性，因为PDU以明文形式发送。然而，路由协议的目标是公布路由拓扑，路由协议通常不需要保密性。
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]中所述进行解释。
An IS-IS Security Association contains a set of parameters shared between any two legitimate IS-IS speakers.
IS-IS安全关联包含任意两个合法IS-IS扬声器之间共享的一组参数。
Parameters associated with an IS-IS SA:
与IS-IS SA关联的参数：
o Key Identifier (Key ID): This is a two-octet unsigned integer used to uniquely identify an IS-IS SA, as manually configured by the network operator.
o 密钥标识符（密钥ID）：这是一个两个八位组的无符号整数，用于唯一标识is-is SA，由网络运营商手动配置。
The receiver determines the active SA by looking at the Key ID field in the incoming PDU.
接收器通过查看传入PDU中的密钥ID字段来确定活动SA。
The sender, based on the active configuration, selects the Security Association to use and puts the correct Key ID value associated with the Security Association in the IS-IS PDU. If multiple valid and active IS-IS Security Associations exist for a given outbound interface at the time an IS-IS PDU is sent, the sender may use any of those Security Associations to protect the packet.
发送方根据活动配置选择要使用的安全关联，并将与安全关联关联的正确密钥ID值放入IS-IS PDU中。如果在发送IS-IS PDU时给定出站接口存在多个有效且活动的IS-IS安全关联，则发送方可以使用这些安全关联中的任何一个来保护数据包。
Using Key IDs makes changing keys while maintaining protocol operation convenient. Each Key ID specifies two independent parts: the authentication protocol and the authentication key, explained below. Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
使用密钥ID可以在维护协议操作的同时方便地更改密钥。每个密钥ID指定两个独立的部分：身份验证协议和身份验证密钥，如下所述。通常，实现将允许网络运营商在密钥链中配置一组密钥，其中链中的每个密钥具有固定的生存期。这些机制的实际运作超出了本文件的范围。
Note that each Key ID can indicate a key with a different authentication protocol. This allows multiple authentication mechanisms to be used at various times without disrupting an IS-IS peering, including the introduction of new authentication mechanisms.
请注意，每个密钥ID可以表示具有不同身份验证协议的密钥。这允许在不同时间使用多个身份验证机制，而不会中断IS-IS对等，包括引入新的身份验证机制。
o Authentication Algorithm: This signifies the authentication algorithm to be used with the IS-IS SA. This information is never sent in cleartext over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
o 身份验证算法：这表示要与IS-IS SA一起使用的身份验证算法。此信息从不以明文形式通过网络发送。因为该信息不是通过线路发送的，所以实现者为该信息选择了特定于实现的表示。目前，以下值是可能的：HMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512。
o Authentication Key: This value denotes the cryptographic authentication key associated with the IS-IS SA. The length of this key is variable and depends upon the authentication algorithm specified by the IS-IS SA.
o 身份验证密钥：该值表示与IS-IS SA关联的加密身份验证密钥。此密钥的长度是可变的，取决于is-is SA指定的身份验证算法。
A new authentication code, 3, indicates that the CRYPTO_AUTH mechanism described in this document is in use and is inserted in the first octet of the existing IS-IS Authentication TLV (10).
新的身份验证代码3表示本文档中描述的加密身份验证机制正在使用，并插入到现有is-is身份验证TLV（10）的第一个八位组中。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+
| Type 10 |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+
| Auth Type 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+ +
| Authentication Data (Variable)|
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+
| Type 10 |
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+
| Auth Type 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+ +
| Authentication Data (Variable)|
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
图1
When calculating the CRYPTO_AUTH 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.
当计算序列号PDU的加密验证结果时，1级序列号PDU应使用区域验证字符串，如在1级链路状态PDU中。2级序列号PDU应使用域身份验证字符串，如2级链路状态PDU。
IS-IS HELLO PDUs SHALL use the Link Level Authentication string, which MAY be different from that of Link State PDUs. The CRYPTO_AUTH result for the IS-IS HELLO PDUs SHALL be calculated after the PDU 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.
IS-IS HELLO PDU应使用链路级认证字符串，该字符串可能不同于链路状态PDU的认证字符串。如果未禁用填充，则应在将PDU填充到MTU大小后计算IS-IS HELLO PDU的加密验证结果。支持序列号PDU和IS-IS HELLO PDU可选校验和的实现不得包括校验和TLV。
In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198] is used:
在下面的算法描述中，使用了与[FIPS-198]一致的以下术语：
H is the specific hashing algorithm (e.g., SHA-256). K is the password for the PDU type as per the International Standard ISO/IEC 10589 [ISO]. Ko is the cryptographic key used with the hash algorithm.
H是特定的散列算法（例如，SHA-256）。K是国际标准ISO/IEC 10589[ISO]规定的PDU类型的密码。Ko是与哈希算法一起使用的加密密钥。
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
L是散列的长度，以八位字节而不是位来度量。
XOR is the exclusive-or operation.
XOR是异或运算。
Opad is the hexadecimal value 0x5c repeated B times. Ipad is the hexadecimal value 0x36 repeated B times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
Opad是十六进制值0x5c，重复B次。Ipad是十六进制值0x36，重复B次。Apad是十六进制值0x878FE1F3，重复（1/4）次。
(1) Preparation of the Key
(1) 钥匙的准备
In this application, Ko is always L octets long.
在此应用程序中，Ko的长度始终为L个八位字节。
If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K) such that Ko is L octets long.
如果身份验证密钥（K）的长度为L个八位字节，则Ko等于K。如果身份验证密钥（K）的长度超过L个八位字节，则Ko设置为H（K）。如果认证密钥（K）的长度小于L个八位字节，则将Ko设置为认证密钥（K），并在认证密钥（K）的末尾附加零，使得Ko的长度为L个八位字节。
(2) First Hash
(2) 第一散列
First, the IS-IS packet's Authentication Data field is filled with the value Apad, and the Authentication Type field is set to 0x3.
首先，IS-IS数据包的身份验证数据字段填充值Apad，并且身份验证类型字段设置为0x3。
Then, a first hash, also known as the inner hash, is computed as follows:
然后，第一散列（也称为内部散列）计算如下：
First-Hash = H(Ko XOR Ipad || (IS-IS PDU))
第一个Hash=H（Ko-XOR-Ipad | | |（IS-IS-PDU））
(3) Second Hash
(3) 第二散列
Then a second hash, also known as the outer hash, is computed as follows:
然后，第二个散列（也称为外部散列）计算如下：
Second-Hash = H(Ko XOR Opad || First-Hash)
第二个散列=H（Ko-XOR-Opad | |第一个散列）
(4) Result
(4) 后果
The resulting second hash becomes the authentication data that is sent in the Authentication Data field of the IS-IS PDU. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used.
产生的第二散列成为在is-is PDU的认证数据字段中发送的认证数据。身份验证数据字段的长度始终与正在使用的特定哈希函数H的消息摘要大小相同。
This also means that the use of hash functions with larger output sizes will also increase the size of the IS-IS PDU as transmitted on the wire.
这也意味着使用输出大小较大的散列函数也会增加在线路上传输的IS-IS PDU的大小。
An appropriate IS-IS SA is selected for use with an outgoing IS-IS PDU. This is done based on the active key at that instant. If IS-IS is unable to find an active key, then the PDU is discarded.
选择适当的IS-IS SA与输出IS-IS PDU一起使用。这是基于当时的活动键完成的。如果IS-IS无法找到活动密钥，则PDU将被丢弃。
If IS-IS is able to find the active key, then the key provides the authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512) that needs to be applied on the PDU.
如果IS-IS能够找到活动密钥，则该密钥提供需要在PDU上应用的身份验证算法（HMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384或HMAC-SHA-512）。
An implementation MUST fill the authentication type and the length before the authentication data is computed. The authentication data is computed as explained in the previous section. The length of the TLV is set as per the authentication algorithm that is being used.
在计算身份验证数据之前，实现必须填写身份验证类型和长度。验证数据的计算如前一节所述。TLV的长度根据正在使用的身份验证算法进行设置。
The length is set to 23 for HMAC-SHA-1, 31 for HMAC-SHA-224, 35 for HMAC-SHA-256, 51 for HMAC-SHA-384, and 67 for HMAC-SHA-512. Note that two octets have been added to account for the Key ID and one octet for the authentication type.
HMAC-SHA-1的长度设置为23，HMAC-SHA-224的长度设置为31，HMAC-SHA-256的长度设置为35，HMAC-SHA-384的长度设置为51，HMAC-SHA-512的长度设置为67。请注意，添加了两个八位字节以表示密钥ID，添加了一个八位字节以表示身份验证类型。
The Key ID is filled.
密钥ID已填充。
The Checksum and Remaining Lifetime fields are set to zero for the Link State Packets (LSPs) before authentication is calculated.
在计算身份验证之前，将链路状态数据包（LSP）的校验和和剩余生存期字段设置为零。
The result of the authentication algorithm is placed in the authentication data, following the Key ID.
认证算法的结果放在认证数据中，紧跟着密钥ID。
The authentication data for the IS-IS IIH PDUs MUST be computed after the IS-IS Hello (IIH) has been padded to the MTU size, if padding is not explicitly disabled.
如果未明确禁用填充，则必须在将IS-IS Hello（IIH）填充到MTU大小后计算IS-IS IIH PDU的身份验证数据。
The appropriate IS-IS SA is identified by looking at the Key ID from the Authentication TLV 10 from the incoming IS-IS PDU.
通过查看来自传入IS-IS PDU的认证TLV 10的密钥ID来识别适当的IS-IS SA。
Authentication-algorithm-dependent processing needs to be performed, using the algorithm specified by the appropriate IS-IS SA for the received packet.
需要使用适当的IS-IS SA为接收的数据包指定的算法来执行认证算法相关的处理。
Before an implementation performs any processing, it needs to save the values of the Authentication Value, the Checksum, and the Remaining Lifetime fields.
在实现执行任何处理之前，它需要保存身份验证值、校验和以及剩余生存期字段的值。
It should then set the Authentication Value field with Apad and the Checksum and Remaining Lifetime fields with zero before the authentication data is computed. The calculated data is compared with the received authentication data in the PDU, and the PDU is discarded if the two do not match. In such a case, an error event SHOULD be logged.
然后，在计算身份验证数据之前，它应该将身份验证值字段设置为Apad，将校验和和剩余生存期字段设置为零。将计算出的数据与PDU中接收到的身份验证数据进行比较，如果两者不匹配，则丢弃PDU。在这种情况下，应记录错误事件。
An implementation MAY have a transition mode where it includes CRYPTO_AUTH information in the PDUs but does not verify this information. This is provided as a transition aid for networks in the process of migrating to the new CRYPTO_AUTH-based authentication schemes.
实现可能具有转换模式，其中在PDU中包含加密验证信息，但不验证该信息。这是在迁移到新的基于加密身份验证方案的过程中为网络提供的过渡帮助。
This document proposes extensions to IS-IS that make it more secure than what it is today. It does not provide confidentiality as a routing protocol contains information that does not need to be kept secret. It does, however, provide means to authenticate the sender of the PDUs, which is of interest to us.
本文档建议对IS-IS进行扩展，使其比现在更安全。它不提供机密性，因为路由协议包含不需要保密的信息。但是，它确实提供了对我们感兴趣的PDU发送方进行身份验证的方法。
It should be noted that authentication method described in this document is not being used to authenticate the specific originator of a PDU, but is rather being used to confirm that the PDU has indeed been issued by an intermediate system that had access to either the area or domain password, depending upon the kind of PDU it is.
应注意，本文件中描述的认证方法不是用于认证PDU的特定发起人，而是用于确认PDU确实是由能够访问区域或域密码的中间系统发布的，具体取决于PDU的类型。
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.
这里描述的机制并不完美，也不需要完美。相反，该机制代表了攻击IS-IS协议的对手的工作功能的显著增加，同时不会导致不适当的实现、部署或操作复杂性。
The mechanism detailed in this document does not protect IS-IS against replay attacks. An adversary could in theory replay old IIHs and bring down the adjacency [CRYPTO] or replay old Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) that would cause a flood of LSPs in the network. Using some sort of crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to solve this problem. Discussing this is beyond the scope of this document.
本文档中详述的机制不保护IS-IS免受重播攻击。理论上，敌方可以重放旧的IIH并关闭邻接[加密]或重放旧的完整序列号PDU（CSNPs）和部分序列号PDU（PSNPs），这将导致网络中LSP泛滥。在IS-IS IIHs和CSNP/PSNPs中使用某种加密序列号是解决此问题的一种选择。讨论这一点超出了本文件的范围。
This document states that the remaining lifetime of the LSP MUST be set to zero before computing the authentication, thus this field is not authenticated. This field is excluded so that the LSPs may be aged by the ISes in between, without requiring re-computation of the authentication data. This can be exploited by an attacker.
本文档声明，在计算身份验证之前，LSP的剩余生存期必须设置为零，因此此字段未经身份验证。该字段被排除，以便lsp可以被中间的ise老化，而不需要重新计算认证数据。攻击者可以利用此漏洞。
There is a transition mode suggested where routers can ignore the CRYPTO_AUTH information carried in the PDUs. The operator must ensure that this mode is only used when migrating to the new CRYPTO_AUTH-based authentication scheme, as this leaves the router vulnerable to an attack.
建议使用一种过渡模式，路由器可以忽略PDU中携带的加密验证信息。运营商必须确保仅在迁移到新的基于CRYPTO_AUTH的身份验证方案时使用此模式，因为这会使路由器容易受到攻击。
To ensure greater security, the keys used should be changed periodically, and implementations MUST be able to store and use more than one key at the same time. Operators should ensure that the authentication key is never sent over the network in cleartext via any protocol. Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.
为了确保更高的安全性，应该定期更改使用的密钥，并且实现必须能够同时存储和使用多个密钥。运营商应确保认证密钥从未通过任何协议以明文形式通过网络发送。还应注意确保所选密钥是不可预测的，避免使用已知算法较弱的任何密钥。[RFC4086]包含有关密钥生成技术和密码随机性的有用信息。
It should be noted that the cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function and on the size and quality of the key.
应当注意，HMAC的加密强度取决于底层散列函数的加密强度以及密钥的大小和质量。
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]将是一种值得认真考虑的方法。鉴于商业运营网络中当前的威胁环境，完全数字签名的计算负担被认为比合理的要高得多，因此在此时被拒绝。
The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell Labs), and Eric Grosse (Bell Labs) for educating us on some of the finer points related to Crypto Mathematics.
作者要感谢雨果·克劳茨克（Hugo Krawczyk）、阿扬·K·伦斯特拉（贝尔实验室）和埃里克·格罗斯（贝尔实验室），感谢他们在与加密数学相关的一些细节方面教育我们。
We would also like to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST for review of portions of this document that are directly derived from the closely related work on RIPv2 Cryptographic Authentication [RFC4822].
我们还要感谢（美国）NIST的Bill Burr、Tim Polk、John Kelsey和Morris Dworkin对本文件中直接源自RIPv2加密认证密切相关工作[RFC4822]的部分内容进行审查。
We would also like to mention Alfred Hoenes for his careful and detailed review during the last call.
我们还想提到阿尔弗雷德·霍恩斯，他在上次通话中进行了仔细和详细的审查。
Lastly, we would like to acknowledge Brian and Stephen Eisenberg for their continued support.
最后，我们要感谢Brian和Stephen Eisenberg的持续支持。
IANA has registered the value for the CRYPTO_AUTH method in the "IS-IS Authentication Type Codes for TLV 10" subregistry established by [RFC5304]. The value 3 denotes the CRYPTO_AUTH mechanism for authenticating IS-IS PDUs.
IANA已在[RFC5304]建立的“TLV 10的IS-IS认证类型代码”子区中注册了CRYPTO_AUTH方法的值。值3表示用于验证IS-IS PDU的加密验证机制。
+--------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+--------------------------------------------+-------+-------------+
| Cryptographic Authentication (CRYPTO_AUTH) | 3 | [RFC5310] |
+--------------------------------------------+-------+-------------+
+--------------------------------------------+-------+-------------+
| Authentication Type Code | Value | Reference |
+--------------------------------------------+-------+-------------+
| Cryptographic Authentication (CRYPTO_AUTH) | 3 | [RFC5310] |
+--------------------------------------------+-------+-------------+
[FIPS-180-3] US National Institute of Standards & Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]美国国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-3，2008年10月。
[FIPS-198] US National Institute of Standards & Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198, March 2002.
[FIPS-198]美国国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，FIPS PUB 198，2002年3月。
[ISO] "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992.
[ISO]“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统路由信息交换协议（ISO 8473）”，ISO/IEC 10589:1992。
[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月。
[RFC2104] Krawczk, H., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczk，H.，“HMAC：用于消息认证的键控哈希”，RFC2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, February 2001.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，2001年2月。
[RFC5304] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“中间系统到中间系统（IS-IS）加密认证”，RFC 5304，2008年10月。
[CRYPTO] Vishwas, M., White, R., and M. Bhatia, "Issues with existing Cryptographic Protection Methods for Routing Protocols", Work in Progress, February 2008.
[加密]Vishwas，M.，White，R.，和M.Bhatia，“路由协议现有加密保护方法的问题”，正在进行的工作，2008年2月。
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", Technical Report, May 1996.
[Dobb96a]Dobbertin，H.，“MD5压缩的密码分析”，技术报告，1996年5月。
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", Cryptobytes, Volume 2, No 2, Summer 1996.
[Dobb96b]Dobbertin，H.，“最近一次攻击后MD5的状态”，Cryptobytes，第2卷，第2期，1996年夏季。
[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月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全性的随机性要求”，RFC 40862005年6月。
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RFC4822]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
Authors' Addresses
作者地址
Manav Bhatia Alcatel-Lucent Bangalore, India
印度班加罗尔朗讯公司
EMail: manav@alcatel-lucent.com
EMail: manav@alcatel-lucent.com
Vishwas Manral IP Infusion Almora, Uttarakhand India
印度北部阿尔莫拉的维什瓦斯·曼拉尔
EMail: vishwas@ipinfusion.com
EMail: vishwas@ipinfusion.com
Tony Li Redback Networks Inc. 300 Holger Way San Jose, CA 95134 USA
Tony Li Redback Networks Inc.美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
EMail: tony.li@tony.li
EMail: tony.li@tony.li
Randall J. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
Randall J.Atkinson极限网络美国加利福尼亚州圣克拉拉门罗街3585号，邮编95051
EMail: rja@extremenetworks.com
EMail: rja@extremenetworks.com
Russ White Cisco Systems RTP North Carolina USA
Russ White Cisco Systems RTP美国北卡罗来纳州
EMail: riw@cisco.com
EMail: riw@cisco.com
Matthew J. Fanto Aegis Data Security Dearborn, MI USA
Matthew J.Fanto Aegis数据安全美国密苏里州迪尔伯恩
EMail: mfanto@aegisdatasecurity.com
EMail: mfanto@aegisdatasecurity.com