[要約] RFC 7210は、長寿命の対称暗号鍵のデータベースに関する規格です。この文書の目的は、ネットワークデバイス間で使用される長寿命の対称鍵の管理を標準化することにあります。これは、特にIPsecやその他のセキュリティプロトコルでの鍵の配布や更新のプロセスを効率化し、セキュリティを強化するために利用されます。関連するRFCにはRFC 4301 (IPsecのセキュリティアーキテクチャ) やRFC 4949 (セキュリティ用語集) などがあり、これらはRFC 7210の文脈で参照されることがあります。
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.
これは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 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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
データベースはテーブルとして特徴付けられ、各行は単一の長期間有効な対称暗号鍵を表します。通常、各キーには1つの行しかありません。キーが複数の目的で使用される（うまくいけば）非常にまれなケース、または同じキーが複数のキー導出関数（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は、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というフィールドの形式も指定しています。
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の情報を必要としない場合は、このフィールドを空にする必要があります。キーテーブル行は、「両方」の方向を指定してもよい（MAY）。その結果、このフィールドのエンコーディングは、同じ行で送受信するためのプロトコル固有のエンコーディング情報をサポートする必要があります。
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の形式と同じです。
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）Peersフィールドには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）[方向]フィールドは「アウト」または「両方」です。そして
(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つのキーが次の条件に一致する場合、それが選択されます。
(1) the Peer field includes H;
（1）Peerフィールドには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）キーテーブル行を指定してメッセージを検証する方法。これは直接またはMKTなどのプロトコル固有の構造の観点から述べることができます
(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、Peersセットのエントリ、またはProtocolSpecificInfoを正規化するためのルール。これには、小文字の16進文字列などの正規化が含まれる場合があります。
(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.
interfacesフィールドの形式はプロトコル固有ではなく、実装上のすべてのプロトコル間で共有されます。プロトコルが同じインターフェースで実行されているインスタンスを区別する必要がある場合、これはピアの仕様に含まれています。一般に、ピアの仕様を定義して、オペレーターが「インターフェース」フィールドを使用して、汎用インターフェース情報とプロトコル固有のピア情報の両方を指定する必要なく、リンク上のプロトコルのすべてのインスタンスを参照できるようにすることが望ましい。
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.
ただし、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.
キーは小文字の16進文字列として表され、キーの最上位オクテットが最初になります。セクション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.
この仕様では、3つのレジストリが定義されています。
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:
各登録エントリには、次の3つのフィールドが含まれている必要があります。
- 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.
レジストリには3つの列があります。最初の列は、名前プロトコルを表すUTF-8でエンコードされたUnicode文字の文字列です。 2番目の列は、UTF-8でエンコードされたUnicode文字の文字列で、プロトコル固有の情報の簡単な説明を提供します。 3番目の列は、キーテーブルでのプロトコルの使用方法を定義する仕様への参照です。
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.
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]
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]
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によって資金提供されています。
[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, <http://www.unicode.org/reports/tr15/tr15-39.html>.
[UAX15] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode Normalization Forms」、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コンソーシアム、「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 />。
[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: housley@vigilsec.com
Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール：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
Tim Polk National Institute of Standards and Technology 100 Bureau Drive、Mail Stop 8930 Gaithersburg、MD 20899-8930 USAメール：tim.polk@nist.gov
Sam Hartman Painless Security, LLC USA EMail: hartmans-ietf@mit.edu
Sam Hartman Painless Security、LLC USA EMail：hartmans-ietf@mit.edu
Dacheng Zhang Huawei Technologies Co. Ltd. China EMail: zhangdacheng@huawei.com
DA Cheng Zhang hu Aはテクノロジー株式会社です。中国のメール：张大成@华华.com