[要約] RFC 8635は、BGPsecのためのルーターキーイングに関する仕様であり、BGPセッションのセキュリティを向上させるために使用されます。このRFCの目的は、BGPsecの実装におけるルーターキーイングの手順と要件を定義することです。
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 8635 IIJ Lab & Arrcus
Category: Standards Track S. Turner
ISSN: 2070-1721 sn3rd
K. Patel
Arrcus, Inc.
August 2019
Router Keying for BGPsec
BGPsecのルーターキーイング
Abstract
概要
BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.
BGPsecを話すルーターには、BGPsecアナウンスに署名するための秘密鍵がプロビジョニングされています。対応する公開鍵は、グローバルリソース公開鍵インフラストラクチャ（RPKI）で公開され、BGPsecメッセージの検証を可能にします。このドキュメントでは、公開鍵と秘密鍵のペアを生成する2つの方法について説明します。ルーター駆動型とオペレーター駆動型です。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8635.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8635で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Management/Router Communication . . . . . . . . . . . . . . . 3
4. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
5. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Router-Driven Keys . . . . . . . . . . . . . . . . . . . 5
6.2. Operator-Driven Keys . . . . . . . . . . . . . . . . . . 6
6.2.1. Using PKCS#8 to Transfer Private Keys . . . . . . . . 6
7. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
8. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
9. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
10. Key Management . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Key Rollover . . . . . . . . . . . . . . . . . . . . . . 10
10.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . 11
10.4. Router Replacement . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Management/Router Channel Security . . . . . . . . . 17
Appendix B. An Introduction to BGPsec Key Management . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
BGPsec-speaking routers are provisioned with private keys, which allow them to digitally sign BGPsec announcements. To verify the signature, the public key, in the form of a certificate [RFC8209], is published in the Resource Public Key Infrastructure (RPKI). This document describes provisioning of BGPsec-speaking routers with the appropriate public-private key pairs. There are two methods: router-driven and operator-driven.
BGPsecを話すルーターには秘密鍵がプロビジョニングされているため、BGPsecアナウンスにデジタル署名できます。署名を検証するために、証明書[RFC8209]の形式の公開鍵がResource Public Key Infrastructure（RPKI）で公開されます。このドキュメントでは、適切な公開鍵と秘密鍵のペアを使用したBGPsec対応ルーターのプロビジョニングについて説明します。ルーター主導型とオペレーター主導型の2つの方法があります。
These two methods differ in where the keys are generated: on the router in the router-driven method, and elsewhere in the operator-driven method.
これらの2つの方法は、キーが生成される場所が異なります。ルーター主導方式のルーター上と、オペレーター主導方式の別の場所です。
The two methods also differ in who generates the private/public key pair: the operator generates the pair and sends it to the router in the operator-driven method, and the router generates its own pair in the router-driven method.
2つの方法は、秘密鍵と公開鍵のペアを誰が生成するかも異なります。オペレーターがペアを生成してオペレーター主導の方法でルーターに送信し、ルーターがルーター主導の方法で独自のペアを生成します。
The router-driven method mirrors the model used by traditional PKI subscribers; the private key never leaves trusted storage (e.g., Hardware Security Module (HSM)). This is by design and supports classic PKI Certification Policies for (often human) subscribers that require the private key only ever be controlled by the subscriber to ensure that no one can impersonate the subscriber. For non-humans, this method does not always work. The operator-driven method is motivated by the extreme importance placed on ensuring the continued operation of the network. In some deployments, the same private key needs to be installed in the soon-to-be online router that was used by the soon-to-be offline router, since this "hot-swapping" behavior can result in minimal downtime, especially compared with the normal RPKI procedures to propagate a new key, which can take a day or longer to converge.
ルーター主導の方法は、従来のPKI加入者が使用していたモデルを反映しています。秘密鍵が信頼できるストレージ（ハードウェアセキュリティモジュール（HSM）など）から出ることはありません。これは設計によるものであり、秘密鍵をサブスクライバーのみが制御して、だれもサブスクライバーになりすますことができないようにする（多くの場合は人間の）サブスクライバーのクラシックPKI証明書ポリシーをサポートします。人間以外の場合、この方法は常に機能するとは限りません。オペレーター主導の方法は、ネットワークの継続的な運用を確保することを非常に重視することによって動機付けられています。一部の展開では、この「ホットスワップ」動作により、特に比較するとダウンタイムが最小になるため、同じプライベートキーを、間もなくオフラインになるルーターで使用される間もなくオンラインになるルーターにインストールする必要があります。通常のRPKIプロシージャを使用して新しいキーを伝達します。収束には1日以上かかる場合があります。
For example, when an operator wants to support hot-swappable routers, the same private key needs to be installed in the soon-to-be online router that was used by the soon-to-be offline router. This motivated the operator-driven method.
たとえば、オペレーターがホットスワップ可能なルーターをサポートしたい場合、同じプライベートキーを、間もなくオフラインになるルーターで使用されていた、間もなくオンラインになるルーターにインストールする必要があります。これは、オペレーター主導の方法に動機を与えました。
Sections 3 through 8 describe the various steps involved for an operator to use the two methods to provision new and existing routers. The methods described involve the operator configuring the two endpoints (i.e., the management station and the router) and acting as the intermediary. Section 9 describes another method that requires more-capable routers.
セクション3から8では、オペレーターが2つの方法を使用して新規および既存のルーターをプロビジョニングするためのさまざまな手順について説明します。説明されている方法は、2つのエンドポイント（つまり、管理ステーションとルーター）を構成し、仲介者として機能するオペレーターを含みます。セクション9では、より多くの機能を持つルーターを必要とする別の方法について説明します。
Useful References: [RFC8205] describes the details of BGPsec, [RFC8209] specifies the format for the PKCS#10 certification request, and [RFC8608] specifies the algorithms used to generate the PKCS#10 signature.
参考資料：[RFC8205]はBGPsecの詳細を説明し、[RFC8209]はPKCS＃10認証要求の形式を指定し、[RFC8608]はPKCS＃10署名の生成に使用されるアルゴリズムを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Operators are free to use either the router-driven or the operator-driven method as supported by the platform. Prudent security practice recommends router-generated keying, if the delay in replacing a router (or router engine) is acceptable to the operator. Regardless of the method chosen, operators first establish a protected channel between the management system and the router; this protected channel prevents eavesdropping, tampering, and message forgery. It also provides mutual authentication. How this protected channel is established is router-specific and is beyond scope of this document. Though other configuration mechanisms might be used, e.g., the Network Configuration Protocol (NETCONF) (see [RFC6470]), the protected channel used between the management platform and the router is assumed to be an SSH-protected CLI. See Appendix A for security considerations for this protected channel.
オペレーターは、プラットフォームでサポートされているルーター駆動方式またはオペレーター駆動方式のいずれかを自由に使用できます。ルーター（またはルーターエンジン）の交換の遅延がオペレーターに受け入れられる場合は、ルーターで生成されたキーを使用することをお勧めします。選択した方法に関係なく、オペレーターはまず管理システムとルーターの間に保護されたチャネルを確立します。この保護されたチャネルは、盗聴、改ざん、およびメッセージの偽造を防ぎます。また、相互認証も提供します。この保護されたチャネルが確立される方法はルーター固有であり、このドキュメントの範囲外です。ネットワーク構成プロトコル（NETCONF）（[RFC6470]を参照）などの他の構成メカニズムが使用される場合がありますが、管理プラットフォームとルーター間で使用される保護されたチャネルは、SSHで保護されたCLIであると想定されます。この保護されたチャネルのセキュリティに関する考慮事項については、付録Aを参照してください。
The previous paragraph assumes the management-system-to-router communications are over a network. When the management system has a direct physical connection to the router, e.g., via the craft port, there is no assumption that there is a protected channel between the two.
前の段落では、管理システムとルーター間の通信がネットワークを介して行われることを前提としています。管理システムがルーターに直接、たとえばクラフトポートを介して物理的に接続している場合、2つの間に保護されたチャネルがあるとの仮定はありません。
To be clear, for both of these methods, an initial leap of faith is required because the router has no keying material that it can use to protect communications with anyone or anything. Because of this initial leap of faith, a direct physical connection is safer than a network connection because there is less chance of a monkey in the middle. Once keying material is established on the router, the communications channel must prevent eavesdropping, tampering, and message forgery. This initial leap of faith will no longer be required once routers are delivered to operators with operator-trusted keying material.
明確にするために、これらの方法のどちらでも、ルータには誰とでも何とでも通信を保護するために使用できるキー情報がないため、最初の信念の飛躍が必要です。この最初の信仰の飛躍のために、直接の物理的な接続は、ネットワーク接続よりも安全です。これは、途中で猿がいる可能性が少ないためです。ルーターでキー情報が確立されると、通信チャネルは盗聴、改ざん、およびメッセージの偽造を防止する必要があります。オペレーターが信頼するキー情報を使用してルーターがオペレーターに配信されると、この最初の信念の飛躍は不要になります。
A number of options exist for the operator's management station to exchange PKI-related information with routers and with the RPKI including:
オペレーターの管理ステーションには、ルーターやRPKIとPKI関連の情報を交換するためのオプションがいくつかあります。
o Using application/pkcs10 media type [RFC5967] to extract certificate requests and application/pkcs7-mime [RFC8551] to return the issued certificate,
o application / pkcs10メディアタイプ[RFC5967]を使用して証明書要求を抽出し、application / pkcs7-mime [RFC8551]を使用して発行された証明書を返す。
o Using FTP or HTTP per [RFC2585], and
o [RFC2585]によるFTPまたはHTTPの使用、および
o Using the Enrollment over Secure Transport (EST) protocol per [RFC7030].
o [RFC7030]に従って、Enrollment over Secure Transport（EST）プロトコルを使用します。
Despite the fact that certificates are integrity-protected and do not necessarily need additional protection, transports that also provide integrity protection are RECOMMENDED.
証明書は整合性保護されており、必ずしも追加の保護を必要としないという事実にもかかわらず、整合性保護も提供するトランスポートが推奨されます。
To start, the operator uses the protected channel to install the appropriate RPKI Trust Anchor's Certificate (TA Certificate) in the router. This will later enable the router to validate the router certificate returned in the PKCS#7 certs-only message [RFC8551].
まず、オペレーターは保護されたチャネルを使用して、適切なRPKIトラストアンカーの証明書（TA証明書）をルーターにインストールします。これにより、後でルーターがPKCS＃7証明書のみのメッセージ[RFC8551]で返されたルーター証明書を検証できるようになります。
The operator configures the Autonomous System (AS) number to be used in the generated router certificate. This may be the sole AS configured on the router or an operator choice if the router is configured with multiple ASes. A router with multiple ASes can generate multiple router certificates by following the process described in this document for each desired certificate. This configured AS number is also used during verification of keys, if generated by the operator (see Section 6.2), as well as during certificate verification steps (see Sections 7, 8, and 9).
オペレーターは、生成されたルーター証明書で使用される自律システム（AS）番号を構成します。これは、ルーター上で構成されている唯一のASか、ルーターが複数のASで構成されている場合はオペレーターの選択です。複数のASを持つルータは、このドキュメントで説明されているプロセスに従って、目的の証明書ごとに複数のルータ証明書を生成できます。この構成されたAS番号は、オペレーターによって生成された場合（セクション6.2を参照）の鍵の検証中、および証明書検証ステップ（セクション7、8、および9を参照）中にも使用されます。
The operator configures or extracts from the router the BGP Identifier [RFC6286] to be used in the generated router certificate. In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used.
オペレーターは、生成されたルーター証明書で使用されるBGP ID [RFC6286]をルーターから構成または抽出します。オペレーターがルーターごとの一意の証明書を使用しないことを選択した場合、0のBGP IDを使用できます。
The operator configures the router's access control mechanism to ensure that only authorized users are able to later access the router's configuration.
オペレーターはルーターのアクセス制御メカニズムを構成して、許可されたユーザーのみが後でルーターの構成にアクセスできるようにします。
The private key, and hence the PKCS#10 certification request, which is sometimes referred to as a Certificate Signing Request (CSR), may be generated by the router or by the operator.
秘密鍵、つまり証明書署名要求（CSR）と呼ばれることもあるPKCS＃10証明書要求は、ルーターまたはオペレーターによって生成される場合があります。
Retaining the CSR allows for verifying that the returned public key in the certificate corresponds to the private key used to generate the signature on the CSR.
CSRを保持することにより、証明書で返された公開鍵がCSRの署名の生成に使用された秘密鍵に対応していることを確認できます。
NOTE: The PKCS#10 certification request does not include the AS number or the BGP Identifier for the router certificate. Therefore, the operator transmits the AS it has chosen on the router as well as the BGP Identifier when it sends the CSR to the CA.
注：PKCS＃10認証要求には、ルーター証明書のAS番号またはBGP識別子は含まれません。したがって、オペレータは、CSRをCAに送信するときに、ルータで選択したASとBGP IDを送信します。
In the router-driven method, once the protected channel is established and the initial setup (Section 5) performed, the operator issues a command or commands for the router to generate the public-private key pair, to generate the PKCS#10 certification request, and to sign the PKCS#10 certification request with the private key. Once the router has generated the PKCS#10 certification request, it returns it to the operator over the protected channel.
ルーター主導の方法では、保護されたチャネルが確立され、初期設定（セクション5）が実行されると、オペレーターがルーターにコマンドを発行して、公開鍵と秘密鍵のペアを生成し、PKCS＃10認証要求を生成します。 、および秘密鍵を使用してPKCS＃10認証要求に署名します。ルーターは、PKCS＃10認証要求を生成すると、保護されたチャネルを介してオペレーターに返します。
The operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA.
オペレーターは、CSRをCAに送信するときに、選択したAS番号とBGP IDを含めます。
Even if the operator cannot extract the private key from the router, this signature still provides a link between a private key and a router. That is, the operator can verify the proof of possession (POP), as required by [RFC6484].
オペレーターがルーターから秘密鍵を抽出できない場合でも、この署名は秘密鍵とルーター間のリンクを提供します。つまり、オペレーターは、[RFC6484]で要求されているように、所有証明（POP）を検証できます。
NOTE: The CA needs to know that the router-driven CSR is authorized. The easiest way to accomplish this is for the operator to mediate the communication with the CA. Other workflows are possible, e.g., where the router sends the CSR to the CA but the operator logs in to the CA independently and is presented with a list of pending requests to approve. See Section 9 for an additional workflow.
注：CAは、ルーター主導のCSRが承認されていることを認識する必要があります。これを行う最も簡単な方法は、オペレーターがCAとの通信を仲介することです。他のワークフローも可能です。たとえば、ルーターがCSRをCAに送信しますが、オペレーターはCAに個別にログインし、承認待ちの要求のリストが提示されます。追加のワークフローについては、セクション9を参照してください。
If a router was to communicate directly with a CA to have the CA certify the PKCS#10 certification request, there would be no way for the CA to authenticate the router. As the operator knows the authenticity of the router, the operator mediates the communication with the CA.
ルーターがCAと直接通信してCAにPKCS＃10証明書要求を認証させる場合、CAがルーターを認証する方法はありません。オペレーターはルーターの信頼性を知っているので、CAとの通信を仲介します。
In the operator-driven method, the operator generates the public-private key pair on a management station and installs the private key into the router over the protected channel. Beware that experience has shown that copy-and-paste from a management station to a router can be unreliable for long texts.
オペレーター主導の方法では、オペレーターは管理ステーションで公開鍵と秘密鍵のペアを生成し、保護されたチャネルを介してルーターに秘密鍵をインストールします。管理ステーションからルーターへのコピーアンドペーストは長いテキストでは信頼できない可能性があることが経験からわかっていることに注意してください。
The operator then creates and signs the PKCS#10 certification request with the private key; the operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA.
次に、オペレーターは、秘密鍵を使用してPKCS＃10認証要求を作成して署名します。オペレーターは、CSRをCAに送信するときに、選択したAS番号とBGP IDを含めます。
A private key can be encapsulated in a PKCS#8 Asymmetric Key Package [RFC5958] and SHOULD be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652] and signed with the operator's End Entity (EE) private key.
秘密鍵はPKCS＃8非対称鍵パッケージ[RFC5958]にカプセル化でき、さらに暗号化メッセージ構文（CMS）SignedData [RFC5652]にカプセル化して、オペレーターのエンドエンティティ（EE）秘密鍵で署名する必要があります。
The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key did in fact come from the operator, but this requires that the operator also provision via the CLI or include in the SignedData the RPKI CA certificate and relevant operators' EE certificate(s). The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope.
ルーターはカプセル化されたPKCS＃8の署名を検証して、返された秘密鍵が実際にオペレーターからのものであることを確認する必要がありますが、これにはオペレーターがCLIを介してプロビジョニングするか、SignedDataにRPKI CA証明書と関連オペレーターを含める必要がありますEE証明書。ルーターは、署名がトラストアンカーに対して有効かどうかをオペレーターに通知する必要があります（SHOULD）。この通知メカニズムは範囲外です。
The operator uses RPKI management tools to communicate with the Global RPKI system to have the appropriate CA validate the PKCS#10 certification request, sign the key in the PKCS#10 (i.e., certify it), generate a PKCS#7 certs-only message, and publish the certificate in the Global RPKI. External network connectivity may be needed if the certificate is to be published in the Global RPKI.
オペレーターは、RPKI管理ツールを使用してグローバルRPKIシステムと通信し、適切なCAがPKCS＃10証明書要求を検証し、PKCS＃10のキーに署名（つまり、それを証明）し、PKCS＃7証明書のみのメッセージを生成します。 、証明書をグローバルRPKIで公開します。証明書をグローバルRPKIで公開する場合は、外部ネットワーク接続が必要になる場合があります。
After the CA certifies the key, it does two things:
CAはキーを認証した後、次の2つのことを行います。
1. Publishes the certificate in the Global RPKI. The CA must have connectivity to the relevant publication point, which, in turn, must have external network connectivity as it is part of the Global RPKI.
1. 証明書をグローバルRPKIで公開します。 CAは関連する公開ポイントへの接続が必要です。また、グローバルRPKIの一部であるため、外部のネットワーク接続が必要です。
2. Returns the certificate to the operator's management station, packaged in a PKCS#7 certs-only message, using the corresponding method by which it received the certificate request. It SHOULD include the certificate chain below the TA Certificate so that the router can validate the router certificate.
2. 証明書要求を受信した対応するメソッドを使用して、PKCS＃7証明書のみのメッセージにパッケージ化された、オペレーターの管理ステーションに証明書を返します。ルータがルータ証明書を検証できるように、TA証明書の下に証明書チェーンを含める必要があります。
In the operator-driven method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key the operator holds corresponds to the returned public key in the PKCS#7 certs-only message. If the operator saved the PKCS#10, it can check this correspondence by comparing the public key in the CSR to the public key in the returned certificate. If the operator has not saved the PKCS#10, it can check this correspondence by regenerating the public key from the private key and then verifying that the regenerated public key matches the public key returned in the certificate.
オペレーター主導の方法では、オペレーターはPKCS＃7証明書のみのメッセージから証明書を抽出し、オペレーターが保持している公開鍵がPKCS＃7証明書のみのメッセージで返された公開鍵に対応していることを確認する必要があります。オペレーターがPKCS＃10を保存した場合、CSRの公開鍵と返された証明書の公開鍵を比較することで、この対応を確認できます。オペレーターがPKCS＃10を保存していない場合は、秘密鍵から公開鍵を再生成し、再生成された公開鍵が証明書で返された公開鍵と一致することを確認することで、この対応を確認できます。
In the operator-driven method, the operator has already installed the private key in the router (see Section 6.2).
オペレーター主導の方法では、オペレーターはすでにルーターに秘密鍵をインストールしています（セクション6.2を参照）。
The operator provisions the PKCS#7 certs-only message into the router over the protected channel.
オペレーターは、保護されたチャネルを介してPKCS＃7証明書のみのメッセージをルーターにプロビジョニングします。
The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. If the router stored the PKCS#10, it can check this correspondence by comparing the public key in the CSR to the public key in the returned certificate. If the router did not store the PKCS#10, it can check this correspondence by generating a signature on any data and then verifying the signature using the returned certificate. The router SHOULD inform the operator whether it successfully received the certificate and whether or not the keys correspond; the mechanism is out of scope.
ルータは、PKCS＃7証明書のみのメッセージから証明書を抽出して、公開鍵が保存されている秘密鍵に対応していることを確認する必要があります（SHOULD）。ルータがPKCS＃10を保存している場合、CSRの公開鍵と返された証明書の公開鍵を比較することで、この対応を確認できます。ルータがPKCS＃10を保存しなかった場合、データに署名を生成し、返された証明書を使用して署名を検証することで、この対応を確認できます。ルーターは、証明書を正常に受信したかどうか、およびキーが対応しているかどうかをオペレーターに通知する必要があります（SHOULD）。メカニズムは範囲外です。
The router SHOULD also verify that the returned certificate validates back to the installed TA Certificate, i.e., the entire chain from the installed TA Certificate through subordinate CAs to the BGPsec certificate validate. To perform this verification, the CA certificate chain needs to be returned along with the router's certificate in the PKCS#7 certs-only message. The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope.
ルーターはまた、返された証明書がインストールされたTA証明書に検証されることを確認する必要があります。この検証を実行するには、PKCS＃7証明書のみのメッセージでCA証明書チェーンをルーターの証明書と共に返す必要があります。ルーターは、署名がトラストアンカーに対して有効かどうかをオペレーターに通知する必要があります（SHOULD）。この通知メカニズムは範囲外です。
NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8 permits more-advanced configurations where the entity that generates the keys is not the direct CA.
注：PKCS＃8と証明書の署名は、同じエンティティで作成する必要はありません。 PKCS＃8に署名すると、キーを生成するエンティティが直接のCAではない、より高度な構成が可能になります。
More PKI-capable routers can take advantage of increased functionality and lighten the operator's burden. Typically, these routers include either preinstalled manufacturer-driven certificates (e.g., IEEE 802.1 AR [IEEE802-1AR]) or preinstalled manufacturer-driven Pre-Shared Keys (PSKs) as well as PKI-enrollment functionality and transport protocol, e.g., CMC's "Secure Transport" [RFC7030] or the original CMC transport protocols [RFC5273]. When the operator first establishes a protected channel between the management system and the router, this preinstalled key material is used to authenticate the router.
PKI対応のルーターを増やすと、機能が向上し、オペレーターの負担が軽減されます。通常、これらのルーターには、製造元主導の事前インストールされた証明書（IEEE 802.1 AR [IEEE802-1AR]など）または製造元主導の事前共有キー（PSK）のほか、PKI登録機能およびトランスポートプロトコル（CMCなど）が含まれています。 Secure Transport」[RFC7030]またはオリジナルのCMCトランスポートプロトコル[RFC5273]。オペレーターが最初に管理システムとルーターの間に保護されたチャネルを確立するとき、このプレインストールされたキーマテリアルがルーターの認証に使用されます。
The operator's burden shifts here to include:
オペレーターの負担は、次のように変化します。
1. Securely communicating the router's authentication material to the CA prior to the operator initiating the router's CSR. CAs use authentication material to determine whether the router is eligible to receive a certificate. At a minimum, authentication material includes the router's AS number and BGP Identifier as well as the router's key material, but it can also include additional information. Authentication material can be communicated to the CA (i.e., CSRs signed by this key material are issued certificates with this AS and BGP Identifier) or to the router (i.e., the operator uses the vendor-supplied management interface to include the AS number and BGP Identifier in the router-driven CSR). The CA stores this authentication material in an account entry for the router so that it can later be compared against the CSR prior to the CA issuing a certificate to the router.
1.オペレーターがルーターのCSRを開始する前に、ルーターの認証資料をCAに安全に通信します。 CAは、認証情報を使用して、ルーターが証明書を受信する資格があるかどうかを判断します。少なくとも、認証資料には、ルーターのAS番号とBGP識別子、およびルーターのキー資料が含まれますが、追加情報を含めることもできます。認証資料は、CA（つまり、この鍵資料によって署名されたCSRは、このASおよびBGP識別子を使用して証明書が発行される）またはルーター（つまり、オペレーターがベンダー提供の管理インターフェースを使用してAS番号とBGPを含める）に通信できます。ルーター主導CSRの識別子）。 CAはこの認証情報をルーターのアカウントエントリに保存し、後でCAがルーターに証明書を発行する前にCSRと比較できるようにします。
2. Enabling the router to communicate with the CA. While the router-to-CA communications are operator-initiated, the operator's management interface need not be involved in the communications path. Enabling the router-to-CA connectivity may require connections to external networks (i.e., through firewalls, NATs, etc.).
2. ルーターがCAと通信できるようにします。ルーターからCAへの通信はオペレーターが開始しますが、オペレーターの管理インターフェースは通信パスに関与する必要はありません。ルーターからCAへの接続を有効にするには、外部ネットワークへの接続が必要になる場合があります（つまり、ファイアウォール、NATなどを介して）。
3. Ensuring the cryptographic chain of custody from the manufacturer. For the preinstalled key material, the operator needs guarantees that either no one has accessed the private key or an authenticated log of those who have accessed it MUST be provided to the operator.
3. 製造元からの暗号化による保管のチェーンを保証します。プレインストールされたキーマテリアルの場合、オペレーターは、秘密キーに誰もアクセスしていないこと、またはアクセスしたユーザーの認証済みログがオペレーターに提供されていることを保証する必要があります。
Once configured, the operator can begin the process of enrolling the router. Because the router is communicating directly with the CA, there is no need for the operator to retrieve the PKCS#10 certification request from the router as in Section 6 or return the PKCS#7 certs-only message to the router as in Section 7. Note that the checks performed by the router in Section 8 (namely, extracting the certificate from the PKCS#7 certs-only message, verifying that the public key corresponds to the private key, and verifying that the returned certificate validated back to an installed trust anchor) SHOULD be performed. Likewise, the router SHOULD notify the operator if any of these fail, but this notification mechanism is out of scope.
設定が完了すると、オペレーターはルーターの登録プロセスを開始できます。ルータはCAと直接通信しているため、オペレータは、セクション6のようにルータからPKCS＃10証明書要求を取得したり、セクション7のようにPKCS＃7証明書のみのメッセージをルータに返す必要はありません。セクション8でルーターによって実行されるチェック（つまり、PKCS＃7証明書のみのメッセージから証明書を抽出し、公開鍵が秘密鍵に対応していることを確認し、返された証明書がインストールされた信頼に対して検証されたことを確認する）に注意してください。 anchor）実行する必要があります。同様に、ルーターはこれらのいずれかが失敗した場合にオペレーターに通知する必要があります（SHOULD）が、この通知メカニズムは範囲外です。
When a router is so configured, the communication with the CA SHOULD be automatically re-established by the router at future times to renew the certificate automatically when necessary (see Section 10). This further reduces the tasks required of the operator.
ルーターがそのように構成されている場合、CAとの通信は、将来ルーターが自動的に再確立して、必要に応じて証明書を自動的に更新する必要があります（セクション10を参照）。これにより、オペレーターに必要なタスクがさらに削減されます。
Key management not only includes key generation, key provisioning, certificate issuance, and certificate distribution, it also includes assurance of key validity, key rollover, and key preservation during router replacement. All of these responsibilities persist for as long as the operator wishes to operate the BGPsec-speaking router.
鍵管理には、鍵の生成、鍵のプロビジョニング、証明書の発行、証明書の配布だけでなく、鍵の有効性の保証、鍵のロールオーバー、ルーター交換時の鍵の保存も含まれます。これらの責任はすべて、事業者がBGPsec対応のルーターの操作を希望する限り続きます。
It is critical that a BGPsec-speaking router is signing with a valid private key at all times. To this end, the operator needs to ensure the router always has an unexpired certificate. That is, the key used to sign BGPsec announcements always has an associated certificate whose expiry time is after the current time.
BGPsec対応のルーターが常に有効な秘密鍵で署名していることが重要です。このために、オペレーターはルーターに常に有効期限の切れていない証明書があることを確認する必要があります。つまり、BGPsecアナウンスに署名するために使用されるキーには、現在の時刻より後の有効期限の証明書が常に関連付けられています。
Ensuring this is not terribly difficult but requires that either:
これを保証することはそれほど難しいことではありませんが、次のいずれかが必要です。
1. The router has a mechanism to notify the operator that the certificate has an impending expiration, and/or
1. ルーターには、証明書に有効期限が迫っていることをオペレーターに通知するメカニズムがあります。
2. The operator notes the expiry time of the certificate and uses a calendaring program to remind them of the expiry time, and/or
2. オペレーターは証明書の有効期限を記録し、カレンダープログラムを使用して有効期限を思い出させます。
3. The RPKI CA warns the operator of pending expiration, and/or
3. RPKI CAは、有効期限が迫っていることをオペレーターに警告します。
4. The operator uses some other kind of automated process to search for and track the expiry times of router certificates.
4. オペレーターは、他の種類の自動化プロセスを使用して、ルーター証明書の有効期限を検索および追跡します。
It is advisable that expiration warnings happen well in advance of the actual expiry time.
有効期限の警告は、実際の有効期限よりかなり前に発生することをお勧めします。
Regardless of the technique used to track router certificate expiry times, additional operators in the same organization should be notified as the expiry time approaches, thereby ensuring that the forgetfulness of one operator does not affect the entire organization.
ルーター証明書の有効期限を追跡するために使用される手法に関係なく、有効期限が近づいたときに同じ組織内の追加のオペレーターに通知する必要があります。これにより、1つのオペレーターの物忘れが組織全体に影響しないようになります。
Depending on inter-operator relationships, it may be helpful to notify a peer operator that one or more of their certificates are about to expire.
オペレーター間の関係によっては、1つ以上の証明書の有効期限が近づいていることをピアオペレーターに通知すると役立つ場合があります。
Routers that support multiple private keys also greatly increase the chance that routers can continuously speak BGPsec because the new private key and certificate can be obtained and distributed prior to expiration of the operational key. Obviously, the router needs to know when to start using the new key. Once the new key is being used, having the already-distributed certificate ensures continuous operation.
複数の秘密鍵をサポートするルーターは、操作鍵の有効期限が切れる前に新しい秘密鍵と証明書を取得して配布できるため、ルーターがBGPsecを継続的に読み込める可能性を大幅に高めます。明らかに、ルーターは新しいキーの使用をいつ開始するかを知る必要があります。新しいキーが使用されると、すでに配布されている証明書があるため、継続的な運用が保証されます。
More information on how to proceed with a key rollover is described in [RFC8634].
キーのロールオーバーを続行する方法の詳細については、[RFC8634]で説明されています。
In certain circumstances, a router's BGPsec certificate may need to be revoked. When this occurs, the operator needs to use the RPKI CA system to revoke the certificate by placing the router's BGPsec certificate on the Certificate Revocation List (CRL) as well as re-keying the router's certificate.
特定の状況では、ルーターのBGPsec証明書を取り消す必要がある場合があります。これが発生した場合、オペレーターはRPKI CAシステムを使用して、ルーターのBGPsec証明書を証明書失効リスト（CRL）に配置し、ルーターの証明書を再入力することで、証明書を取り消す必要があります。
The process of revoking an active router key consists of requesting the revocation from the CA, the CA actually revoking the router's certificate, the re-keying/renewing of the router's certificate (possibly) distributing a new key and certificate to the router, and distributing the status. During the time this process takes, the operator must decide how they wish to maintain continuity of operation (with or without the compromised private key) or whether they wish to bring the router offline to address the compromise.
アクティブなルーターキーを取り消すプロセスは、CAからの取り消しの要求、CAは実際にルーターの証明書を取り消す、ルーターの証明書の再キー付け/更新（おそらく）、新しいキーと証明書をルーターに配布すること、および配布することで構成されます。ステータス。このプロセスにかかる時間の間に、オペレーターは運用の継続性を維持する方法（侵害された秘密鍵の有無にかかわらず）、または侵害に対処するためにルーターをオフラインにするかどうかを決定する必要があります。
Keeping the router operational and BGPsec-speaking is the ideal goal; but, if operational practices do not allow this, then reconfiguring the router to disable BGPsec is likely preferred to bringing the router offline.
ルータの動作を維持し、BGPsecを使用することが理想的な目標です。ただし、運用上の慣行でこれが許可されていない場合は、ルータをオフラインにするよりも、ルータを再構成してBGPsecを無効にする方が望ましいと考えられます。
Routers that support more than one private key, where one is operational and other(s) are soon-to-be-operational, facilitate revocation events because the operator can configure the router to make a soon-to-be-operational key operational, request revocation of the compromised key, and then make a next generation soon-to-be-operational key. Hopefully, all this can be done without needing to take the router offline or reboot it. For routers that support only one operational key, the operators should create or install the new private key and then request revocation of the certificate corresponding to the compromised private key.
オペレーターがすぐに操作できるキーを操作できるようにルーターを構成できるので、1つが操作可能で他のものがすぐに操作可能になる複数の秘密キーをサポートするルーターは、失効イベントを容易にします。侵害されたキーの失効をリクエストし、すぐに動作する次世代のキーを作成します。うまくいけば、これらすべてを、ルーターをオフラインにしたり、再起動したりすることなく実行できます。 1つの操作キーのみをサポートするルーターの場合、オペレーターは新しい秘密キーを作成またはインストールしてから、侵害された秘密キーに対応する証明書の失効を要求する必要があります。
At the time of writing, routers often generate private keys for uses such as Secure Shell (SSH), and the private keys may not be seen or exported from the router. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software that accesses the router must be updated with the new keys. Also, any network-based initial contact with a new routing engine requires trust in the public key presented on first contact.
執筆時点では、ルーターはSecure Shell（SSH）などの使用のために秘密鍵を生成することが多く、秘密鍵が表示されない、またはルーターからエクスポートされない場合があります。これは優れたセキュリティですが、ルーティングエンジンまたはルーター全体を現場で交換する必要があり、ルーターにアクセスするすべてのソフトウェアを新しいキーで更新する必要がある場合、問題が生じます。また、新しいルーティングエンジンとのネットワークベースの最初の連絡には、最初の連絡時に提示された公開鍵への信頼が必要です。
To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to be inserted via a protected channel, e.g., SSH, NETCONF (see [RFC6470]), and SNMP.
オペレーターがRPKIの対応する公開鍵の更新と配布を必要とせずに迅速にルーターを交換できるようにするには、ルーターは、SSH、NETCONF（[RFC6470]を参照）、SNMPなどの保護されたチャネルを介してプライベートBGPsec鍵を挿入できるようにする必要があります（SHOULD）。 。
This lets the operator escrow the old private key via the mechanism used for operator-driven keys (see Section 6.2), such that it can be reinserted into a replacement router. The router MAY allow the private key to be exported via the protected channel after key generation, but this SHOULD be paired with functionality that sets the newly generated key into a permanent non-exportable state to ensure that it is not exported at a future time by unauthorized operations.
これにより、オペレーターは、オペレーター主導のキー（セクション6.2を参照）に使用されるメカニズムを介して古い秘密キーをエスクローできるため、交換用ルーターに再挿入できます。ルーターは、鍵の生成後、保護されたチャネルを介して秘密鍵をエクスポートできる場合がありますが、これは、新しく生成された鍵を永続的な非エクスポート状態に設定して、将来的にエクスポートされないようにする機能と組み合わせる必要があります。不正な操作。
The router's manual will describe which of the key-generation options discussed in the earlier sections of this document a router supports or if it supports both of them. The manual will also describe other important security-related information (e.g., how to SSH to the router). After becoming familiar with the capabilities of the router, an operator is encouraged to ensure that the router is patched with the latest software updates available from the manufacturer.
ルーターのマニュアルには、このドキュメントの前のセクションで説明したキー生成オプションのうち、ルーターがサポートするもの、または両方をサポートするものがあるかどうかが記載されています。マニュアルには、その他の重要なセキュリティ関連情報（ルーターへのSSH接続方法など）も記載されています。ルーターの機能に慣れた後、オペレーターはルーターが製造元から入手可能な最新のソフトウェアアップデートでパッチされていることを確認することをお勧めします。
This document defines no protocols. So, in some sense, it introduces no new security considerations. However, it relies on many other protocols, and the security considerations in the referenced documents should be consulted; notably, the documents listed in Section 1 should be consulted first. PKI-relying protocols, of which BGPsec is one, have many issues to consider -- so many, in fact, entire books have been written to address them -- so listing all PKI-related security considerations is neither useful nor helpful. Regardless, some bootstrapping-related issues that are worth repeating are listed here:
このドキュメントではプロトコルを定義していません。したがって、ある意味では、新しいセキュリティに関する考慮事項は導入されていません。ただし、他の多くのプロトコルに依存しているため、参照されているドキュメントのセキュリティに関する考慮事項を参照する必要があります。特に、セクション1にリストされているドキュメントを最初に参照する必要があります。 BGPsecが1つであるPKI依存プロトコルには、考慮すべき多くの問題があります-実際には、それらに対処するために本全体が書かれています-したがって、すべてのPKI関連のセキュリティの考慮事項を一覧表示することは、有用でもあり有用でもありません。とにかく、繰り返す価値のあるいくつかのブートストラップ関連の問題を以下に示します。
o Public-private key pair generation: Mistakes here are, for all practical purposes, catastrophic because PKIs rely on the pairing of a difficult-to-generate public-private key pair with a signer; all key pairs MUST be generated from a good source of non-deterministic random input [RFC4086].
o 公開鍵と秘密鍵のペアの生成：PKIは生成が難しい公開鍵と秘密鍵のペアと署名者のペアに依存しているため、ここでの間違いはすべての実用的な目的にとって破滅的です。すべての鍵ペアは、非決定的なランダム入力[RFC4086]の適切なソースから生成する必要があります。
o Private key protection at rest: Mistakes here are, for all, practical purposes, catastrophic because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer; all private keys MUST be protected when at rest in a secure fashion. Obviously, how each router protects private keys is implementation specific. Likewise, the local storage format for the private key is just that: a local matter.
o 保管時の秘密鍵の保護：ここでの間違いは、秘密鍵の開示により別のエンティティが署名者になりすます（つまり、偽装する）ため、実際には破滅的です。安全な方法で保管されているときは、すべての秘密鍵を保護する必要があります。明らかに、各ルーターがどのように秘密鍵を保護するかは、実装によって異なります。同様に、秘密鍵のローカルストレージ形式は、ローカルの問題です。
o Private key protection in transit: Mistakes here are, for all practical purposes, catastrophic because disclosure of the private key allows another entity to masquerade as (i.e., impersonate) the signer; therefore, transport security is strongly RECOMMENDED. The level of security provided by the transport layer's security mechanism SHOULD be at least as good as the strength of the BGPsec key; there's no point in spending time and energy to generate an excellent public-private key pair and then transmit the private key in the clear or with a known-to-be-broken algorithm, as it just undermines trust that the private key has been kept private. Additionally, operators SHOULD ensure the transport security mechanism is up to date, in order to address all known implementation bugs.
o送信中の秘密鍵の保護：ここでの間違いは、秘密鍵の開示により、別のエンティティが署名者になりすます（つまり、偽装する）ことができるため、すべての実用的な目的にとって破滅的です。したがって、トランスポートセキュリティは強く推奨されます。トランスポート層のセキュリティメカニズムによって提供されるセキュリティのレベルは、少なくともBGPsecキーの強度と同等である必要があります。秘密鍵が保持されているという信頼を損なうだけなので、優れた公開鍵と秘密鍵のペアを生成してから、平文で、または既知の解読可能なアルゴリズムで秘密鍵を送信するために時間とエネルギーを費やす意味はありません。民間。さらに、オペレーターは、すべての既知の実装バグに対処するために、トランスポートセキュリティメカニズムが最新であることを確認する必要があります。
Though the CA's certificate is installed on the router and used to verify that the returned certificate is in fact signed by the CA, the revocation status of the CA's certificate is rarely checked as the router may not have global connectivity or CRL-aware software. The operator MUST ensure that the installed CA certificate is valid.
CAの証明書はルーターにインストールされ、返された証明書が実際にCAによって署名されていることを確認するために使用されますが、ルーターがグローバル接続またはCRL対応のソフトウェアを持っていない可能性があるため、CAの証明書の失効ステータスはめったにチェックされません。オペレーターは、インストールされているCA証明書が有効であることを確認する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[IEEE802-1AR] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802.1AR, <https://standards.ieee.org/standard/802_1AR-2018.html>.
[IEEE802-1AR] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Secure Device Identity」、IEEE Std 802.1AR、<https://standards.ieee.org/standard/802_1AR-2018.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<https://www.rfc-editor.org / info / rfc4253>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、DOI 10.17487 / RFC5958、2010年8月、<https://www.rfc-editor.org/info/rfc5958>。
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC6286]チェン、E.、J。ユアン、「BGP-4の自律システム全体の一意のBGP ID」、RFC 6286、DOI 10.17487 / RFC6286、2011年6月、<https://www.rfc-editor.org / info / rfc6286>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8608, DOI 10.17487/RFC8608, June 2019, <https://www.rfc-editor.org/info/rfc8608>.
[RFC8608]ターナー、S。およびO.ボーチャート、「BGPsecアルゴリズム、キー形式、および署名形式」、RFC 8608、DOI 10.17487 / RFC8608、2019年6月、<https://www.rfc-editor.org/info/ rfc8608>。
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209]レイノルズ、M。、ターナー、S。、およびS.ケント、「BGPsecルーター証明書、証明書失効リスト、および認証要求のプロファイル」、RFC 8209、DOI 10.17487 / RFC8209、2017年9月、<https：/ /www.rfc-editor.org/info/rfc8209>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B。、およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 4.0 Message Specification」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https： //www.rfc-editor.org/info/rfc8551>。
[RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", BCP 224, RFC 8634, DOI 10.17487/RFC8634, August 2019, <https://www.rfc-editor.org/info/rfc8634>.
[RFC8634] Weis、B.、Gagliano、R。、およびK. Patel、「BGPsecルーター証明書のロールオーバー」、BCP 224、RFC 8634、DOI 10.17487 / RFC8634、2019年8月、<https：//www.rfc-editor。 org / info / rfc8634>。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/info/rfc2585>.
[RFC2585] Housley、R。およびP. Hoffman、「Internet X.509 Public Key Infrastructure Operational Protocols：FTP and HTTP」、RFC 2585、DOI 10.17487 / RFC2585、1999年5月、<https：//www.rfc-editor。 org / info / rfc2585>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <https://www.rfc-editor.org/info/rfc3766>.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、DOI 10.17487 / RFC3766、2004年4月、<https：//www.rfc-editor。 org / info / rfc3766>。
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008, <https://www.rfc-editor.org/info/rfc5273>.
[RFC5273] Schaad、J。およびM. Myers、「CMS（CMC）を介した証明書管理：トランスポートプロトコル」、RFC 5273、DOI 10.17487 / RFC5273、2008年6月、<https://www.rfc-editor.org/info / rfc5273>。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号化サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< https://www.rfc-editor.org/info/rfc5480>。
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, DOI 10.17487/RFC5647, August 2009, <https://www.rfc-editor.org/info/rfc5647>.
[RFC5647] Igoe、K。およびJ. Solinas、「Secure Shell Transport Layer ProtocolのAES Galoisカウンターモード」、RFC 5647、DOI 10.17487 / RFC5647、2009年8月、<https://www.rfc-editor.org/ info / rfc5647>。
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.
[RFC5656] Stebila、D。およびJ. Green、「Secure Shell Transport Layerにおける楕円曲線アルゴリズムの統合」、RFC 5656、DOI 10.17487 / RFC5656、2009年12月、<https://www.rfc-editor.org/info / rfc5656>。
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, <https://www.rfc-editor.org/info/rfc5967>.
[RFC5967]ターナー、S。、「The application / pkcs10 Media Type」、RFC 5967、DOI 10.17487 / RFC5967、2010年8月、<https://www.rfc-editor.org/info/rfc5967>。
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6187] Igoe、K。およびD. Stebila、「Secure Shell AuthenticationのX.509v3証明書」、RFC 6187、DOI 10.17487 / RFC6187、2011年3月、<https://www.rfc-editor.org/info/rfc6187 >。
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) Base Notifications", RFC 6470, DOI 10.17487/RFC6470, February 2012, <https://www.rfc-editor.org/info/rfc6470>.
[RFC6470] Bierman、A。、「Network Configuration Protocol（NETCONF）Base Notifications」、RFC 6470、DOI 10.17487 / RFC6470、2012年2月、<https://www.rfc-editor.org/info/rfc6470>。
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6484]ケント、S。、コング、D。、ソ、K。、およびR.ワトロ、「リソース公開鍵インフラストラクチャ（RPKI）の証明書ポリシー（CP）」、BCP 173、RFC 6484、DOI 10.17487 / RFC6484 、2012年2月、<https://www.rfc-editor.org/info/rfc6484>。
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, <https://www.rfc-editor.org/info/rfc6668>.
[RFC6668] Bider、D。およびM. Baushke、「Secure Shell（SSH）Transport Layer ProtocolのSHA-2データ整合性検証」、RFC 6668、DOI 10.17487 / RFC6668、2012年7月、<https：//www.rfc -editor.org/info/rfc6668>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin、M。、編、Yee、P。、編、およびD. Harkins、編、「Enrollment over Secure Transport」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：// www.rfc-editor.org/info/rfc7030>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205]レピンスキー、M。、エド。 K. Sriram、編、「BGPsecプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8205>。
[SP800-57] National Institute of Standards and Technology (NIST), "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.
[SP800-57]米国国立標準技術研究所（NIST）、「Recommendation for Key Management-Part 1：General」、NIST Special Publication 800-57 Revision 4、DOI 10.6028 / NIST.SP.800-57pt1r4、January、 <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。
Appendix A. Management/Router Channel Security
付録A.管理/ルーターチャネルのセキュリティ
Encryption, integrity, authentication, and key-exchange algorithms used by the protected channel should be of equal or greater strength than the BGPsec keys they protect, which for the algorithm specified in [RFC8608] is 128 bits; see [RFC5480] and [SP800-57] for information about this strength claim as well as [RFC3766] for "how to determine the length of an asymmetric key as a function of a symmetric key strength requirement". In other words, for the encryption algorithm, do not use export grade crypto (40-56 bits of security), and do not use Triple-DES (112 bits of security). Suggested minimum algorithms would be AES-128, specifically the following:
保護されたチャネルで使用される暗号化、整合性、認証、および鍵交換アルゴリズムは、それらが保護するBGPsec鍵と同等以上の強度である必要があります。これは、[RFC8608]で指定されているアルゴリズムでは128ビットです。この強度の主張に関する情報については[RFC5480]と[SP800-57]を、「対称鍵の強度要件の関数として非対称鍵の長さを決定する方法」については[RFC3766]を参照してください。つまり、暗号化アルゴリズムでは、エクスポートグレードの暗号（40〜56ビットのセキュリティ）を使用せず、Triple-DES（112ビットのセキュリティ）を使用しないでください。推奨される最小アルゴリズムはAES-128で、具体的には次のとおりです。
o aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption,
o 暗号化にはaes128-cbc [RFC4253]およびAEAD_AES_128_GCM [RFC5647]
o hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity,
o 整合性のためにhmac-sha2-256 [RFC6668]またはAESAD_AES_128_GCM [RFC5647]
o ecdsa-sha2-nistp256 [RFC5656] for authentication, and
o 認証のためのecdsa-sha2-nistp256 [RFC5656]、および
o ecdh-sha2-nistp256 [RFC5656] for key exchange.
o 鍵交換用のecdh-sha2-nistp256 [RFC5656]。
Some routers support the use of public key certificates and SSH. The certificates used for the SSH session are different than the certificates used for BGPsec. The certificates used with SSH should also enable a level of security at least as good as the security offered by the BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication.
一部のルーターは、公開鍵証明書とSSHの使用をサポートしています。 SSHセッションに使用される証明書は、BGPsecに使用される証明書とは異なります。 SSHで使用される証明書は、少なくともBGPsecキーによって提供されるセキュリティと同等のレベルのセキュリティも有効にする必要があります。 x509v3-ecdsa-sha2-nistp256 [RFC6187]を認証に使用できます。
The protected channel must provide confidentiality, authentication, and integrity and replay protection.
保護されたチャネルは、機密性、認証、整合性、および再生保護を提供する必要があります。
This appendix is informative. It attempts to explain some of the PKI jargon.
この付録は参考情報です。 PKI専門用語のいくつかを説明しようとします。
BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers. In PKI parlance, the senders are referred to as "signers", and the receivers are referred to as "relying parties". The signers with which we are concerned here are routers signing BGPsec updates. Signers use private keys to sign, and relying parties use the corresponding public keys, in the form of X.509 public key certificates, to verify signatures. The third party involved is the entity that issues the X.509 public key certificate, the Certification Authority (CA). Key management is all about making these key pairs and the certificates, as well as ensuring that the relying parties trust that the certified public keys in fact correspond to the signers' private keys.
BGPsecスピーカーは、他のBGPsecスピーカーによって検証される署名付きのBGPsec更新を送信します。 PKI用語では、送信者は「署名者」と呼ばれ、受信者は「証明書利用者」と呼ばれます。ここで関係する署名者は、BGPsecアップデートに署名するルーターです。署名者は秘密鍵を使用して署名し、証明書利用者はX.509公開鍵証明書の形式で対応する公開鍵を使用して署名を検証します。関係するサードパーティは、X.509公開鍵証明書を発行するエンティティである認証局（CA）です。キー管理は、これらのキーペアと証明書を作成することと、証明書利用者が、認証された公開キーが実際に署名者の秘密キーに対応することを信頼することを保証することです。
The specifics of key management greatly depend on the routers as well as management interfaces provided by the routers' vendor. Because of these differences, it is hard to write a definitive "how to", but this guide is intended to arm operators with enough information to ask the right questions. The other aspect that makes this guide informative is that the steps for the do-it-yourself (DIY) approach involve arcane commands while the GUI-based vendor-assisted management console approach will likely hide all of those commands behind some button clicks. Regardless, the operator will end up with a BGPsec-enabled router. Initially, we focus on the DIY approach and then follow up with some information about the GUI-based approach.
キー管理の詳細は、ルーターおよびルーターのベンダーが提供する管理インターフェイスに大きく依存します。これらの違いのため、明確な「方法」を書くことは困難ですが、このガイドは、適切な質問をするのに十分な情報をオペレーターに提供することを目的としています。このガイドを有益なものにするもう1つの側面は、日曜大工（DIY）アプローチの手順には難解なコマンドが含まれているのに対し、GUIベースのベンダー支援の管理コンソールアプローチでは、ボタンクリックの背後にこれらのコマンドがすべて非表示になる可能性があります。いずれにしても、オペレーターは最終的にBGPsec対応ルーターになります。最初はDIYアプローチに焦点を当て、次にGUIベースのアプローチに関する情報をフォローアップします。
The first step in the DIY approach is to generate a private key. However, in fact, what you do is create a key pair: one part (the private key) is kept very private, and the other part (the public key) is given out to verify whatever is signed. The two methods for how to create the key pair are the subject of this document, but it boils down to either doing it on-router (router-driven) or off-router (operator-driven).
DIYアプローチの最初のステップは、秘密鍵を生成することです。ただし、実際には、キーペアを作成します。一方の部分（秘密キー）は非常に秘密にされ、もう一方の部分（公開キー）は、署名されたものを検証するために提供されます。キーペアを作成する2つの方法は、このドキュメントの主題ですが、結局のところ、ルーター上（ルーター主導）またはルーター外（オペレーター主導）のいずれかで作成します。
If you are generating keys on the router (router-driven), then you will need to access the router. Again, how you access the router is router-specific, but generally the DIY approach involves using the CLI and accessing the router either directly via the router's craft port or over the network on an administrative interface. If accessing the router over the network, be sure to do it securely (i.e., use SSHv2). Once logged into the router, issue a command or a series of commands that will generate the key pair for the algorithms referenced in the main body of this document; consult your router's documentation for the specific commands. The key-generation process will yield one or more files containing the private key and the public key; the file format varies depending on, among other things, the arcane command the operator issued; however, the files are generally DER- or PEM-encoded.
ルーター（ルーター駆動型）でキーを生成する場合は、ルーターにアクセスする必要があります。繰り返しますが、ルーターへのアクセス方法はルーター固有ですが、一般的にDIYのアプローチでは、CLIを使用し、ルーターのクラフトポートを介して直接、または管理インターフェイス上のネットワークを介してルーターにアクセスします。ネットワーク経由でルーターにアクセスする場合は、安全にアクセスしてください（SSHv2を使用）。ルータにログインしたら、このドキュメントの本文で参照されているアルゴリズムのキーペアを生成するコマンドまたは一連のコマンドを発行します。特定のコマンドについては、ルーターのドキュメントを参照してください。鍵生成プロセスにより、秘密鍵と公開鍵を含む1つ以上のファイルが生成されます。ファイル形式は、特に、オペレーターが発行した難解なコマンドによって異なります。ただし、ファイルは通常、DERまたはPEMでエンコードされています。
The second step is to generate the certification request, which is often referred to as a Certificate Signing Request (CSR) or PKCS#10 certification request, and to send it to the CA to be signed. To generate the CSR, the operator issues some more arcane commands while logged into the router; using the private key just generated to sign the certification request with the algorithms referenced in the main body of this document; the CSR is signed to prove to the CA that the router has possession of the private key (i.e., the signature is the proof-of-possession). The output of the command is the CSR file; the file format varies depending on the arcane command you issued, but generally the files are DER- or PEM-encoded.
2番目のステップは、証明書署名要求（CSR）またはPKCS＃10証明書要求と呼ばれることが多い証明書要求を生成し、それをCAに送信して署名することです。 CSRを生成するために、オペレーターはルーターにログイン中にいくつかの難解なコマンドを発行します。このドキュメントの本文で参照されているアルゴリズムを使用して、認証要求に署名するために生成された秘密鍵を使用します。 CSRは、ルータが秘密鍵を所有していることをCAに証明するために署名されています（つまり、署名は所有証明です）。コマンドの出力はCSRファイルです。ファイル形式は、発行した難解なコマンドによって異なりますが、通常、ファイルはDERまたはPEMでエンコードされています。
The third step is to retrieve the signed CSR from the router and send it to the CA. But before sending it, you need to also send the CA the subject name (i.e., "ROUTER-" followed by the AS number) and serial number (i.e., the 32-bit BGP Identifier) for the router. The CA needs this information to issue the certificate. How you get the CSR to the CA is beyond the scope of this document. While you are still connected to the router, install the trust anchor for the root of the PKI. At this point, you no longer need access to the router for BGPsec-related initiation purposes.
3番目の手順は、署名されたCSRをルーターから取得してCAに送信することです。ただし、送信する前に、CAにルーターのサブジェクト名（「ROUTER-」の後にAS番号が続く）とシリアル番号（32ビットのBGP識別子）も送信する必要があります。 CAは、証明書を発行するためにこの情報を必要とします。 CSRをCAに取得する方法は、このドキュメントの範囲外です。引き続きルーターに接続している間に、PKIのルートにトラストアンカーをインストールします。この時点で、BGPsec関連の開始目的でルーターにアクセスする必要はありません。
The fourth step is for the CA to issue the certificate based on the CSR you sent. The certificate will include the subject name, serial number, public key, and other fields; it will also be signed by the CA. After the CA issues the certificate, the CA returns the certificate and posts the certificate to the RPKI repository. Check that the certificate corresponds to the public key contained in the certificate by verifying the signature on the CSR sent to the CA; this is just a check to make sure that the CA issued a certificate that includes a public key that is the pair of the private key (i.e., the math will work when verifying a signature generated by the private key with the returned certificate).
4番目のステップは、CAが送信したCSRに基づいて証明書を発行することです。証明書には、サブジェクト名、シリアル番号、公開鍵、およびその他のフィールドが含まれます。また、CAによって署名されます。 CAが証明書を発行した後、CAは証明書を返し、証明書をRPKIリポジトリに投稿します。 CAに送信されたCSRの署名を検証して、証明書が証明書に含まれている公開鍵に対応していることを確認します。これは、CAが秘密鍵のペアである公開鍵を含む証明書を発行したことを確認するためのチェックにすぎません（つまり、返された証明書を使用して秘密鍵によって生成された署名を検証するときに数学が機能します）。
If generating the keys off-router (operator-driven), then the same steps are used as with on-router key generation (possibly with the same arcane commands as those used in the on-router approach). However, no access to the router is needed, and the first three steps are done on an administrative workstation:
キーをルーター外で（オペレーター主導で）生成する場合、ルーター上でのキー生成と同じ手順が使用されます（ルーター上で使用されるものと同じ難解なコマンドを使用する可能性があります）。ただし、ルーターへのアクセスは必要なく、最初の3つのステップは管理ワークステーションで実行されます。
Step 1: Generate key pair. Step 2: Create CSR and sign CSR with private key. Step 3: Send CSR file with the subject name and serial number to CA.
ステップ1：キーペアを生成します。ステップ2：CSRを作成し、秘密鍵でCSRに署名します。ステップ3：サブジェクト名とシリアル番号を含むCSRファイルをCAに送信します。
After the CA has returned the certificate and you have checked the certificate, you need to put the private key and trust anchor in the router. Assuming the DIY approach, you will be using the CLI and accessing the router either directly via the router's craft port or over the network on an admin interface; if accessing the router over the network, make doubly sure it is done securely (i.e., use SSHv2) because the private key is being moved over the network. At this point, access to the router is no longer needed for BGPsec-related initiation purposes.
CAが証明書を返し、証明書を確認したら、秘密鍵とトラストアンカーをルーターに配置する必要があります。 DIYアプローチを想定すると、CLIを使用して、ルーターのクラフトポートを介して直接、または管理インターフェイス上のネットワークを介してルーターにアクセスします。ネットワークを介してルーターにアクセスする場合は、秘密鍵がネットワークを介して移動されるため、安全に（つまり、SSHv2を使用して）確実に行われるようにしてください。この時点で、ルータへのアクセスは、BGPsec関連の開始の目的では必要ありません。
NOTE: Regardless of the approach taken, the first three steps could trivially be collapsed by a vendor-provided script to yield the private key and the signed CSR.
注：取られたアプローチに関係なく、最初の3つのステップは、ベンダー提供のスクリプトによって簡単に省略でき、秘密鍵と署名済みCSRを生成します。
Given a GUI-based vendor-assisted management console, all of these steps will likely be hidden behind pointing and clicking the way through BGPsec-enabling the router.
GUIベースのベンダー支援の管理コンソールを考えると、これらの手順はすべて、BGPsec対応のルーターを経由する方法を指してクリックすることの背後に隠されている可能性があります。
The scenarios described above require the operator to access each router, which does not scale well to large networks. An alternative would be to create an image, perform the necessary steps to get the private key and trust anchor on the image, and then install the image via a management protocol.
上記のシナリオでは、オペレーターが各ルーターにアクセスする必要がありますが、大規模なネットワークには適していません。別の方法としては、イメージを作成し、必要な手順を実行して秘密キーとトラストアンカーをイメージに取得してから、管理プロトコルを介してイメージをインストールします。
One final word of advice: certificates include a notAfter field that unsurprisingly indicates when relying parties should no longer trust the certificate. To avoid having routers with expired certificates, follow the recommendations in the Certification Policy (CP) [RFC6484] and make sure to renew the certificate at least one week prior to the notAfter date. Set a calendar reminder in order not to forget!
最後に一言：証明書にはnotAfterフィールドが含まれており、これは当然、証明書利用者が証明書を信頼する必要がないことを示します。期限切れの証明書を持つルーターを使用しないようにするには、証明書ポリシー（CP）[RFC6484]の推奨に従い、notAfter日付の少なくとも1週間前に証明書を更新してください。忘れないようにカレンダーのリマインダーを設定してください！
Authors' Addresses
著者のアドレス
Randy Bush IIJ & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America
ランディブッシュIIJ＆Arrcus 5147クリスタルスプリングスベインブリッジ島、ワシントン98110アメリカ合衆国
Email: randy@psg.com
Sean Turner sn3rd
ショーンターナーsn3rd
Email: sean@sn3rd.com
Keyur Patel Arrcus, Inc.
Keur Patel Recurs、Inc.
Email: keyur@arrcus.com