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




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.

これはInternet Standards Trackドキュメントです。

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(Internet Engineering Task Force)の製品です。これは、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


Copyright Notice


Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

1. Introduction
1. はじめに

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.


1.1. Requirements Notation
1.1. 要件表記

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Conceptual Database Structure
2. 概念的なデータベース構造

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.


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は、1つまたは複数のピアシステムで保持されている同じキーの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.

ピア通常、ユニキャストキーの場合、このフィールドには、データベースにこのキーを持つピアシステムが一覧表示されます。グループキーの場合、このフィールドは、キーが適切なグループを指定します。たとえば、これはマルチキャストルーティングプロトコルのルーティング領域を指定する場合があります。正式には、このフィールドは、キーが適切であるスコープに対するプロトコル固有の一連の制限を提供します。 Peersフィールドの識別子の形式は、プロトコルによって指定されます。

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.

インターフェース「インターフェース」フィールドは、このキーを使用することが適切である物理インターフェースまたは仮想インターフェース、あるいはその両方のセットを識別します。 「キー」フィールドの長期間有効な値が任意のインターフェースでの使用を意図している場合、このフィールドは「すべて」に設定されます。 interfacesフィールドは一連の文字列で構成されます。これらの文字列の形式は実装によって指定され、問題のプロトコルには依存しません。プロトコルは、[インターフェイス]フィールドのサポートを必要とする場合や、インターフェイスに基づく制約キーのサポートが不要であることを示す場合があります。例として、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 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.


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フィールドは、Keyフィールドの長期の値から短期の鍵を生成するために使用される鍵導出関数を示します。 「キー」フィールドの長期間有効な値を直接使用する場合、KDFフィールドは「なし」に設定されます。鍵導出関数は、鍵素材の暗号による分離を提供する一方向関数です。 KDFは、キーテーブルの行からの入力と送信または受信されるメッセージを使用できますが、他の構成状態に依存してはなりません(MUST NOT)。このドキュメントでは、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フィールドは、指定された1つまたは複数のピアのセキュリティプロトコルで使用される暗号化アルゴリズムを示します。このようなアルゴリズムは、暗号化アルゴリズムとモード(AES-128-CBCなど)、認証アルゴリズム(HMAC-SHA1-96またはAES-128-CMACなど)、またはセキュリティプロトコルで必要なその他の対称暗号アルゴリズムのいずれかです。 。 KDFフィールドに「なし」が含まれている場合、長期間有効なキーがこのアルゴリズムで直接使用されます。それ以外の場合、このアルゴリズムでは派生した有効期間の短いキーが使用されます。長期キーを使用して、セキュリティプロトコルで使用する短期キーのセットを生成する場合、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.

キーキーフィールドには、長期間有効な対称暗号キーが小文字の16進文字列の形式で含まれます。キーのサイズは、KDFとAlgIDによって異なります。たとえば、KDF = noneおよびAlgID = AES128には、32ビットの16進数で表される128ビットのキーが必要です。

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.

方向[方向]フィールドは、このキーをインバウンドトラフィック、アウトバウンドトラフィックの両方に使用できるかどうか、またはキーが無効になっていて現在はまったく使用されていないかどうかを示します。サポートされる値は、それぞれ「in」、「out」、「both」、および「disabled」です。 Protocolフィールドは、これらの値のどれが有効かを決定します。

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で、4桁は年、2桁は月、2桁は日、2桁は時間、2桁は分、2桁は秒を指定します。 「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で、4桁は年、2桁は月、2桁は日、2桁は時間、2桁は分、2桁は秒を指定します。 「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の形式と同じです。

3. Key Selection and Rollover
3. キーの選択とロールオーバー

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:


(1) the Peers field includes H;


(2) the Protocol field matches P;


(3) If an interface is specified by the protocol, the Interfaces field in the key table row includes I or "all";


(4) the Direction field is either "out" or "both"; and


(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.


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つのキーが次の条件に一致する場合、それが選択されます。

(1) the Peer field includes H;


(2) the Protocol field matches P;


(3) if the Interface field is provided, it includes I or is "all";


(4) the Direction field is either "in" or "both";

(4)[方向]フィールドは "in"または "both"のいずれかです。

(5) the LocalKeyName is L; and


(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.


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.


4. Application of the Database in a Security Protocol
4. セキュリティプロトコルでのデータベースの適用

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


(2) The ways of locating the peer identifier (a member of the Peers set) and the LocalKeyName inside an incoming message


(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


(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


(5) The form and validation rules for members of the Peers set


(6) The algorithms and KDFs supported


(7) The form of the ProtocolSpecificInfo field


(8) The rules for canonicalizing LocalKeyName, PeerKeyName, entries in the Peers set, or ProtocolSpecificInfo; this may include normalizations such as lowercasing hexadecimal strings


(9) The Indication whether the support for Interfaces is required by this protocol


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.


5. Textual Conventions
5. テキストの表記法
5.1. Key Names
5.1. キーネーム

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].

特定のプロトコルのキーが整数のキー識別子で識別される場合、関連付けられたキー名は、最下位オクテットが最初に来る小文字の16進数として表されます。この整数は、プロトコルのキー識別子フィールドの幅に達するまで、先頭にゼロの数字が埋め込まれます。キー名に整数以外の人間が読めるテキストが含まれている場合、特に2つの異なるタイプのシステム間のプロトコルで使用されている場合、そのフォーマットとエンコーディングが問題になる可能性があります。キー範囲としてASCII範囲[RFC20]の文字で十分な場合は、それらを使用する必要があります(SHOULD)。その範囲外の文字が望ましいまたは必要な場合は、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.

ASCII範囲外の文字を使用するAdminKeyNameの場合、AdminKeyNameはUTF-8 [RFC3629]を使用してエンコードする必要があり、文字列が正しく比較される可能性を最大にするために、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.


5.2. Keys
5.2. キー

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.


6. Operational Considerations
6. 運用上の考慮事項

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.


7. Security Considerations
7. セキュリティに関する考慮事項

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.


Designers should recognize the warning provided in [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.


8. IANA Considerations
8. IANAに関する考慮事項

This specification defines three registries.


8.1. KeyTable Protocols
8.1. KeyTableプロトコル

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].

KeyTable Protocolsレジストリへのすべての割り当ては、[RFC5226]のセクション4.1に従って、必要な仕様に基づいて行われます。

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.


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.

レジストリには3つの列があります。最初の列は、名前プロトコルを表すUTF-8でエンコードされたUnicode文字の文字列です。 2番目の列は、UTF-8でエンコードされたUnicode文字の文字列で、プロトコル固有の情報の簡単な説明を提供します。 3番目の列は、キーテーブルでのプロトコルの使用方法を定義する仕様への参照です。

There are no initial registrations.


8.2. KeyTable KDFs
8.2. KeyTable KDF

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.

KeyTable KDFレジストリへのすべての割り当ては、RFC 5226のセクション4.1に従って先着順で行われます。

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.

レジストリには3つの列があります。最初の列は、KDFの名前を表すUTF-8でエンコードされたUnicode文字の文字列です。 2列目は、UTF-8でエンコードされたUnicode文字列で、KDFの簡単な説明を提供します。 3番目の列は、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]
8.3. KeyTable AlgIDs
8.3. KeyTable AlgID

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.

KeyTable AlgIDsレジストリへのすべての割り当ては、RFC 5226のセクション4.1に従って先着順で行われます。

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.

レジストリには3つの列があります。最初の列は、アルゴリズム識別子(AlgID)を表すUTF-8でエンコードされたUnicode文字の文字列です。 2列目は、UTF-8でエンコードされたUnicode文字列で、特定されたアルゴリズムの簡単な説明を提供します。 3番目の列は、識別されたアルゴリズムを定義する仕様への参照です。

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]
9. Acknowledgments
9. 謝辞

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.

このドキュメントは、長年にわたるさまざまな人々との多くの議論を反映しています。特に、著者は、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、Brian Weisに感謝します。洞察。著者はさらに、IANAの懸念に対処するためのテキストを提供し、書式設定を支援してくれたBrian Weisに感謝します。

Sam Hartman's work on this document is funded by Huawei.

このドキュメントに関するSam Hartmanの作業はHuaweiによって資金提供されています。

10. Normative References
10. 引用文献

[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.

[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、RFC 20、1969年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, <>.

[UAX15] Unicodeコンソーシアム、「Unicode Standard Annex#15:Unicode Normalization Forms」、Unicode 6.3.0、2013年9月、<>。

[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.3.0", (Mountain View, CA: The Unicode Consortium, 2013. ISBN 978-1-936213-08-5), <>.

[UNICODE] Unicodeコンソーシアム、「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 />。

11. Informative References
11. 参考引用

[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 Framework:Preparation and Comparison of Internationalized Strings in Application Protocols」、Work in Progress、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:Keyed-Hashing for Message Authentication」、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、「RFCで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、「The TCP Authentication Option」、RFC 5925、2010年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 Authentication Option(TCP-AO)の暗号化アルゴリズム」、RFC 5926、2010年6月。

Authors' Addresses


Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail:

Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール

Tim Polk National Institute of Standards and Technology 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA EMail:

Tim Polk National Institute of Standards and Technology 100 Bureau Drive、Mail Stop 8930 Gaithersburg、MD 20899-8930 USAメール

Sam Hartman Painless Security, LLC USA EMail:

Sam Hartman Painless Security、LLC USA

Dacheng Zhang Huawei Technologies Co. Ltd. China EMail:

DA Cheng Zhang hu Aはテクノロジー株式会社です。中国のメール:张大成@华华.com