Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7210 Vigil Security
Category: Standards Track T. Polk
ISSN: 2070-1721 NIST
S. Hartman
Painless Security
D. Zhang
Huawei Technologies Co. Ltd.
April 2014
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7210 Vigil Security
Category: Standards Track T. Polk
ISSN: 2070-1721 NIST
S. Hartman
Painless Security
D. Zhang
Huawei Technologies Co. Ltd.
April 2014
Database of Long-Lived Symmetric Cryptographic Keys
长寿命对称密钥数据库
Abstract
摘要
This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.
本文档指定了许多不同路由协议用于消息安全的长寿命加密密钥概念数据库中包含的信息。该数据库旨在支持手动和自动密钥管理。除了描述数据库的模式外，本文档还描述了可在数据库上执行的操作以及希望使用数据库的路由协议的要求。在许多典型场景中，协议不直接使用长寿命密钥，而是使用密钥派生函数从长寿命密钥派生短命密钥。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7210.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7210.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document specifies the information that needs to be included in a database of long-lived cryptographic keys in order to key the cryptographic authentication of routing protocols. This conceptual database is designed to separate protocol-specific aspects from both manual and automated key management. The intent is to allow many different implementation approaches to the specified cryptographic key database, while simplifying specification and heterogeneous deployments. This conceptual database avoids the need to build knowledge of any security protocol into key management protocols. It minimizes protocol-specific knowledge in operational/management interfaces, and it constrains where that knowledge can appear. Textual conventions are provided for the representation of keys and other identifiers. These conventions should be used when presenting keys and identifiers to operational/management interfaces or reading keys/identifiers from these interfaces. This satisfies the operational requirement that all implementations represent the keys and key identifiers in the same way so that cross-vendor configuration instructions can be provided.
本文档指定了需要包含在长寿命加密密钥数据库中的信息，以便为路由协议的加密身份验证提供密钥。该概念数据库旨在将协议特定方面与手动和自动密钥管理分开。其目的是允许对指定的加密密钥数据库使用多种不同的实现方法，同时简化规范和异构部署。这个概念数据库避免了将任何安全协议的知识构建到密钥管理协议中的需要。它最小化了操作/管理界面中特定于协议的知识，并限制了这些知识的出现位置。为键和其他标识符的表示提供了文本约定。当向操作/管理接口呈现密钥和标识符或从这些接口读取密钥/标识符时，应使用这些约定。这满足了操作需求，即所有实现都以相同的方式表示密钥和密钥标识符，从而可以提供跨供应商的配置说明。
Routing protocols can employ the services of more-generic security protocols such as TCP-AO [RFC5925]. Implementations of routing protocols may need to supply keys to databases specific to these security protocols as the associated entries in this document's conceptual database are manipulated.
路由协议可以使用更通用的安全协议（如TCP-AO[RFC5925]）的服务。路由协议的实现可能需要向特定于这些安全协议的数据库提供密钥，因为本文档的概念数据库中的相关条目被操纵。
In many instances, the long-lived keys are not used directly in security protocols, but rather a key derivation function is used to derive short-lived keys from the long-lived key in the database. In other instances, security protocols will directly use the long-lived key from the database. The database design supports both use cases.
在许多情况下，长寿命密钥不直接用于安全协议，而是使用密钥派生函数从数据库中的长寿命密钥派生出短命密钥。在其他情况下，安全协议将直接使用来自数据库的长寿命密钥。数据库设计支持这两种用例。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The database is characterized as a table, where each row represents a single long-lived symmetric cryptographic key. Normally, each key should only have one row. Only in the (hopefully) very rare cases where a key is used for more than one purpose, or where the same key is used with multiple key derivation functions (KDFs) will multiple rows contain the same key value. The columns in the table represent the key value and attributes of the key.
数据库被描述为一个表，其中每一行代表一个长期使用的对称加密密钥。通常，每个键应该只有一行。只有在（希望如此）非常罕见的情况下，一个键用于多个目的，或者同一个键与多个键派生函数（KDF）一起使用时，多行才会包含相同的键值。表中的列表示键的键值和属性。
To accommodate manual key management, the format of the fields has been purposefully chosen to allow updates with a plain-text editor and to provide equivalent display on multiple systems.
为了适应手动密钥管理，特意选择了字段的格式，以允许使用纯文本编辑器进行更新，并在多个系统上提供等效的显示。
The columns that the table consists of are listed as follows:
该表由以下列组成：
AdminKeyName The AdminKeyName field contains a human-readable string meant to identify the key for the user. Implementations can use this field to uniquely identify rows in the key table. The same string can be used on the local system and peer systems, but this is not required. Routing protocols do not make use of this string; they use the LocalKeyName and the PeerKeyName. However, if these strings are to be used as protocol elements in other protocols or otherwise transferred between systems, they will need to follow the requirements of Section 5.1.
AdminKeyName AdminKeyName字段包含一个人类可读的字符串，用于标识用户的密钥。实现可以使用此字段唯一标识键表中的行。本地系统和对等系统上可以使用相同的字符串，但这不是必需的。路由协议不使用此字符串；它们使用LocalKeyName和PeerKeyName。但是，如果这些字符串将用作其他协议中的协议元素或在系统之间传输，则需要遵循第5.1节的要求。
LocalKeyName The LocalKeyName field contains a string identifying the key. It can be used to retrieve the key in the local database when received in a message. As discussed in Section 4, the protocol defines the form of this field. For example, many routing protocols restrict the format of their key names to integers that can be represented in 16 or 32 bits. Typically, this field does not contain data in human character sets requiring internationalization. If there ever are any routing Protocols with key names requiring internationalization, those specifications need to address issues of canonicalization and normalization so that key names can be compared using binary comparison.
LocalKeyName LocalKeyName字段包含标识密钥的字符串。当在消息中接收到密钥时，它可用于检索本地数据库中的密钥。如第4节所述，协议定义了该字段的形式。例如，许多路由协议将其密钥名的格式限制为可以用16或32位表示的整数。通常，此字段不包含需要国际化的人类角色集中的数据。如果有任何路由协议的密钥名需要国际化，那么这些规范需要解决规范化和规范化问题，以便可以使用二进制比较来比较密钥名。
PeerKeyName PeerKeyName is the name of the key used by the local system in an outgoing message. For unicast communication, the PeerKeyName of a key on a system matches the LocalKeyName of the identical key that is maintained on one or multiple peer systems. Similar to LocalKeyName, a protocol defines the form of this identifier and will often restrict it to be an integer. For group keys, the protocol will typically require this field be an empty string as the sending and the receiving key names need to be the same.
PeerKeyName PeerKeyName是本地系统在传出消息中使用的密钥的名称。对于单播通信，系统上密钥的PeerKeyName与一个或多个对等系统上维护的相同密钥的LocalKeyName匹配。与LocalKeyName类似，协议定义此标识符的形式，并且通常将其限制为整数。对于组密钥，协议通常要求此字段为空字符串，因为发送和接收密钥名称需要相同。
Peers Typically for unicast keys, this field lists the peer systems that have this key in their database. For group keys, this field names the groups for which the key is appropriate. For example, this might name a routing area for a multicast routing protocol. Formally, this field provides a protocol-specific set of restrictions on the scope in which the key is appropriate. The format of the identifiers in the Peers field is specified by the protocol.
对等点通常对于单播密钥，此字段列出在其数据库中具有此密钥的对等系统。对于组密钥，此字段命名密钥适用的组。例如，这可能会为多播路由协议命名一个路由区域。在形式上，该字段提供了一组特定于协议的对密钥适用范围的限制。对等字段中标识符的格式由协议指定。
Interfaces The Interfaces field identifies the set of physical and/or virtual interfaces for which it is appropriate to use this key. When the long-lived value in the Key field is intended for use on any interface, this field is set to "all". The interfaces field consists of a set of strings; the form of these strings is specified by the implementation and is independent of the protocol in question. Protocols may require support for the Interfaces field or may indicate that support for constraining keys based on interface is not required. As an example, TCP-AO implementations are unlikely to make the decision of what interface to use prior to key selection. In that case, the implementations are expected to use the same keying material across all of the interfaces and then require the "all" setting.
接口接口字段标识适合使用此键的物理和/或虚拟接口集。当键字段中的长寿命值用于任何接口时，此字段设置为“全部”。接口字段由一组字符串组成；这些字符串的形式由实现指定，并且独立于所讨论的协议。协议可能需要对接口字段的支持，或者可能表明不需要支持基于接口约束密钥。例如，TCP-AO实现不太可能在选择密钥之前决定使用哪个接口。在这种情况下，实现需要在所有接口上使用相同的键控材料，然后需要“全部”设置。
Protocol The Protocol field identifies a single routing protocol where this key may be used to provide cryptographic protection. This specification establishes a registry for this field; the registry also specifies the format of the following field, ProtocolSpecificInfo, for each registered protocol.
协议协议字段标识单个路由协议，其中该密钥可用于提供加密保护。本规范为该字段建立了一个注册表；注册表还为每个已注册协议指定以下字段ProtocolSpecificInfo的格式。
ProtocolSpecificInfo This field contains the protocol-specified information that may be useful for a protocol to apply the key correctly. Note that such information MUST NOT be required for a protocol to locate an appropriate key. When a protocol does not need the information in ProtocolSpecificInfo, it will require this field be empty. Key table rows MAY specify a Direction of "both". As a result, the encoding of this field needs to support encoding protocol-specific information for sending and receiving in the same row.
ProtocolSpecificInfo此字段包含协议指定的信息，这些信息可能有助于协议正确应用密钥。请注意，协议不需要这些信息来定位适当的密钥。当协议不需要ProtocolSpecificInfo中的信息时，它将要求此字段为空。键表行可以指定“两者”的方向。因此，该字段的编码需要支持在同一行中发送和接收特定于编码协议的信息。
KDF The KDF field indicates the key derivation function that is used to generate short-lived keys from the long-lived value in the Key field. When the long-lived value in the Key field is intended for direct use, the KDF field is set to "none". A key derivation function is a one-way function that provides cryptographic separation of key material. The KDF MAY use inputs from the row in the key table and the message being sent or received but MUST NOT depend on other configuration state. This document establishes an IANA registry for the values in the KDF field to simplify references in future specifications. The protocol indicates what (if any) KDFs are valid.
KDF KDF字段表示用于从键字段中的长寿命值生成短命键的键派生函数。当密钥字段中的长寿命值打算直接使用时，KDF字段设置为“无”。密钥派生函数是一种单向函数，提供密钥材料的加密分离。KDF可以使用来自键表中的行的输入以及正在发送或接收的消息，但不能依赖于其他配置状态。本文档为KDF字段中的值建立IANA注册表，以简化未来规范中的引用。协议指示哪些KDF（如果有）是有效的。
AlgID The AlgID field indicates which cryptographic algorithm is to be used with the security protocol for the specified peer or peers. Such an algorithm can be an encryption algorithm and mode (e.g., AES-128-CBC), an authentication algorithm (e.g., HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric cryptographic algorithm needed by a security protocol. If the KDF field contains "none", then the long-lived key is used directly with this algorithm; otherwise, the derived short-lived key is used with this algorithm. When the long-lived key is used to generate a set of short-lived keys for use with the security protocol, the AlgID field identifies a ciphersuite rather than a single cryptographic algorithm. This document establishes an IANA registry for the values in the AlgID field to simplify references in future specifications. Protocols indicate which algorithms are appropriate.
AlgID AlgID字段指示将与指定对等方的安全协议一起使用的加密算法。这种算法可以是加密算法和模式（例如，AES-128-CBC）、认证算法（例如，HMAC-SHA1-96或AES-128-CMAC）或安全协议所需的任何其他对称加密算法。如果KDF字段包含“none”，则长寿命密钥直接用于此算法；否则，该算法将使用派生的短期密钥。当长寿命密钥用于生成一组与安全协议一起使用的短命密钥时，AlgID字段标识密码套件，而不是单个密码算法。本文件为AlgID字段中的值建立IANA注册表，以简化未来规范中的引用。协议表明哪些算法是合适的。
Key The Key field contains a long-lived symmetric cryptographic key in the format of a lowercase hexadecimal string. The size of the Key depends on the KDF and the AlgID. For instance, KDF=none and AlgID=AES128 require a 128-bit key, which is represented by 32 hexadecimal digits.
密钥密钥字段包含小写十六进制字符串格式的长寿命对称加密密钥。密钥的大小取决于KDF和AlgID。例如，KDF=none和AlgID=AES128需要一个128位的密钥，该密钥由32个十六进制数字表示。
Direction The Direction field indicates whether this key may be used for inbound traffic, outbound traffic, both, or whether the key has been disabled and may not currently be used at all. The supported values are "in", "out", "both", and "disabled", respectively. The Protocol field will determine which of these values are valid.
方向方向字段指示此密钥是否可用于入站流量和出站流量，或者该密钥是否已禁用且当前可能根本不使用。支持的值分别为“输入”、“输出”、“两者”和“禁用”。协议字段将确定这些值中哪些是有效的。
SendLifetimeStart The SendLifetimeStart field specifies the earliest date and time in Coordinated Universal Time (UTC) at which this key should be considered for use when sending traffic. The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, two digits specify the minute, and two digits specify the second. The "Z" is included as a clear indication that the time is in UTC.
SendLifetimeStart SendLifetimeStart字段指定在发送流量时应考虑使用此键的协调世界时（UTC）中的最早日期和时间。格式为YYYYMMDDHHSSZ，其中四位数字表示年份，两位数字表示月份，两位数字表示日期，两位数字表示小时，两位数字表示分钟，两位数字表示秒。“Z”作为时间单位为UTC的明确指示。
SendLifeTimeEnd The SendLifeTimeEnd field specifies the latest date and time at which this key should be considered for use when sending traffic. The format is the same as the SendLifetimeStart field.
SendLifeTimeEnd SendLifeTimeEnd字段指定发送流量时应考虑使用此密钥的最新日期和时间。格式与SendLifetimeStart字段相同。
AcceptLifeTimeStart The AcceptLifeTimeStart field specifies the earliest date and time in Coordinated Universal Time (UTC) at which this key should be considered for use when processing received traffic. The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, two digits specify the minute, and two digits specify the second. The "Z" is included as a clear indication that the time is in UTC.
AcceptLifeTimeStart AcceptLifeTimeStart字段指定协调世界时（UTC）中最早的日期和时间，在该日期和时间处理接收的流量时，应考虑使用此键。格式为YYYYMMDDHHSSZ，其中四位数字表示年份，两位数字表示月份，两位数字表示日期，两位数字表示小时，两位数字表示分钟，两位数字表示秒。“Z”作为时间单位为UTC的明确指示。
AcceptLifeTimeEnd The AcceptLifeTimeEnd field specifies the latest date and time at which this key should be considered for use when processing the received traffic. The format of this field is identical to the format of AcceptLifeTimeStart.
AcceptLifeTimeEnd AcceptLifeTimeEnd字段指定在处理接收的流量时应考虑使用此密钥的最新日期和时间。此字段的格式与AcceptLifeTimeStart的格式相同。
A protocol may directly consult the key table to find the key to use on an outgoing message. The protocol provides a protocol (P) and a peer identifier (H) into the key selection function. Optionally, an interface identifier (I) may also need to be provided. Any key that satisfies the following conditions may be selected:
协议可以直接查阅密钥表，以查找用于传出消息的密钥。该协议向密钥选择功能提供协议（P）和对等标识符（H）。可选地，还需要提供接口标识符（I）。可选择满足以下条件的任何钥匙：
(1) the Peers field includes H;
(1) 对等字段包括H；
(2) the Protocol field matches P;
(2) 协议字段匹配P；
(3) If an interface is specified by the protocol, the Interfaces field in the key table row includes I or "all";
(3) 如果协议指定了接口，则键表行的接口字段包括I或“全部”；
(4) the Direction field is either "out" or "both"; and
(4) 方向字段为“out”或“both”；和
(5) SendLifetimeStart <= current time <= SendLifeTimeEnd.
(5) SendLifetimeStart<=当前时间<=SendLifeTimeEnd。
During key selection, there may be multiple entries that simultaneously exist and are associated with different cryptographic algorithms or ciphersuites. Systems should support selection of keys based on algorithm preference to facilitate algorithm transition.
在密钥选择过程中，可能同时存在多个条目，这些条目与不同的加密算法或密码套件相关联。系统应支持基于算法偏好的密钥选择，以促进算法转换。
In addition, multiple entries with overlapping valid periods are expected to be available for orderly key rollover. In these cases, the expectation is that systems will transition to the newest key available. To meet this requirement, this specification recommends supplementing the key selection algorithm with the following differentiation: select the long-lived key specifying the most recent time in the SendLifetimeStart field.
此外，有效期重叠的多个条目预计可用于有序的键滚动。在这些情况下，系统将过渡到可用的最新密钥。为了满足此要求，本规范建议使用以下区别来补充密钥选择算法：在SendLifetimeStart字段中选择指定最近时间的长寿命密钥。
In order to look up a key for validating an incoming message, the protocol provides its protocol (P), the peer identifier (H), the key identifier (L), and optionally the interface (I). If one key matches the following conditions, it is selected:
为了查找用于验证传入消息的密钥，协议提供其协议（P）、对等标识符（H）、密钥标识符（L）以及可选的接口（I）。如果一个键符合以下条件，则选择该键：
(1) the Peer field includes H;
(1) 对等字段包括H；
(2) the Protocol field matches P;
(2) 协议字段匹配P；
(3) if the Interface field is provided, it includes I or is "all";
(3) 如果提供了接口字段，则包括I或为“全部”；
(4) the Direction field is either "in" or "both";
(4) 方向字段为“in”或“both”；
(5) the LocalKeyName is L; and
(5) LocalKeyName是L；和
(6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.
(6) AcceptLifeTimeStart<=当前时间<=AcceptLifeTimeEnd。
Note that the key usage is loosely bound by the times specified in the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security associations should not be established except within the period of use specified by these fields, while allowing some grace time for clock skew. However, if a security association has already been established based on a particular long-lived key, exceeding the lifetime does not have any direct impact. The implementations of security protocols that involve long-lived security associations should be designed to periodically interrogate the database and rollover to new keys without tearing down the security associations.
请注意，密钥的使用受到AcceptLifeTimeStart和AcceptLifeTimeEnd字段中指定的时间的松散限制。除非在这些字段指定的使用期限内，否则不应建立新的安全关联，同时为时钟偏移留出一些宽限时间。但是，如果已经基于特定的长寿命密钥建立了安全关联，则超过该生存期不会产生任何直接影响。涉及长期安全关联的安全协议的实现应设计为定期查询数据库并滚动到新密钥，而不会破坏安全关联。
Rather than consulting the conceptual database, a security protocol such as TCP-AO may update its own tables as keys are added and removed. In this case, the protocol needs to maintain its own key information. Some routing protocols use IP Security (IPsec) to provide integrity. If a specification describes how to use the conceptual database described in this document to configure keys for these routing protocols, similar concerns apply. The specification mapping those routing protocols onto this conceptual database needs to describe how the Security Policy Database is manipulated as rows are added and removed from the conceptual database.
在添加和删除密钥时，诸如TCP-AO之类的安全协议可能会更新自己的表，而不是查阅概念数据库。在这种情况下，协议需要维护自己的密钥信息。一些路由协议使用IP安全（IPsec）来提供完整性。如果规范描述了如何使用本文档中描述的概念数据库来配置这些路由协议的密钥，则类似的问题也适用。将这些路由协议映射到此概念数据库的规范需要描述在概念数据库中添加和删除行时如何操作安全策略数据库。
In order to use the key table database in a protocol specification, a protocol needs to specify certain information. This section enumerates items that a protocol must specify.
为了在协议规范中使用密钥表数据库，协议需要指定某些信息。本节列举协议必须指定的项。
(1) The ways of mapping the information in a key table row to the information needed to produce an outgoing message; specified as an explanation of either how to fill in authentication-related fields in a message based on key table information, or (for protocols such as TCP-AO) how to construct Master Key Tuples (MKTs) or other protocol-specific structures from a key table row
(1) 将键表行中的信息映射到生成传出消息所需的信息的方法；指定为说明如何基于密钥表信息在消息中填写身份验证相关字段，或（对于TCP-AO等协议）如何从密钥表行构造主密钥元组（MKT）或其他特定于协议的结构
(2) The ways of locating the peer identifier (a member of the Peers set) and the LocalKeyName inside an incoming message
(2) 在传入消息中定位对等标识符（对等集的成员）和LocalKeyName的方法
(3) The methods of verifying a message given a key table row; this may be stated directly or in terms of protocol-specific structures such as MKTs
(3) 验证给定键表行的消息的方法；这可以直接说明，也可以根据协议特定结构（如MKTs）说明
(4) The form and validation rules for LocalKeyName and PeerKeyName; if either of these is an integer, the conventions in Section 5.1 are used as a vendor-independent format
(4) LocalKeyName和PeerKeyName的格式和验证规则；如果其中任何一个是整数，则第5.1节中的约定将用作独立于供应商的格式
(5) The form and validation rules for members of the Peers set
(5) 对等集成员的表单和验证规则
(6) The algorithms and KDFs supported
(6) 支持的算法和KDF
(7) The form of the ProtocolSpecificInfo field
(7) ProtocolSpecificInfo字段的形式
(8) The rules for canonicalizing LocalKeyName, PeerKeyName, entries in the Peers set, or ProtocolSpecificInfo; this may include normalizations such as lowercasing hexadecimal strings
(8) 规范化LocalKeyName、PeerKeyName、对等点集中的条目或ProtocolSpecificInfo的规则；这可能包括规范化，例如将十六进制字符串小写
(9) The Indication whether the support for Interfaces is required by this protocol
(9) 该协议是否要求支持接口的指示
The form of the interfaces field is not protocol specific but instead is shared among all protocols on an implementation. If a protocol needs to distinguish instances running over the same interface, this is included in the specification of peers. Generally, it is desirable to define the specification of peers so that an operator can use the Interfaces field to refer to all instances of a protocol on a link without having to specify both generic interfaces information and protocol-specific peer information.
接口字段的形式不是特定于协议的，而是在实现上的所有协议之间共享的。如果协议需要区分在同一接口上运行的实例，这将包含在对等规范中。通常，希望定义对等体的规范，以便操作员可以使用接口字段来引用链路上的协议的所有实例，而不必指定通用接口信息和协议特定的对等体信息。
When a key for a given protocol is identified by an integer key identifier, the associated key name will be represented as lowercase hexadecimal digits with the most significant octet first. This integer is padded with leading zero digits until the width of the key identifier field in the protocol is reached. If a key name contains non-integer human-readable text, its format and encoding may be an issue, particularly if it is used in protocol between two different types of systems. If characters from the ASCII range [RFC20] are sufficient for a key name, then they SHOULD be used. If characters outside of that range are desirable or required, then they MUST be in an encoding of Unicode [UNICODE].
当给定协议的密钥由整数密钥标识符标识时，关联的密钥名称将表示为小写十六进制数字，最重要的八位位组在前。该整数用前导零位填充，直到达到协议中密钥标识符字段的宽度。如果密钥名包含非整数人类可读文本，则其格式和编码可能会有问题，特别是在两种不同类型的系统之间的协议中使用时。如果ASCII范围[RFC20]中的字符足以作为键名，则应使用它们。如果需要或需要超出该范围的字符，则必须采用Unicode[Unicode]编码。
In the case of an AdminKeyName that uses characters outside of the ASCII range, the AdminKeyName MUST be encoded using UTF-8 [RFC3629] and SHOULD be normalized using Unicode Normalization Form KC [UAX15] to maximize the chance that the strings will compare correctly.
如果AdminKeyName使用ASCII范围以外的字符，则必须使用UTF-8[RFC3629]对AdminKeyName进行编码，并应使用Unicode规范化表单KC[UAX15]进行规范化，以最大限度地提高字符串正确比较的机会。
However, simply using Unicode Normalization Form KC is not sufficient to account for all issues of string comparison; refer to [PRECIS-FRAMEWORK] for additional information.
然而，仅仅使用Unicode规范化表单KC不足以解决字符串比较的所有问题；有关更多信息，请参阅[PRECIS-FRAMEWORK]。
A key is represented as a lowercase hexadecimal string with the most significant octet of the key first. As discussed in Section 2, the length of this string depends on the associated algorithm and KDF.
一个键被表示为一个小写的十六进制字符串，其最重要的八位位组位于第一位。如第2节所述，该字符串的长度取决于相关的算法和KDF。
If the valid periods for long-lived keys do not overlap or the system clocks are inconsistent, it is possible to construct scenarios where systems cannot agree upon a long-lived key. When installing a series of keys to be used one after another, operators should configure the SendLifetimeStart field of the key to be several hours after the AcceptLifeTimeStart field of the key to guarantee there is some overlap. This overlap is intended to address the clock-skew issue and allow for basic operational considerations. Operators may choose to specify a longer overlap (e.g., several days) to allow for exceptional circumstances.
如果长寿命密钥的有效期不重叠或系统时钟不一致，则可能构建系统无法就长寿命密钥达成一致的场景。在安装一系列要依次使用的密钥时，操作员应将密钥的SendLifetimeStart字段配置为在密钥的AcceptLifeTimeStart字段之后数小时，以确保存在一些重叠。这种重叠旨在解决时钟偏移问题，并考虑基本的操作考虑。运营商可选择指定更长的重叠时间（例如，几天），以考虑特殊情况。
Management of encryption and authentication keys has been a significant operational problem, both in terms of key synchronization and key selection. For instance, the current guidance [RFC3562] warns against sharing TCP MD5 keying material between systems and recommends changing keys according to a schedule. The same general operational issues are relevant for the management of other cryptographic keys.
在密钥同步和密钥选择方面，加密和身份验证密钥的管理一直是一个重要的操作问题。例如，当前指南[RFC3562]警告不要在系统之间共享TCP MD5键控材料，并建议根据时间表更改键。同样的一般操作问题也与其他加密密钥的管理相关。
It has been recognized in [RFC4107] that automated key management is not viable in multiple scenarios. The conceptual database specified in this document is designed to accommodate both manual key management and automated key management. A future specification to automatically populate rows in the database is envisioned.
[RFC4107]中已经认识到，自动密钥管理在多个场景中是不可行的。本文档中指定的概念数据库旨在同时支持手动密钥管理和自动密钥管理。未来的规范将自动填充数据库中的行。
Designers should recognize the warning provided in [RFC4107]:
设计师应识别[RFC4107]中提供的警告：
Automated key management and manual key management provide very different features. In particular, the protocol associated with an automated key management technique will confirm the liveness of the peer, protect against replay, authenticate the source of the short-term session key, associate protocol state information with the short-term session key, and ensure that a fresh short-term session key is generated. Further, an automated key management
自动密钥管理和手动密钥管理提供了非常不同的功能。具体而言，与自动密钥管理技术相关联的协议将确认对等方的活跃性，防止重播，认证短期会话密钥的源，将协议状态信息与短期会话密钥相关联，并确保生成新的短期会话密钥。此外，自动密钥管理
protocol can improve interoperability by including negotiation mechanisms for cryptographic algorithms. These valuable features are impossible or extremely cumbersome to accomplish with manual key management.
该协议可以通过包含密码算法的协商机制来提高互操作性。这些有价值的功能是不可能或极其繁琐的手动密钥管理完成。
This specification defines three registries.
本规范定义了三个注册表。
Per this document, IANA has established a registry called "KeyTable Protocols".
根据本文件，IANA建立了一个名为“KeyTable Protocols”的注册表。
All assignments to the KeyTable Protocols registry are made on a Specification Required basis per Section 4.1 of [RFC5226].
根据[RFC5226]第4.1节的规定，对KeyTable协议注册表的所有分配都是在规定的基础上进行的。
Each registration entry must contain the three fields:
每个注册条目必须包含三个字段：
- Protocol Name (unique within the registry); - Protocol-Specific Info; and - Reference.
- 协议名称（在注册表中唯一）；-协议特定信息；和-参考。
The specification needs to describe parameters required for using the conceptual database as outlined in Section 4. This typically means that the specification focuses more on the application of security protocols with the key tables rather than being a new security protocol specification for general purposes. Of course, new protocols may combine information on how to use the key table database with the protocol specification.
规范需要描述使用第4节中概述的概念数据库所需的参数。这通常意味着该规范更多地关注具有密钥表的安全协议的应用，而不是一个用于一般目的的新安全协议规范。当然，新协议可能会将有关如何使用密钥表数据库的信息与协议规范结合起来。
The registry has three columns. The first column is a string of Unicode characters encoded in UTF-8 representing the name protocol. The second column is a string of Unicode characters encoded in UTF-8 providing a brief description of Protocol-Specific Info. The third column is a reference to a specification defining how the protocol is used with the key table.
注册表有三列。第一列是以UTF-8编码的Unicode字符字符串，表示名称协议。第二列是以UTF-8编码的Unicode字符字符串，提供协议特定信息的简要说明。第三列是对规范的引用，该规范定义了协议如何与密钥表一起使用。
There are no initial registrations.
没有初始注册。
Per this document, IANA has established a registry called "KeyTable KDFs". The remainder of this section describes the registry.
根据本文件，IANA建立了一个名为“KeyTable KDFs”的注册表。本节的其余部分介绍注册表。
All assignments to the KeyTable KDFs registry are made on a First Come First Served basis per Section 4.1 of RFC 5226.
根据RFC 5226第4.1节，对KeyTable KDFs注册表的所有分配均以先到先得的方式进行。
The registry has three columns. The first column is a string of Unicode characters encoded in UTF-8 representing the name of a KDF. The second column is a string of Unicode characters encoded in UTF-8 providing a brief description of the KDF. The third column is a reference to a specification defining the KDF, if available.
注册表有三列。第一列是以UTF-8编码的Unicode字符字符串，表示KDF的名称。第二列是以UTF-8编码的Unicode字符字符串，提供了KDF的简要描述。第三列是对定义KDF的规范的引用（如果可用）。
The initial contents of this registry and that in Section 8.3 are chosen based on the algorithms defined for TCP-AO [RFC5926].
本注册表的初始内容和第8.3节中的初始内容是根据为TCP-AO[RFC5926]定义的算法选择的。
KDF Description Reference
------------ ---------------------------- ---------
none No KDF is used with this key N/A
AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
HMAC-SHA-1 HMAC using the SHA-1 hash [RFC2104]
KDF Description Reference
------------ ---------------------------- ---------
none No KDF is used with this key N/A
AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
HMAC-SHA-1 HMAC using the SHA-1 hash [RFC2104]
Per this document, IANA has established a registry called "KeyTable AlgIDs". The remainder of this section describes the registry.
根据本文件，IANA建立了一个名为“KeyTable AlgIDs”的注册表。本节的其余部分介绍注册表。
All assignments to the KeyTable AlgIDs registry are made on a First Come First Served basis per Section 4.1 of RFC 5226.
根据RFC 5226第4.1节，对键表AlgIDs注册表的所有分配均以先到先得的方式进行。
The registry has three columns. The first column is a string of Unicode characters encoded in UTF-8 representing the algorithm identifier (AlgID). The second column is a string of Unicode characters encoded in UTF-8 providing a brief description of the identified algorithm. The third column is a reference to a specification defining the identified algorithm.
注册表有三列。第一列是以UTF-8编码的Unicode字符字符串，表示算法标识符（AlgID）。第二列是以UTF-8编码的Unicode字符字符串，提供了已识别算法的简要说明。第三列是对定义已识别算法的规范的引用。
The initial contents of this registry and that in Section 8.2 are chosen based on the algorithms defined for TCP-AO [RFC5926].
本注册表的初始内容和第8.2节中的初始内容是根据为TCP-AO[RFC5926]定义的算法选择的。
AlgID Description Reference
------------ --------------------------------- ---------
AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
AES-128-CMAC-96 AES-128-CMAC truncated to 96 bits [RFC5926]
HMAC-SHA-1-96 HMAC SHA-1 truncated to 96 bits [RFC2104]
AlgID Description Reference
------------ --------------------------------- ---------
AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493]
AES-128-CMAC-96 AES-128-CMAC truncated to 96 bits [RFC5926]
HMAC-SHA-1-96 HMAC SHA-1 truncated to 96 bits [RFC2104]
This document reflects many discussions with many different people over many years. In particular, the authors thank Jari Arkko, Ran Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla, Mike Shand, Dave Ward, and Brian Weis for their insights. The authors additionally thank Brian Weis for supplying text to address IANA concerns and for help with formatting.
本文件反映了多年来与许多不同人士进行的许多讨论。特别是，作者感谢贾里·阿克科、冉·阿特金森、罗恩·博尼卡、罗斯·卡隆、拉尔斯·艾格特、帕西·艾隆、阿德里安·法雷尔、格雷戈里·勒博维茨、艾西·林登、桑迪·墨菲、埃里克·雷斯科拉、迈克·山德、戴夫·沃德和布赖恩·韦斯的见解。作者还感谢Brian Weis提供文本以解决IANA关注的问题，并在格式方面提供帮助。
Sam Hartman's work on this document is funded by Huawei.
Sam Hartman在本文件上的工作由华为资助。
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[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月。
[UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", Unicode 6.3.0, September 2013, <http://www.unicode.org/reports/tr15/tr15-39.html>.
[UAX15]Unicode联盟，“Unicode标准附录#15：Unicode规范化格式”，Unicode 6.3.0，2013年9月<http://www.unicode.org/reports/tr15/tr15-39.html>.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.3.0", (Mountain View, CA: The Unicode Consortium, 2013. ISBN 978-1-936213-08-5), <http://www.unicode.org/versions/Unicode6.3.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，版本6.3.0”（加利福尼亚州山景城：UNICODE联盟，2013年，ISBN 978-1-936213-08-5）<http://www.unicode.org/versions/Unicode6.3.0/>.
[PRECIS-FRAMEWORK] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, March 2014.
[PRECIS-FRAMEWORK]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备和比较”，正在进行的工作，2014年3月。
[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月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, June 2006.
[RFC4493]Song，JH.，Poovendran，R.，Lee，J.，和T.Iwata，“AES-CMAC算法”，RFC 4493，2006年6月。
[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月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，2010年6月。
Authors' Addresses
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA EMail: tim.polk@nist.gov
蒂姆·波尔克国家标准与技术研究所美国马里兰州盖瑟斯堡市局道100号邮政站8930邮编：20899-8930电子邮件：蒂姆。polk@nist.gov
Sam Hartman Painless Security, LLC USA EMail: hartmans-ietf@mit.edu
Sam Hartman无痛安全有限责任公司美国电子邮件：hartmans-ietf@mit.edu
Dacheng Zhang Huawei Technologies Co. Ltd. China EMail: zhangdacheng@huawei.com
张大成华为技术有限公司中国电子邮件：zhangdacheng@huawei.com