[要約] RFC 7211は、ルーターキーの操作モデルに関する標準化ドキュメントであり、ルーターのキー管理と交換に関する手順とポリシーを定義しています。このRFCの目的は、セキュリティを向上させるために、ルーターのキー操作に関する一貫性と効率性を提供することです。
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7211 Painless Security
Category: Informational D. Zhang
ISSN: 2070-1721 Huawei Technologies Co. Ltd.
June 2014
Operations Model for Router Keying
ルーターキーイングの操作モデル
Abstract
概要
The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.
IETFは、RFC 6518、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」で説明されている設計ガイドラインに従って、ルーティングプロトコル認証のセキュリティを分析する取り組みに従事しています。これらの取り組みを展開するには、すべてのルーティングプロトコルで機能するルーティングプロトコルセキュリティの運用および管理モデルを開発することが重要です。このドキュメントは、ルーター認証の管理と運用に関して、オペレーターと実装者に推奨事項を提供します。これらの推奨事項は、プロトコル設計者が直面する管理の問題を理解するのにも役立ちます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7211.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7211で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Breakdown of KARP Configuration . . . . . . . . . . . . . . . 3
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . 5
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 5
3.3. Interactions with Automated Key Management . . . . . . . 6
3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 6
4. Credentials and Authorization . . . . . . . . . . . . . . . . 6
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 9
4.1.2. Key Separation and Protocol Design . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 10
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The Role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 12
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 14
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
The Keying and Authentication of Routing Protocols (KARP) working group is designing improvements to the cryptographic authentication of IETF routing protocols. These improvements include enhancing how integrity functions are handled within each protocol as well as designing an automated key management solution.
ルーティングプロトコルのキーイングと認証（KARP）ワーキンググループは、IETFルーティングプロトコルの暗号化認証の改善を設計しています。これらの改善には、各プロトコル内での整合性機能の処理方法の強化や、自動鍵管理ソリューションの設計が含まれます。
This document discusses issues to consider when thinking about the operational and management model for KARP. Each implementation will take its own approach to management; this is one area for vendor differentiation. However, it is desirable to have a common baseline for the management objects allowing administrators, security architects, and protocol designers to understand what management capabilities they can depend on in heterogeneous environments. Similarly, designing and deploying the protocol will be easier when thought is paid to a common operational model. This will also help with the design of NETCONF schemas or MIBs later. This document provides recommendations to help establish such a baseline.
このドキュメントでは、KARPの運用モデルと管理モデルについて検討する際に考慮すべき問題について説明します。各実装は、独自の管理アプローチを採用します。これは、ベンダーを差別化するための1つの領域です。ただし、管理者、セキュリティアーキテクト、およびプロトコル設計者が異機種環境で依存できる管理機能を理解できるように、管理オブジェクトに共通のベースラインを設定することが望ましいです。同様に、一般的な運用モデルを考慮すると、プロトコルの設計と展開が容易になります。これは、後でNETCONFスキーマまたはMIBを設計する際にも役立ちます。このドキュメントは、そのようなベースラインを確立するのに役立つ推奨事項を提供します。
This document also gives recommendations for how management and operational issues can be approached as protocols are revised and as support is added for the key table [RFC7210].
このドキュメントでは、プロトコルが改訂され、キーテーブル[RFC7210]のサポートが追加されたときに、管理と運用の問題に対処する方法に関する推奨事項も示しています。
Routing security faces interesting challenges not present with some other security domains. Routers need to function in order to establish network connectivity. As a result, centralized services cannot typically be used for authentication or other security tasks; see Section 4.4. In addition, routers' roles affect how new routers are installed and how problems are handled; see Section 6.
ルーティングセキュリティは、他の一部のセキュリティドメインにはない興味深い課題に直面しています。ルーターは、ネットワーク接続を確立するために機能する必要があります。その結果、一元化されたサービスは通常、認証やその他のセキュリティタスクに使用できません。セクション4.4を参照してください。さらに、ルーターの役割は、新しいルーターのインストール方法と問題の処理方法に影響します。セクション6を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Routing authentication configuration includes configuration of key material used to authenticate routers as well as parameters needed to use these keys. Configuration also includes information necessary to use an automated key management protocol to configure router keying. The key table [RFC7210] describes configuration needed for manual keying. Configuration of automated key management is a work in progress.
ルーティング認証の構成には、ルーターの認証に使用されるキーマテリアルの構成と、これらのキーを使用するために必要なパラメーターが含まれます。構成には、自動キー管理プロトコルを使用してルーターのキーイングを構成するために必要な情報も含まれています。キーテーブル[RFC7210]には、手動キーイングに必要な設定が記述されています。自動鍵管理の構成は進行中の作業です。
There are multiple ways of structuring configuration information. One factor to consider is the scope of the configuration information. Several protocols are peer-to-peer routing protocols where a different key could potentially be used for each neighbor. Other protocols require that the same group key be used for all nodes in an administrative domain or routing area. In other cases, the same group key needs to be used for all routers on an interface, but different group keys can be used for each interface.
構成情報を構成する方法は複数あります。考慮すべき1つの要素は、構成情報の範囲です。いくつかのプロトコルはピアツーピアルーティングプロトコルで、各ネイバーに異なるキーが使用される可能性があります。他のプロトコルでは、管理ドメインまたはルーティング領域のすべてのノードに同じグループキーを使用する必要があります。他の場合では、インターフェイス上のすべてのルーターに同じグループキーを使用する必要がありますが、インターフェイスごとに異なるグループキーを使用できます。
Within situations where a per-interface, per-area, or per-peer key can be used for manually configured long-term keys, that flexibility may not be desirable from an operational standpoint. For example, consider OSPF [RFC2328]. Each router on an OSPF link needs to use the same authentication configuration, including the set of keys used for reception and the set of keys used for transmission, but it may use different keys for different links. The most general management model would be to configure keys per link. However, for deployments where the area uses the same key, it would be strongly desirable to configure the key as a property of the area. If the keys are configured per link, they can get out of sync. In order to support generality of configuration and common operational situations, it would be desirable to have some sort of inheritance where default configurations are made per area unless overridden per interface.
インターフェイスごと、エリアごと、またはピアごとのキーを手動で構成された長期キーに使用できる状況では、運用の観点からその柔軟性は望ましくない場合があります。たとえば、OSPF [RFC2328]を検討してください。 OSPFリンク上の各ルーターは、受信に使用されるキーのセットと送信に使用されるキーのセットを含む、同じ認証構成を使用する必要がありますが、リンクごとに異なるキーを使用する場合があります。最も一般的な管理モデルは、リンクごとにキーを構成することです。ただし、エリアが同じキーを使用する展開の場合、キーをエリアのプロパティとして設定することが強く望まれます。キーがリンクごとに構成されている場合、それらは同期しなくなる可能性があります。構成の一般性と一般的な運用状況をサポートするために、インターフェイスごとにオーバーライドされない限り、デフォルトの構成がエリアごとに行われる、ある種の継承があることが望ましいでしょう。
As described in [RFC7210], the cryptographic keys are separated from the interface configuration into their own configuration store. Each routing protocol is responsible for defining the form of the peer specification used by that protocol. Thus, each routing protocol needs to define the scope of keys. For group keying, the peer specification names the group. A protocol could define a peer specification indicating the key had a link scope and also a peer specification for scoping a key to a specific area. For link-scoped keys, it is generally best to define a single peer specification indicating the key has a link scope and to use interface restrictions to restrict the key to the appropriate link.
[RFC7210]で説明されているように、暗号化キーはインターフェイス構成から独自の構成ストアに分離されます。各ルーティングプロトコルは、そのプロトコルで使用されるピア仕様の形式を定義します。したがって、各ルーティングプロトコルはキーのスコープを定義する必要があります。グループキーイングの場合、ピア仕様はグループに名前を付けます。プロトコルは、キーにリンクスコープがあることを示すピア仕様と、キーを特定の領域にスコープするためのピア仕様を定義できます。リンクスコープのキーの場合、一般に、キーにリンクスコープがあることを示す単一のピア仕様を定義し、インターフェイス制限を使用してキーを適切なリンクに制限するのが最善です。
Operational Requirements: implementations of this model MUST support configuration of keys at the most general scope for the underlying protocol; protocols supporting per-peer keys MUST permit configuration of per-peer keys, protocols supporting per-interface keys MUST support configuration of per-interface keys, and so on for any additional scopes. Implementations MUST NOT permit configuration of an inappropriate key scope. For example, configuration of separate keys per interface would be inappropriate to support for a protocol requiring per-area keys. This restriction can be enforced by rules specified by each routing protocol for validating key table entries. As such, these implementation requirements are best addressed by care being taken in how routing protocols specify the use of the key tables.
運用要件：このモデルの実装は、基になるプロトコルの最も一般的なスコープでキーの構成をサポートする必要があります。ピアごとのキーをサポートするプロトコルは、ピアごとのキーの構成を許可する必要があり、インターフェースごとのキーをサポートするプロトコルは、インターフェースごとのキーの構成をサポートする必要があります。実装では、不適切なキースコープの構成を許可してはなりません。たとえば、インターフェイスごとに個別のキーを設定することは、エリアごとのキーを必要とするプロトコルのサポートには不適切です。この制限は、キーテーブルエントリを検証するために、各ルーティングプロトコルで指定されたルールによって適用できます。したがって、これらの実装要件は、ルーティングプロトコルがキーテーブルの使用を指定する方法に注意を払うことで最も適切に対処されます。
The routing key table [RFC7210] provides a very general mechanism to abstract the storage of keys for routing protocols. To avoid misconfiguration and simplify problem determination, the router MUST verify the internal consistency of entries added to the table. Routing protocols describe how their protocol interacts with the key table including what validation MUST be performed. At a minimum, the router MUST verify:
ルーティングキーテーブル[RFC7210]は、ルーティングプロトコルのキーのストレージを抽象化する非常に一般的なメカニズムを提供します。設定ミスを回避し、問題判別を簡素化するために、ルータはテーブルに追加されたエントリの内部の一貫性を検証する必要があります。ルーティングプロトコルは、実行する必要がある検証を含め、プロトコルがキーテーブルとどのように相互作用するかを記述します。少なくとも、ルーターは以下を確認する必要があります。
o The cryptographic algorithms are valid for the protocol.
o 暗号アルゴリズムは、プロトコルに対して有効です。
o The key derivation function is valid for the protocol.
o 鍵導出関数は、プロトコルに対して有効です。
o The direction is valid for the protocol. For example, if a protocol requires the same session key be used in both directions, the direction field in the key table entry associated with the session key MUST be specified as "both".
o 方向はプロトコルに対して有効です。たとえば、プロトコルが同じセッションキーを両方向で使用する必要がある場合、セッションキーに関連付けられたキーテーブルエントリの方向フィールドを「両方」として指定する必要があります。
o The peer specification is consistent with the protocol.
o ピアの仕様はプロトコルと一致しています。
Other checks are possible. For example, the router could verify that if a key is associated with a peer, that peer is a configured peer for the specified protocol. However, this may be undesirable. It may be desirable to load a key table when some peers have not yet been configured. Also, it may be desirable to share portions of a key table across devices even when their current configuration does not require an adjacency with a particular peer in the interest of uniform configuration or preparing for fail-over. For these reasons, these additional checks are generally undesirable.
他のチェックも可能です。たとえば、ルーターは、キーがピアに関連付けられている場合、そのピアが指定されたプロトコルの構成済みピアであることを確認できます。ただし、これは望ましくない場合があります。一部のピアがまだ構成されていない場合は、キーテーブルをロードすることが望ましい場合があります。また、現在の構成が特定のピアとの隣接関係を必要としない場合でも、統一された構成またはフェイルオーバーの準備のために、デバイス間でキーテーブルの一部を共有することが望ましい場合があります。これらの理由により、これらの追加のチェックは一般に望ましくありません。
Several management interfaces will be quite common. For service provider deployments, the configuration management system can simply update the key table. However, for smaller deployments, efficient management interfaces that do not require a configuration management system are important. In these environments, configuration interfaces (such as web interfaces and command-line interfaces) provided directly by the router will be important for easy management of the router.
いくつかの管理インターフェースは非常に一般的です。サービスプロバイダーの導入の場合、構成管理システムはキーテーブルを更新するだけで済みます。ただし、小規模な展開では、構成管理システムを必要としない効率的な管理インターフェイスが重要です。これらの環境では、ルーターから直接提供される構成インターフェース（Webインターフェースやコマンドラインインターフェースなど）がルーターの管理を容易にするために重要になります。
As part of adding a new key, it is typically desirable to set an expiration time for an old key. The management interface SHOULD provide a mechanism to easily update the expiration time for a current key used with a given peer or interface. Also, when adding a key, it is desirable to push the key out to nodes that will need it, allowing use for receiving packets and then later for enabling transmit. This can be accomplished automatically by providing a delay between when a key becomes valid for reception and transmission. However, some environments may not be able to predict when all the necessary changes will be made. In these cases, having a mechanism to enable a key for sending is desirable. The management interface SHOULD provide an easy mechanism to update the direction of an existing key or to enable a disabled key.
新しいキーを追加する一環として、通常、古いキーの有効期限を設定することが望ましいです。管理インターフェースは、特定のピアまたはインターフェースで使用される現在の鍵の有効期限を簡単に更新するメカニズムを提供する必要があります（SHOULD）。また、キーを追加するときは、そのキーを必要とするノードにキーをプッシュして、パケットの受信に使用できるようにし、後で送信を有効にすることが望ましいです。これは、キーが受信と送信で有効になるまでの遅延を提供することにより、自動的に実行できます。ただし、一部の環境では、必要なすべての変更がいつ行われるかを予測できない場合があります。これらのケースでは、送信用のキーを有効にするメカニズムを持つことが望ましいです。管理インターフェースは、既存のキーの方向を更新したり、無効なキーを有効にしたりするための簡単なメカニズムを提供する必要があります（SHOULD）。
Implementations SHOULD permit a configuration in which if no unexpired key is available, existing security associations continue using the expired key with which they were established. Implementations MUST support a configuration in which security associations fail if no unexpired key is available for them. See Section 6.2 for a discussion of reporting and managing security faults including those related to key expiration.
実装は、有効期限が切れていないキーが利用できない場合、既存のセキュリティ結合が、それらが確立された有効期限が切れたキーを引き続き使用する構成を許可する必要があります（SHOULD）。実装は、セキュリティアソシエーションが期限切れでないキーを使用できない場合にセキュリティアソシエーションが失敗する構成をサポートする必要があります。キーの失効に関連するものを含むセキュリティ障害の報告と管理については、セクション6.2を参照してください。
Consideration is required for how an automated key management protocol will assign key IDs for group keys. All members of the group may need to use the same key ID. This requires careful coordination of global key IDs. Interactions with the peer key ID field may make this easier; this requires additional study.
自動鍵管理プロトコルがグループ鍵に鍵IDをどのように割り当てるかを考慮する必要があります。グループのすべてのメンバーが同じキーIDを使用する必要がある場合があります。これには、グローバルキーIDの注意深い調整が必要です。ピアキーIDフィールドとの相互作用により、これが容易になる場合があります。これには追加の調査が必要です。
Automated key management protocols also assign keys for single peers. If the key ID is global and needs to be coordinated between the receiver and transmitter, then there is complexity in key management protocols that can be avoided if key IDs are not global.
自動鍵管理プロトコルは、単一のピアに鍵を割り当てます。キーIDがグローバルであり、レシーバーとトランスミッター間で調整する必要がある場合、キーIDがグローバルでない場合に回避できるキー管理プロトコルは複雑になります。
Many core and enterprise routers support multiple routing instances. For example, a router serving multiple VPNs is likely to have a forwarding/routing instance for each of these VPNs. Each VRF will require its own routing key table.
多くのコアおよびエンタープライズルーターは、複数のルーティングインスタンスをサポートしています。たとえば、複数のVPNにサービスを提供するルーターには、これらのVPNごとに転送/ルーティングインスタンスが存在する可能性があります。各VRFには独自のルーティングキーテーブルが必要です。
Several methods for authentication have been proposed for KARP. The simplest is preshared keys used directly as traffic keys. In this mode, the traffic integrity keys are directly configured. This is the mode supported by most of today's routing protocols.
KARPでは、いくつかの認証方法が提案されています。最も単純なのは、トラフィックキーとして直接使用される事前共有キーです。このモードでは、トラフィック整合性キーが直接構成されます。これは、今日のほとんどのルーティングプロトコルでサポートされているモードです。
As discussed in [RTG-AUTH], preshared keys can be used as the input to a key derivation function (KDF) to generate traffic keys. For example, the TCP Authentication Option (TCP-AO) [RFC5925] derives keys based on the initial TCP session state. Typically, a KDF will combine a long-term key with public inputs exchanged as part of the protocol to form fresh session keys. A KDF could potentially be used with some inputs that are configured along with the long-term key. Also, it's possible that inputs to a KDF will be private and exchanged as part of the protocol, although this will be uncommon in KARP's uses of KDFs.
[RTG-AUTH]で説明したように、事前共有鍵は、鍵導出関数（KDF）への入力として使用して、トラフィック鍵を生成できます。たとえば、TCP認証オプション（TCP-AO）[RFC5925]は、初期のTCPセッション状態に基づいてキーを導出します。通常、KDFは長期鍵をプロトコルの一部として交換される公開入力と組み合わせて、新しいセッション鍵を形成します。 KDFは、長期鍵とともに構成されている一部の入力で使用される可能性があります。また、KDFへの入力はプライベートであり、プロトコルの一部として交換される可能性がありますが、これはKARPによるKDFの使用では一般的ではありません。
Preshared keys could also be used by an automated key management protocol. In this mode, preshared keys would be used for authentication. However, traffic keys would be generated by some key-agreement mechanism or transported in a key encryption key derived from the preshared key. This mode may provide better replay protection. Also, in the absence of active attackers, key-agreement strategies such as Diffie-Hellman can be used to produce high-quality traffic keys even from relatively weak preshared keys. These key-agreement mechanisms are valuable even when active attackers are present, although an active attacker can mount a man-in-the-middle attack if the preshared key is sufficiently weak.
事前共有キーは、自動キー管理プロトコルでも使用できます。このモードでは、事前共有キーが認証に使用されます。ただし、トラフィック鍵は、何らかの鍵合意メカニズムによって生成されるか、事前共有鍵から導出された鍵暗号鍵で転送されます。このモードは、より優れた再生保護を提供します。また、アクティブな攻撃者がいない場合、Diffie-Hellmanなどのキー一致戦略を使用して、比較的弱い事前共有キーからでも高品質のトラフィックキーを生成できます。事前共有キーが十分に弱い場合、アクティブな攻撃者は中間者攻撃を開始できますが、これらのキー一致メカニズムはアクティブな攻撃者が存在する場合でも価値があります。
Public keys can be used for authentication within an automated key management protocol. The KARP design guide [RFC6518] describes a mode in which routers have the hashes of peer routers' public keys. In this mode, a traditional public-key infrastructure is not required. The advantage of this mode is that a router only contains its own keying material, limiting the scope of a compromise. The disadvantage is that when a router is added or deleted from the set of authorized routers, all routers in that set need to be updated. Note that self-signed certificates are a common way of communicating public keys in this style of authentication.
公開鍵は、自動鍵管理プロトコル内の認証に使用できます。 KARP設計ガイド[RFC6518]は、ルーターがピアルーターの公開キーのハッシュを持つモードについて説明しています。このモードでは、従来の公開鍵インフラストラクチャは必要ありません。このモードの利点は、ルーターには独自のキー情報しか含まれていないため、侵害の範囲が限定されることです。欠点は、承認済みルーターのセットからルーターが追加または削除されると、そのセット内のすべてのルーターを更新する必要があることです。自己署名証明書は、このスタイルの認証で公開鍵を通信する一般的な方法であることに注意してください。
Certificates signed by a certification authority or some other PKI could be used for authentication within an automated key management protocol. The advantage of this approach is that routers may not need to be directly updated when peers are added or removed. The disadvantage is that more complexity and cost are required.
証明機関またはその他のPKIによって署名された証明書は、自動キー管理プロトコル内の認証に使用できます。このアプローチの利点は、ピアが追加または削除されたときにルーターを直接更新する必要がない場合があることです。欠点は、より複雑でコストがかかることです。
Each of these approaches has a different set of management and operational requirements. Key differences include how authorization is handled and how identity works. This section discusses these differences.
これらのアプローチはそれぞれ、管理と運用の要件のセットが異なります。主な違いには、承認の処理方法とIDの動作方法が含まれます。このセクションでは、これらの違いについて説明します。
In the protocol, manual preshared keys are either unnamed or named by a key ID (which is a small integer -- typically 16 or 32 bits). Implementations that support multiple keys for protocols that have no names for keys need to try all possible keys before deciding a packet cannot be validated [RFC4808]. Typically key IDs are names used by one group or peer.
このプロトコルでは、手動の事前共有キーは、名前が付けられていないか、キーID（小さな整数で、通常は16または32ビット）によって名前が付けられています。キーの名前がないプロトコルの複数のキーをサポートする実装は、パケットを検証できないと判断する前に、可能なすべてのキーを試す必要があります[RFC4808]。通常、キーIDは1つのグループまたはピアが使用する名前です。
Manual preshared keys are often known by a group of peers rather than just one other peer. This is an interesting security property: unlike with digitally signed messages or protocols where symmetric keys are known only to two parties, it is impossible to identify the peer sending a message cryptographically. However, it is possible to show that the sender of a message is one of the parties who knows the preshared key. Within the routing threat model, the peer sending a message can be identified only because peers are trusted and thus can be assumed to correctly label the packets they send. This contrasts with a protocol where cryptographic means such as digital signatures are used to verify the origin of a message. As a consequence, authorization is typically based on knowing the preshared key rather than on being a particular peer. Note that once an authorization decision is made, the peer can assert its identity; this identity is trusted just as the routing information from the peer is trusted. Doing an additional check for authorization based on the identity included in the packet would provide little value: an attacker who somehow had the key could claim the identity of an authorized peer, and an attacker without the key should be unable to claim the identity of any peer. Such a check is not required by the KARP threat model: inside attacks are not in scope.
手動の事前共有鍵は、他の1つのピアだけでなく、ピアのグループによく知られています。これは興味深いセキュリティプロパティです。デジタル署名されたメッセージや対称キーが2つの当事者だけに知られているプロトコルとは異なり、メッセージを送信するピアを暗号で識別することは不可能です。ただし、メッセージの送信者が事前共有キーを知っている当事者の1人であることを示すことは可能です。ルーティング脅威モデル内では、メッセージを送信するピアは、ピアが信頼され、送信するパケットに正しくラベルを付けると想定できるためにのみ識別できます。これは、デジタル署名などの暗号化手段を使用してメッセージの発信元を検証するプロトコルとは対照的です。その結果、承認は通常、特定のピアであるというよりも、事前共有キーを知ることに基づいています。承認の決定が行われると、ピアはそのアイデンティティをアサートできることに注意してください。このIDは、ピアからのルーティング情報が信頼されるのと同じように信頼されます。パケットに含まれているIDに基づいて承認の追加チェックを行っても、ほとんど価値はありません。何らかの方法でキーを持っている攻撃者は、許可されたピアのIDを要求でき、キーを持たない攻撃者はいずれのIDも要求できません。ピア。このようなチェックはKARP脅威モデルでは必要ありません。内部攻撃は対象外です。
Preshared keys used with key derivation work similarly to manual preshared keys. However, to form the actual traffic keys, session-or peer-specific information is combined with the key. From an authorization standpoint, the derivation key works the same as a manual key. An additional routing protocol step or transport step forms the key that is actually used.
鍵導出で使用される事前共有鍵は、手動事前共有鍵と同様に機能します。ただし、実際のトラフィックキーを形成するために、セッションまたはピア固有の情報がキーと結合されます。承認の観点から見ると、派生キーは手動キーと同じように機能します。追加のルーティングプロトコルステップまたはトランスポートステップにより、実際に使用されるキーが形成されます。
Preshared keys that are used via automatic key management have not yet been specified for KARP, although ongoing work suggests they will be needed. Their naming and authorization may differ from existing uses of preshared keys in routing protocols. In particular, such keys may end up being known only by two peers. Alternatively, they may also be known by a group of peers. Authorization could potentially be based on peer identity, although it is likely that knowing the right key will be sufficient. There does not appear to be a compelling reason to decouple the authorization of a key for some purpose from the authorization of peers holding that key to perform the authorized function.
自動鍵管理を介して使用される事前共有鍵は、KARPにはまだ指定されていませんが、継続的な作業により、必要になることが示唆されています。それらの名前と承認は、ルーティングプロトコルでの事前共有キーの既存の使用とは異なる場合があります。特に、そのようなキーは、2つのピアだけが知っていることになります。あるいは、それらはピアのグループによって知られている場合もあります。承認はピアのアイデンティティに基づいて行われる可能性がありますが、正しいキーを知っていれば十分である可能性があります。承認された機能を実行するために、そのキーを保持しているピアの承認から、何らかの目的でキーの承認を切り離すための説得力のある理由はないようです。
Care needs to be taken when symmetric keys are used for multiple purposes. Consider the implications of using the same preshared key for two interfaces: it becomes impossible to cryptographically distinguish a router on one interface from a router on another interface. So, a router that is trusted to participate in a routing protocol on one interface becomes implicitly trusted for the other interfaces that share the key. For many cases, such as link-state routers in the same routing area, there is no significant advantage that an attacker could gain from this trust within the KARP threat model. However, other protocols, such as BGP and RIP, permit routes to be filtered across a trust boundary. For these protocols, participation in one interface might be more advantageous than another. Operationally, when this trust distinction is important to a deployment, different keys need to be used on each side of the trust boundary. Key derivation can help prevent this problem in cases of accidental misconfiguration. However, key derivation cannot protect against a situation where a system was incorrectly trusted to have the key used to perform the derivation. This question of trust is important to the KARP threat model because it is essential to determining whether a party is an insider for a particular routing protocol. A customer router that is an insider for a BGP peering relationship with a service provider is not typically an insider when considering the security of that service provider's IGP. Similarly, to the extent that there are multiple zones of trust and a routing protocol is determining whether a particular router is within a certain zone, the question of untrusted actors is within the scope of the routing threat model.
対称鍵を複数の目的で使用する場合は注意が必要です。 2つのインターフェースに同じ事前共有鍵を使用することの影響を考慮してください。あるインターフェースのルーターを別のインターフェースのルーターから暗号で区別することが不可能になります。したがって、1つのインターフェイスのルーティングプロトコルに参加することが信頼されているルーターは、キーを共有する他のインターフェイスに対して暗黙的に信頼されます。同じルーティングエリア内のリンクステートルーターなどの多くの場合、攻撃者がKARP脅威モデル内のこの信頼から得ることができる大きな利点はありません。ただし、BGPやRIPなどの他のプロトコルでは、信頼境界を越えてルートをフィルタリングできます。これらのプロトコルの場合、1つのインターフェースへの参加が別のインターフェースよりも有利な場合があります。運用上、この信頼の区別がデプロイメントにとって重要である場合、信頼境界の両側で異なるキーを使用する必要があります。鍵の導出は、偶発的な設定ミスの場合にこの問題を防ぐのに役立ちます。ただし、キーの導出は、システムが導出の実行に使用されるキーを持っていると誤って信頼されている状況から保護することはできません。この信頼の問題は、当事者が特定のルーティングプロトコルの内部関係者であるかどうかを判断することが不可欠であるため、KARP脅威モデルにとって重要です。サービスプロバイダーとのBGPピアリング関係のインサイダーであるカスタマールータは、そのサービスプロバイダーのIGPのセキュリティを考慮する場合、通常はインサイダーではありません。同様に、複数の信頼ゾーンがあり、ルーティングプロトコルが特定のルーターが特定のゾーン内にあるかどうかを決定している限り、信頼できないアクターの問題はルーティング脅威モデルの範囲内です。
Key derivation can be part of a management solution for having multiple keys for different zones of trust. A master key could be combined with peer, link, or area identifiers to form a router-specific preshared key that is loaded onto routers. Provided that the master key lives only on the management server and not the individual routers, trust is preserved. However, in many cases, generating independent keys for the routers and storing the result is more practical. If the master key were somehow compromised, all the resulting keys would need to be changed. However, if independent keys are used, the scope of a compromise may be more limited.
鍵の導出は、異なる信頼ゾーン用の複数の鍵を持つための管理ソリューションの一部になることができます。マスターキーをピア、リンク、またはエリア識別子と組み合わせて、ルーターに読み込まれるルーター固有の事前共有キーを形成できます。マスターキーが管理サーバーにのみ存在し、個々のルーターに存在しない場合、信頼は保持されます。ただし、多くの場合、ルーターの独立したキーを生成し、その結果を保存する方が実用的です。マスターキーが何らかの形で侵害された場合、結果として生じるすべてのキーを変更する必要があります。ただし、独立したキーが使用されている場合、侵害の範囲はさらに限定される可能性があります。
More subtle problems with key separation can appear in protocol design. Two protocols that use the same traffic keys may work together in unintended ways permitting one protocol to be used to attack the other. Consider two hypothetical protocols. Protocol A starts its messages with a set of extensions that are ignored if not understood. Protocol B has a fixed header at the beginning of its messages but ends messages with extension information. It may be that the same message is valid both as part of protocol A and protocol B. An attacker may be able to gain an advantage by getting a router to generate this message with one protocol under situations where the other protocol would not generate the message. This hypothetical example is overly simplistic; real-world attacks exploiting key separation weaknesses tend to be complicated and involve specific properties of the cryptographic functions involved. The key point is that whenever the same key is used in multiple protocols, attacks may be possible. All the involved protocols need to be analyzed to understand the scope of potential attacks.
キーの分離に関するさらに微妙な問題がプロトコル設計に現れることがあります。同じトラフィックキーを使用する2つのプロトコルが意図しない方法で連携して、1つのプロトコルを使用して他のプロトコルを攻撃する可能性があります。 2つの架空のプロトコルを考えます。プロトコルAは、理解できない場合は無視される一連の拡張子でメッセージを開始します。プロトコルBは、メッセージの先頭に固定ヘッダーがありますが、メッセージを拡張情報で終了します。同じメッセージがプロトコルAとプロトコルBの両方の部分として有効である可能性があります。攻撃者は、他のプロトコルがメッセージを生成しない状況下で、ルーターにこのプロトコルを使用してこのメッセージを生成させることにより、利点を得る可能性があります。 。この架空の例は非常に単純化しています。鍵の分離の弱点を悪用する実際の攻撃は複雑になる傾向があり、関連する暗号化機能の特定の特性を伴います。重要な点は、同じキーが複数のプロトコルで使用されている場合は常に、攻撃が可能になる可能性があるということです。潜在的な攻撃の範囲を理解するには、関連するすべてのプロトコルを分析する必要があります。
Key separation attacks interact with the KARP operational model in a number of ways. Administrators need to be aware of situations where using the same manual traffic key with two different protocols (or the same protocol in different contexts) creates attack opportunities. Design teams should consider how their protocol might interact with other routing protocols and describe any attacks discovered so that administrators can understand the operational implications. When designing automated key management or new cryptographic authentication within routing protocols, we need to be aware that administrators expect to be able to use the same preshared keys in multiple contexts. As a result, we should use appropriate key derivation functions so that different cryptographic keys are used even when the same initial input key is used.
キー分離攻撃は、いくつかの方法でKARP運用モデルと相互作用します。管理者は、2つの異なるプロトコル（または異なるコンテキストで同じプロトコル）で同じ手動トラフィックキーを使用すると、攻撃の機会が生じる状況に注意する必要があります。設計チームは、管理者が運用上の影響を理解できるように、プロトコルが他のルーティングプロトコルとどのように相互作用するかを検討し、発見された攻撃を説明する必要があります。ルーティングプロトコル内で自動キー管理または新しい暗号化認証を設計する場合、管理者は複数のコンテキストで同じ事前共有キーを使用できることを期待していることを認識する必要があります。その結果、同じ初期入力キーが使用されている場合でも異なる暗号化キーが使用されるように、適切なキー導出関数を使用する必要があります。
Outside of a PKI, public keys are expected to be known by the hash of a key or (potentially self-signed) certificate. The Session Description Protocol provides a standardized mechanism for naming keys (in that case, certificates) based on hashes (Section 5 of [RFC4572]). KARP SHOULD adopt this approach or another approach already standardized within the IETF rather than inventing a new mechanism for naming public keys.
PKIの外では、公開鍵は、鍵または（潜在的に自己署名された）証明書のハッシュによって認識されることが期待されています。セッション記述プロトコルは、ハッシュ（[RFC4572]のセクション5）に基づいてキー（この場合は証明書）に名前を付けるための標準化されたメカニズムを提供します。 KARPは、公開鍵に名前を付けるための新しいメカニズムを発明するのではなく、このアプローチまたはIETF内ですでに標準化されている別のアプローチを採用する必要があります（SHOULD）。
A public key is typically expected to belong to one peer. As a peer generates new keys and retires old keys, its public key may change. For this reason, from a management standpoint, peers should be thought of as associated with multiple public keys rather than as containing a single public-key hash as an attribute of the peer object.
公開鍵は通常、1つのピアに属していると予想されます。ピアが新しいキーを生成し、古いキーをリタイアすると、その公開キーが変更される場合があります。このため、管理の観点からは、ピアは、ピアオブジェクトの属性として単一の公開キーハッシュを含むのではなく、複数の公開キーに関連付けられていると考える必要があります。
Authorization of public keys could be done either by key hash or by peer identity. Performing authorizations by peer identity should make it easier to update the key of a peer without risk of losing authorizations for that peer. However, management interfaces need to be carefully designed to avoid making this extra level of indirection complicated for operators.
公開鍵の承認は、鍵ハッシュまたはピアIDのいずれかによって行うことができます。ピアIDによって承認を実行すると、ピアの承認を失うリスクなしに、ピアのキーを簡単に更新できます。ただし、管理者インターフェースは、オペレーターにとってこの追加の間接レベルが複雑にならないように注意深く設計する必要があります。
When a PKI is used, certificates are used. The certificate binds a key to a name of a peer. The key management protocol is responsible for exchanging certificates and validating them to a trust anchor.
PKIを使用する場合、証明書が使用されます。証明書は、キーをピアの名前にバインドします。鍵管理プロトコルは、証明書の交換とトラストアンカーに対する検証を担当します。
Authorization needs to be done in terms of peer identities not in terms of keys. One reason for this is that when a peer changes its key, the new certificate needs to be sufficient for authentication to continue functioning even though the key has never been seen before.
承認は、キーではなくピアIDの観点から行う必要があります。この理由の1つは、ピアがそのキーを変更したときに、キーが以前に確認されたことがない場合でも、認証が機能し続けるには新しい証明書で十分である必要があるためです。
Potentially, authorization could be performed in terms of groups of peers rather than single peers. An advantage of this is that it may be possible to add a new router with no authentication-related configuration of the peers of that router. For example, a domain could decide that any router with a particular keyPurposeID signed by the organization's certificate authority is permitted to join the IGP. Just as in configurations where cryptographic authentication is not used, automatic discovery of this router can establish appropriate adjacencies.
潜在的に、単一のピアではなく、ピアのグループの観点から許可が実行される可能性があります。これの利点は、そのルーターのピアの認証関連の構成を持たない新しいルーターを追加できる可能性があることです。たとえば、ドメインは、組織の認証局によって署名された特定のkeyPurposeIDを持つすべてのルーターがIGPに参加することを許可されると決定できます。暗号化認証を使用しない構成と同様に、このルーターの自動検出により適切な隣接関係を確立できます。
Assuming that self-signed certificates are used by routers that wish to use public keys but that do not need a PKI, then PKI and the "infrastructure-less" mode of public-key operation described in the previous section can work well together. One router could identify its peers based on names and use certificate validation. Another router could use hashes of certificates. This could be very useful for border routers between two organizations. Smaller organizations could use public keys and larger organizations could use PKI.
自己署名証明書が、公開鍵を使用したいがPKIを必要としないルーターによって使用されると仮定すると、PKIと前のセクションで説明した公開鍵操作の「インフラストラクチャレス」モードは、うまく機能します。 1つのルーターは、名前に基づいてピアを識別し、証明書の検証を使用できます。別のルーターは、証明書のハッシュを使用できます。これは、2つの組織間の境界ルーターに非常に役立ちます。小規模な組織では公開鍵を使用でき、大規模な組織ではPKIを使用できます。
A PKI has significant operational concerns including certification practices, handling revocation, and operational practices around certificate validation. The Routing PKI (RPKI) has addressed these concerns within the scope of BGP and the validation of address ownership. Adapting these practices to routing protocol authentication is outside the scope of this document.
PKIには、認証の実践、失効の処理、証明書の検証に関する運用の実践など、運用上の重大な懸念があります。ルーティングPKI（RPKI）は、BGPの範囲内でこれらの懸念に対処し、アドレス所有権の検証を行いました。これらのプラクティスをルーティングプロトコル認証に適合させることは、このドキュメントの範囲外です。
An area to explore is the role of central servers like RADIUS or directories. Routers need to securely operate in order to provide network routing services. Routers cannot generally contact a central server while establishing routing because the router might not have a functioning route to the central service until after routing is established. As a result, a system where keys are pushed by a central management system is an undesirable result for router keying. However, central servers may play a role in authorization and key rollover. For example, a node could send a hash of a public key to a RADIUS server.
調査する領域は、RADIUSやディレクトリなどの中央サーバーの役割です。ルーターは、ネットワークルーティングサービスを提供するために安全に動作する必要があります。ルーターは、ルーティングが確立されるまで、中央サービスへのルートが機能しない可能性があるため、ルーティングを確立している間は通常、中央サーバーに接続できません。その結果、中央管理システムによってキーがプッシュされるシステムは、ルータのキーイングにとって望ましくない結果になります。ただし、中央サーバーは、承認とキーのロールオーバーで役割を果たす場合があります。たとえば、ノードは公開鍵のハッシュをRADIUSサーバーに送信できます。
If central servers do play a role, it will be critical to make sure that they are not required during routine operation or a cold-start of a network. They are more likely to play a role in enrollment of new peers or key migration/compromise.
中央サーバーが役割を果たす場合は、通常の操作またはネットワークのコールドスタート中にそれらが必要とされないことを確認することが重要です。彼らは、新しい仲間の登録や主要な移行/妥協において役割を果たす可能性が高いです。
Another area where central servers may play a role is for group key agreement. As an example, [OSPF-AUTO] discusses the potential need for key-agreement servers in OSPF. Other routing protocols that use multicast or broadcast such as IS-IS are likely to need a similar approach. Multicast key-agreement protocols need to allow operators to choose which key servers will generate traffic keys. The quality of random numbers [RFC4086] is likely to differ between systems. As a result, operators may have preferences for where keys are generated.
中央サーバーが役割を果たす可能性があるもう1つの領域は、グループキーの合意です。例として、[OSPF-AUTO]は、OSPFでの鍵合意サーバーの潜在的な必要性について説明します。 IS-ISなどのマルチキャストまたはブロードキャストを使用する他のルーティングプロトコルでも、同様のアプローチが必要になる可能性があります。マルチキャストキー合意プロトコルでは、オペレーターがトラフィックキーを生成するキーサーバーを選択できる必要があります。乱数の品質[RFC4086]は、システム間で異なる可能性があります。その結果、オペレーターは、キーが生成される場所を好みます。
One significant management consideration will be the grouping of management objects necessary to determine who is authorized to act as a peer for a given routing action. As discussed previously, the following objects are potentially required:
管理上の重要な考慮事項の1つは、特定のルーティングアクションのピアとして動作することを承認されているユーザーを決定するために必要な管理オブジェクトのグループ化です。前述のように、次のオブジェクトが潜在的に必要です。
o Key objects are required. Symmetric keys may be preshared, and knowledge of the key may be used as the decision factor in authorization. Knowledge of the private key corresponding to asymmetric public keys may be used directly for authorization as well. During key transitions, more than one key may refer to a given peer. Group preshared keys may refer to multiple peers.
o キーオブジェクトが必要です。対称鍵は事前共有することができ、鍵の知識を許可の決定要素として使用できます。非対称公開鍵に対応する秘密鍵の知識は、認証にも直接使用できます。キーの移行中、複数のキーが特定のピアを参照する場合があります。グループ事前共有キーは複数のピアを参照する場合があります。
o Peer objects are required. A peer is a router that this router might wish to communicate with. Peers may be identified by names or keys.
o ピアオブジェクトが必要です。ピアは、このルーターが通信する可能性のあるルーターです。ピアは名前またはキーで識別できます。
o Objects representing peer groups are required. Groups of peers may be authorized for a given routing protocol.
o ピアグループを表すオブジェクトが必要です。ピアのグループは、特定のルーティングプロトコルに対して許可される場合があります。
Establishing a management model is difficult because of the complex relationships between each set of objects. As discussed, there may be more than one key for a peer. However, in the preshared key case, there may be more than one peer for a key. This is true both for group security association protocols such as an IGP or one-to-one protocols where the same key is used administratively. In some of these situations, it may be undesirable to explicitly enumerate the peers in the configuration; for example, IGP peers are auto-discovered for broadcast links but not for non-broadcast multi-access links.
オブジェクトの各セット間の関係が複雑なため、管理モデルの確立は困難です。説明したように、ピアには複数のキーが存在する場合があります。ただし、事前共有キーの場合は、キーに複数のピアがある場合があります。これは、IGPのようなグループセキュリティアソシエーションプロトコルにも、同じキーが管理上使用される1対1プロトコルにも当てはまります。これらの状況の一部では、構成内のピアを明示的に列挙することが望ましくない場合があります。たとえば、IGPピアは、ブロードキャストリンクでは自動検出されますが、非ブロードキャストマルチアクセスリンクでは自動検出されません。
Peers may be identified either by name or key. If peers are identified by key, it is strongly desirable from an operational standpoint to consider any peer identifiers or names to be a local matter and not require the identifiers or names to be synchronized. Obviously, if peers are identified by names (for example, with certificates in a PKI), identifiers need to be synchronized between the authorized peer and the peer making the authorization decision.
ピアは名前またはキーで識別できます。ピアがキーによって識別される場合、運用上の観点から、ピアの識別子または名前をローカルな問題であると見なし、識別子または名前を同期する必要がないことを強くお勧めします。明らかに、ピアが名前で識別される場合（たとえば、PKIの証明書を使用）、識別子は、承認されたピアと承認決定を行うピアとの間で同期する必要があります。
In many cases, peers will explicitly be identified in routing protocol configuration. In these cases, it is possible to attach the authorization information (keys or identifiers) to the peer's configuration object. Two cases do not involve enumerating peers. The first is the case where preshared keys are shared among a group of peers. It is likely that this case can be treated from a management standpoint as a single peer representing all the peers that share the keys. The other case is one where certificates in a PKI are used to introduce peers to a router. In this case, rather than configuring peers, the router needs to be configured with information on which certificates represent acceptable peers.
多くの場合、ピアはルーティングプロトコル構成で明示的に識別されます。これらの場合、承認情報（キーまたは識別子）をピアの構成オブジェクトに添付することが可能です。 2つのケースには、ピアの列挙は含まれません。 1つは、事前共有鍵がピアのグループ間で共有される場合です。このケースは、管理の観点から、鍵を共有するすべてのピアを表す単一のピアとして扱うことができる可能性があります。もう1つのケースは、PKIの証明書を使用してピアをルーターに導入する場合です。この場合、ピアを構成するのではなく、どの証明書が受け入れ可能なピアを表すかに関する情報をルーターに構成する必要があります。
Another consideration is which routing protocols share peers. For example, it may be common for LDP peers to also be peers of some other routing protocol. Also, RSVP - Traffic Engineering (RSVP-TE) may be associated with some TE-based IGP. In some of these cases, it would be desirable to use the same authorization information for both routing protocols.
別の考慮事項は、どのルーティングプロトコルがピアを共有するかです。たとえば、LDPピアが他のルーティングプロトコルのピアになることもよくあります。また、RSVP-トラフィックエンジニアリング（RSVP-TE）は、一部のTEベースのIGPに関連付けられている場合があります。これらのケースのいくつかでは、両方のルーティングプロトコルに同じ認証情報を使用することが望ましいでしょう。
Finally, as discussed in Section 7, it is sometimes desirable to override some aspect of the configuration for a peer in a group. As an example, when rotating to a new key, it is desirable to be able to roll that key out to each peer that will use the key, even if in the stable state the key is configured for a peer group.
最後に、セクション7で説明したように、グループ内のピアの構成の一部の側面をオーバーライドすることが望ましい場合があります。例として、新しいキーにローテーションする場合、安定状態でキーがピアグループ用に構成されている場合でも、そのキーを使用する各ピアにそのキーをロールアウトできることが望ましいです。
In order to develop a management model for authorization, the working group needs to consider several questions. What protocols support auto-discovery of peers? What protocols require more configuration of a peer than simply the peer's authorization information and network address? What management operations are going to be common as security information for peers is configured and updated? What operations will be common while performing key transitions or while migrating to new security technologies?
承認の管理モデルを開発するために、ワーキンググループはいくつかの質問を考慮する必要があります。ピアの自動検出をサポートするプロトコルは何ですか？ピアの承認情報とネットワークアドレスだけでなく、ピアの構成を多く必要とするプロトコルはどれですか。ピアのセキュリティ情報が構成および更新されると、どの管理操作が一般的になりますか？主要な移行の実行中、または新しいセキュリティテクノロジーへの移行中に、どのような操作が一般的になりますか？
One key operational question is what areas will administrator involvement be required. Likely areas where involvement may be useful include enrollment of new peers. Fault recovery should also be considered.
運用上の重要な問題の1つは、管理者の関与が必要な領域です。関与が有用である可能性が高い領域には、新しい仲間の登録が含まれます。障害回復も考慮する必要があります。
One area where the management of routing security needs to be optimized is the deployment of a new router. In some cases, a new router may be deployed on an existing network where routing to management servers is already available. In other cases, routers may be deployed as part of connecting or creating a site. Here, the router and infrastructure may not be available until the router has securely authenticated.
ルーティングセキュリティの管理を最適化する必要がある1つの領域は、新しいルーターの展開です。場合によっては、管理サーバーへのルーティングが既に利用可能な既存のネットワークに新しいルーターが展開されることがあります。他の場合では、ルーターはサイトの接続または作成の一部として展開されます。ここで、ルーターとインフラストラクチャは、ルーターが安全に認証されるまで使用できない場合があります。
In general, security configuration can be treated as an additional configuration item that needs to be set up to establish service. There is no significant security value in protecting routing protocol keys more than administrative password or Authentication, Authorization, and Accounting (AAA) secrets that can be used to gain login access to a router. These existing secrets can be used to make configuration changes that impact routing protocols as much as disclosure of a routing protocol key. Operators already have procedures in place for these items. So, it is appropriate to use similar procedures for routing protocol keys. It is reasonable to improve existing configuration procedures and the routing protocol procedures over time. However, it is more desirable to deploy KARP with security similar to that used for managing existing secrets than to delay deploying KARP.
一般に、セキュリティ構成は、サービスを確立するために設定する必要がある追加の構成項目として扱うことができます。ルーターへのログインアクセスを取得するために使用できる管理パスワードまたは認証、承認、アカウンティング（AAA）シークレットを超えるルーティングプロトコルキーを保護することには、重要なセキュリティ上の価値はありません。これらの既存のシークレットを使用して、ルーティングプロトコルに影響を与える構成変更を、ルーティングプロトコルキーの開示と同じくらい行うことができます。オペレーターは、これらのアイテムの手順を既に用意しています。したがって、プロトコルキーのルーティングには同様の手順を使用するのが適切です。時間の経過とともに、既存の構成手順とルーティングプロトコル手順を改善することは合理的です。ただし、KARPの展開を遅らせるよりも、既存のシークレットの管理に使用されるセキュリティと同様のセキュリティでKARPを展開する方が望ましいです。
Operators MAY develop higher assurance procedures for dealing with keys. For example, asymmetric keys can be generated on a router and never exported from the router. Operators can evaluate the cost vs. security and the availability tradeoffs of these procedures.
オペレーターは、キーを処理するためのより高い保証手順を開発できます（MAY）。たとえば、非対称鍵をルーターで生成し、ルーターからエクスポートすることはできません。オペレーターは、これらの手順のコストとセキュリティ、および可用性のトレードオフを評価できます。
Faults may interact with operational practice in at least two ways. First, security solutions may introduce faults. For example, if certificates expire in a PKI, previous adjacencies may no longer form. Operational practice will require a way of repairing these errors. This may end up being very similar to repairing other faults that can partition a network.
障害は、少なくとも2つの方法で運用慣行と相互作用します。まず、セキュリティソリューションは障害を引き起こす可能性があります。たとえば、証明書がPKIで期限切れになると、以前の隣接関係が形成されなくなる可能性があります。運用の実践では、これらのエラーを修復する方法が必要になります。これは、ネットワークを分割する可能性のある他の障害の修復と非常によく似たものになる可能性があります。
Notifications will play a critical role in avoiding security faults. Implementations SHOULD use appropriate mechanisms to notify operators as security resources are about to expire. Notifications can include messages to consoles, logged events, Simple Network Management Protocol (SNMP) traps, or notifications within a routing protocol. One strategy is to have increasing escalations of notifications.
通知は、セキュリティ障害を回避する上で重要な役割を果たします。実装では、セキュリティリソースの有効期限が近づくと、適切なメカニズムを使用してオペレーターに通知する必要があります（SHOULD）。通知には、コンソールへのメッセージ、ログに記録されたイベント、簡易ネットワーク管理プロトコル（SNMP）トラップ、またはルーティングプロトコル内の通知を含めることができます。 1つの戦略は、通知のエスカレーションを増やすことです。
Monitoring will also play an important role in avoiding security faults such as certificate expiration. Some classes of security fault, including issues with certificates, will affect only key management protocols. Other security faults can affect routing protocols directly. However, the protocols MUST still have adequate operational mechanisms to recover from these situations. Also, some faults, such as those resulting from a compromise or actual attack on a facility, are inherent and may not be prevented.
監視は、証明書の期限切れなどのセキュリティ障害を回避する上でも重要な役割を果たします。証明書の問題を含む、一部のクラスのセキュリティ障害は、鍵管理プロトコルにのみ影響します。その他のセキュリティ障害は、ルーティングプロトコルに直接影響を与える可能性があります。ただし、これらのプロトコルは、これらの状況から回復するための適切な操作メカニズムを備えている必要があります。また、妥協や施設への実際の攻撃に起因する障害など、いくつかの障害は固有のものであり、防止できない場合があります。
A second class of faults is equipment faults that impact security. For example, if keys are stored on a router and never exported from that device, failure of a router implies a need to update security provisioning on the replacement router and its peers.
障害の2番目のクラスは、セキュリティに影響を与える機器の障害です。たとえば、キーがルーターに格納されていて、そのデバイスからエクスポートされていない場合、ルーターの障害は、交換用ルーターとそのピアのセキュリティプロビジョニングを更新する必要があることを意味します。
One approach, recommended by work on securing BGP [KEYING] is to maintain the router's keying material so that when a router is replaced the same keys can be used. Router keys can be maintained on a central server. These approaches permit the credentials of a router to be recovered. This provides valuable options in case of hardware fault. The failing router can be recovered without changing credentials on other routers or waiting for keys to be certified. One disadvantage of this approach is that even if public-key cryptography is used, the private keys are located on more than just the router. A system in which keys were generated on a router and never exported from that router would typically make it more difficult for an attacker to obtain the keys. For most environments, the ability to quickly replace a router justifies maintaining keys centrally.
BGP [KEYING]の保護に関する作業で推奨される1つのアプローチは、ルーターのキー情報を維持して、ルーターを交換したときに同じキーを使用できるようにすることです。ルーターのキーは中央サーバーで管理できます。これらのアプローチにより、ルーターの資格情報を回復できます。これは、ハードウェア障害の場合に貴重なオプションを提供します。障害のあるルーターは、他のルーターの資格情報を変更したり、キーが認証されるのを待ったりせずに回復できます。このアプローチの1つの欠点は、公開鍵暗号化が使用されている場合でも、秘密鍵がルーターだけではない場所に配置されることです。キーがルーターで生成され、そのルーターからエクスポートされなかったシステムでは、通常、攻撃者がキーを取得することがより困難になります。ほとんどの環境では、ルーターをすばやく交換できるため、キーを一元的に維持することが正当化されます。
More generally, keying is another item of configuration that needs to be restored to reestablish service when equipment fails. Operators typically perform the minimal configuration necessary to get a router back in contact with the management server. The same would apply for keys. Operators who do not maintain copies of key material for performing key recovery on routers would need to perform a bit more work to regain contact with the management server. It seems reasonable to assume that management servers will be able to cause keys to be generated or distributed sufficiently to fully restore service.
より一般的には、キーイングは、機器に障害が発生したときにサービスを再確立するために復元する必要がある別の設定項目です。オペレーターは通常、ルーターを管理サーバーに接続するために必要な最小限の構成を実行します。同じことがキーにも当てはまります。ルーターでキーリカバリを実行するためのキーマテリアルのコピーを保持していないオペレーターは、管理サーバーとの接続を回復するためにもう少し作業を行う必要があります。管理サーバーは、サービスを完全に復元するのに十分なキーを生成または配布できると想定するのは理にかなっているようです。
It needs to be possible to deploy automated key management in an organization without either having to disable existing security or disrupting routing. As a result, it needs to be possible to perform a phased upgrade from manual keying to automated key management. This upgrade procedure needs to be easy and have a very low risk of disrupting routing. Today, many operators do not update keys because the perceived risk of an attack is lower than the cost of an update combined with the potential cost of routing disruptions during the update. Even when a routing protocol has technical mechanisms that permit an update with no disruption in service, there is still a potential cost of service disruptions as operational procedures and practices need to correctly use the technical mechanisms.
既存のセキュリティを無効にしたり、ルーティングを中断したりすることなく、自動化されたキー管理を組織に展開できる必要があります。その結果、手動キーイングから自動キー管理への段階的なアップグレードを実行できるようにする必要があります。このアップグレード手順は簡単で、ルーティングを中断するリスクが非常に低い必要があります。今日、攻撃の知覚されるリスクは更新のコストと更新中のルーティング中断の潜在的なコストを組み合わせたものよりも低いため、多くのオペレーターはキーを更新しません。ルーティングプロトコルに、サービスを中断することなく更新を許可する技術的なメカニズムがある場合でも、運用手順と実践では技術的なメカニズムを正しく使用する必要があるため、サービスが中断する可能性があります。
For peer-to-peer protocols such as BGP, upgrading to automated key management can be relatively easy. First, code that supports automated key management needs to be loaded on both peers. Then, the adjacency can be upgraded. The configuration can be updated to switch to automated key management when the second router reboots. Alternatively, if the key management protocols involved can detect that both peers now support automated key management, then a key can potentially be negotiated for an existing session.
BGPなどのピアツーピアプロトコルの場合、自動キー管理へのアップグレードは比較的簡単です。まず、自動キー管理をサポートするコードを両方のピアにロードする必要があります。その後、隣接関係をアップグレードできます。 2番目のルーターが再起動したときに、構成を更新して自動キー管理に切り替えることができます。または、関係するキー管理プロトコルが両方のピアが自動キー管理をサポートするようになったことを検出できる場合、既存のセッションでキーがネゴシエートされる可能性があります。
The situation is more complex for organizations that have not upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option [RFC5925]. Today, routers typically need to understand whether a given peer supports TCP MD5 or TCP-AO before opening a TCP connection. In addition, many implementations support grouping configuration (including security configuration) of related peers together. Implementations make it challenging to move from TCP MD5 to TCP-AO before all peers in the group are ready. Operators perceive it as high risk to update the configuration of a large number of peers. One particularly risky situation is upgrading the configuration of Internal BGP (iBGP) peers.
TCP MD5 [RFC2385]からTCP認証オプション[RFC5925]にアップグレードしていない組織の場合、状況はより複雑になります。今日、ルーターは通常、TCP接続を開く前に、特定のピアがTCP MD5またはTCP-AOをサポートしているかどうかを理解する必要があります。さらに、多くの実装では、関連するピアのグループ化構成（セキュリティ構成を含む）を一緒にサポートしています。実装により、グループ内のすべてのピアの準備が整う前に、TCP MD5からTCP-AOに移行することが困難になります。オペレーターは、多数のピアの構成を更新することを高いリスクとして認識しています。特に危険な状況の1つは、内部BGP（iBGP）ピアの構成をアップグレードすることです。
The situation is more complicated for multicast protocols. It's typically not desirable to bring down an entire link to reconfigure it as using automated key management. Two approaches should be considered. One is to support key table rows that enable the automated key management and manually configured keying for the same link at the same time. Coordinating this may be challenging from an operational standpoint. Another possibility is for the automated key management protocol to actually select the same traffic key that is being used manually. This could be accomplished by having an option in the key management protocol to export the current manual group key through the automated key management protocol. Then after all nodes are configured with automated key management, manual key entries can be removed. The next re-key after all nodes have manual entries removed will generate a new fresh key. Group key management protocols are RECOMMENDED to support an option to export existing manual keys during initial deployment of automated key management.
マルチキャストプロトコルの場合、状況はより複雑になります。通常、リンク全体を停止して、自動キー管理を使用するようにリンクを再構成することは望ましくありません。 2つのアプローチを検討する必要があります。 1つは、自動リンクされたキー管理と、手動で構成された同じリンクのキーイングを同時に有効にするキーテーブル行をサポートすることです。これを調整することは、運用の観点から困難な場合があります。別の可能性は、自動鍵管理プロトコルが実際に手動で使用されているのと同じトラフィック鍵を選択することです。これは、自動キー管理プロトコルを介して現在の手動グループキーをエクスポートするオプションをキー管理プロトコルに含めることで実現できます。次に、すべてのノードが自動キー管理で構成された後、手動キーエントリを削除できます。すべてのノードで手動エントリが削除された後の次の再キーは、新しい新しいキーを生成します。グループキー管理プロトコルは、自動キー管理の初期展開中に既存の手動キーをエクスポートするオプションをサポートするために推奨されています。
This document does not define a protocol. It does discuss the operational and management implications of several security technologies.
このドキュメントではプロトコルを定義していません。いくつかのセキュリティテクノロジーの運用と管理の影響について説明します。
Close synchronization of time can impact the security of routing protocols in a number of ways. Time is used to control when keys MAY begin being used and when they MUST NOT be used any longer as described in [RFC7210]. Routers need to have tight enough time synchronization that receivers permit a key to be utilized for validation prior to the first use of that key for generation of integrity-protected messages; otherwise, availability will be impacted. If time synchronization is too loose, then a key can be used beyond its intended lifetime. The Network Time Protocol (NTP) can be used to provide time synchronization. For some protocols, time synchronization is also important for replay detection.
時間の厳密な同期は、ルーティングプロトコルのセキュリティにさまざまな方法で影響を与える可能性があります。 [RFC7210]で説明されているように、キーはいつ使用されてもよいか、いつ使用されてはならないかを制御するために時間が使用されます。完全性で保護されたメッセージを生成するためにキーを最初に使用する前に、受信者がキーを検証に利用できるように、ルーターは十分にタイトな時間同期をとる必要があります。そうしないと、可用性が影響を受けます。時間の同期が緩すぎる場合、キーはその意図された有効期間を超えて使用できます。 Network Time Protocol（NTP）を使用して、時刻を同期させることができます。一部のプロトコルでは、時間同期もリプレイ検出にとって重要です。
Funding for Sam Hartman's work on this memo is provided by Huawei.
このメモに関するSam Hartmanの作業に対する資金は、Huaweiによって提供されています。
The authors would like to thank Bill Atwood, Randy Bush, Wes George, Gregory Lebovitz, and Russ White for valuable reviews.
著者は、貴重なレビューをしてくれたBill Atwood、Randy Bush、Wes George、Gregory Lebovitz、およびRuss Whiteに感謝します。
[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月。
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, April 2014.
[RFC7210] Housley、R.、Polk、T.、Hartman、S。、およびD. Zhang、「長寿命の対称暗号鍵のデータベース」、RFC 7210、2014年4月。
[KEYING] Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", Work in Progress, May 2014.
[キーイング]ターナーS.、パテルK.、R。ブッシュ、「BGPsecのルーターキーイング」、2014年5月、作業中。
[OSPF-AUTO] Liu, Y., "OSPFv3 Automated Group Keying Requirements", Work in Progress, July 2007.
[OSPF-AUTO] Liu、Y。、「OSPFv3 Automated Group Keying Requirements」、Work in Progress、2007年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox、J。、「Session Description Protocol（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、2006年7月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808] Bellovin、S。、「TCP-MD5の主要な変更戦略」、RFC 4808、2007年3月。
[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月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518] Lebovitz、G。およびM. Bhatia、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドライン」、RFC 6518、2012年2月。
[RTG-AUTH] Polk, T. and R. Housley, "Routing Authentication Using A Database of Long-Lived Cryptographic Keys", Work in Progress, November 2010.
[RTG-AUTH] Polk、T。およびR. Housley、「長命の暗号鍵のデータベースを使用したルーティング認証」、2010年11月、作業中。
Authors' Addresses
著者のアドレス
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Dacheng Zhang Huawei Technologies Co. Ltd.
DAはテクノロジー株式会社としてZhang hu Aになります。
EMail: zhangdacheng@huawei.com