draft-ietf-sidrops-rtr-keying-06.txt   rfc8635.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft IIJ Lab / Dragon Research Lab Request for Comments: 8635 IIJ Lab & Arrcus
Intended status: Best Current Practice S. Turner Category: Standards Track S. Turner
Expires: November 15, 2019 sn3rd ISSN: 2070-1721 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
May 14, 2019 August 2019
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-06
Abstract Abstract
BGPsec-speaking routers are provisioned with private keys in order to BGPsec-speaking routers are provisioned with private keys in order to
sign BGPsec announcements. The corresponding public keys are sign BGPsec announcements. The corresponding public keys are
published in the global Resource Public Key Infrastructure, enabling published in the Global Resource Public Key Infrastructure (RPKI),
verification of BGPsec messages. This document describes two methods enabling verification of BGPsec messages. This document describes
of generating the public-private key-pairs: router-driven and two methods of generating the public-private key pairs: router-driven
operator-driven. and operator-driven.
Requirements Language
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 16, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Management / Router Communication . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 3. Management/Router Communication . . . . . . . . . . . . . . . 3
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5 5. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 6. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6 6.1. Router-Driven Keys . . . . . . . . . . . . . . . . . . . 5
5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6 6.2. Operator-Driven Keys . . . . . . . . . . . . . . . . . . 6
6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7 6.2.1. Using PKCS#8 to Transfer Private Keys . . . . . . . . 6
7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7 7. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8 8. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9 10. Key Management . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . 10
9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Key Rollover . . . . . . . . . . . . . . . . . . . . . . 10
9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11 10.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10.4. Router Replacement . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Informative References . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Management/Router Channel Security . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. An Introduction to BGPsec Key Management . . . . . . 16 Appendix A. Management/Router Channel Security . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. An Introduction to BGPsec Key Management . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
BGPsec-speaking routers are provisioned with private keys, which BGPsec-speaking routers are provisioned with private keys, which
allow them to digitally sign BGPsec announcements. To verify the allow them to digitally sign BGPsec announcements. To verify the
signature, the public key, in the form of a certificate [RFC8209], is signature, the public key, in the form of a certificate [RFC8209], is
published in the Resource Public Key Infrastructure (RPKI). This published in the Resource Public Key Infrastructure (RPKI). This
document describes provisioning of BGPsec-speaking routers with the document describes provisioning of BGPsec-speaking routers with the
appropriate public-private key-pairs. There are two methods, router- appropriate public-private key pairs. There are two methods: router-
driven and operator-driven. driven and operator-driven.
These two methods differ in where the keys are generated: on the These two methods differ in where the keys are generated: on the
router in the router-driven method, and elsewhere in the router in the router-driven method, and elsewhere in the operator-
operator-driven method. driven method.
The two methods also differ in who generates the private/public key 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 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 operator-driven method, and the router generates its own pair in
the router-drive method. the router-driven method.
The router-driven method mirrors the model used by traditional PKI The router-driven method mirrors the model used by traditional PKI
subscribers; the private key never leaves trusted storage (e.g., subscribers; the private key never leaves trusted storage (e.g.,
Hardware Security Module). This is by design and supports classic Hardware Security Module (HSM)). This is by design and supports
PKI Certification Policies for (often human) subscribers which classic PKI Certification Policies for (often human) subscribers that
require the private key only ever be controlled by the subscriber to require the private key only ever be controlled by the subscriber to
ensure that no one can impersonate the subscriber. For non-humans, ensure that no one can impersonate the subscriber. For non-humans,
this method does not always work. The operator-driven model is this method does not always work. The operator-driven method is
motivated by the extreme importance placed on ensuring the continued motivated by the extreme importance placed on ensuring the continued
operation of the network. In some deployments, the same private key 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 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 by the soon-to-be offline router, since this "hot-swapping" behavior
can result in minimal downtime, especially compared with the normal can result in minimal downtime, especially compared with the normal
RPKI procedures to propagate a new key, which can take a day or RPKI procedures to propagate a new key, which can take a day or
longer to converge. longer to converge.
For example, when an operator wants to support hot-swappable routers, 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 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 router that was used by the soon-to-be offline router. This
motivated the operator-driven method. motivated the operator-driven method.
Sections 2 through 7 describe the various steps involved for an Sections 3 through 8 describe the various steps involved for an
operator to use the two methods to provision new and existing operator to use the two methods to provision new and existing
routers. The methods described involve the operator configuring the routers. The methods described involve the operator configuring the
two end points (i.e., the management station and the router) and two endpoints (i.e., the management station and the router) and
acting as the intermediary. Section 8 describes another method that acting as the intermediary. Section 9 describes another method that
requires more capable routers. requires more-capable routers.
Useful References: [RFC8205] describes details of BGPsec, [RFC8209] Useful References: [RFC8205] describes the details of BGPsec,
specifies the format for the PKCS#10 certification request, and [RFC8209] specifies the format for the PKCS#10 certification request,
[RFC8208] specifies the algorithms used to generate the PKCS#10 and [RFC8608] specifies the algorithms used to generate the PKCS#10
signature. signature.
2. Management / Router Communication 2. Requirements Language
Operators are free to use either the router-driven or 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 as well as
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. 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.
The previous paragraph assumes the management system-to-router 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.
3. Management/Router Communication
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.
The previous paragraph assumes the management-system-to-router
communications are over a network. When the management system has a communications are over a network. When the management system has a
direct physical connection to the router, e.g., via the craft port, direct physical connection to the router, e.g., via the craft port,
there is no assumption that there is a protected channel between the there is no assumption that there is a protected channel between the
two. two.
To be clear: for both of these methods, an initial leap-of-faith is 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 required because the router has no keying material that it can use to
protect communications with anyone or anything. Because of this protect communications with anyone or anything. Because of this
initial leap of faith, a direct physical connection is safer than initial leap of faith, a direct physical connection is safer than a
connecting via a network connection because there is less chance of a network connection because there is less chance of a monkey in the
man in the middle. Once keying material is established on the middle. Once keying material is established on the router, the
router, the communications channel must prevent eavesdropping, communications channel must prevent eavesdropping, tampering, and
tampering, and message forgery. This initial leap-of-faith will no message forgery. This initial leap of faith will no longer be
longer be required once routers are delivered to operators with required once routers are delivered to operators with operator-
operator-trusted keying material trusted keying material.
3. Exchange Certificates 4. Exchange Certificates
A number of options exist for the operator management station to A number of options exist for the operator's management station to
exchange PKI-related information with routers and with the RPKI exchange PKI-related information with routers and with the RPKI
including: including:
- Using application/pkcs10 media type [RFC5967] to extract o Using application/pkcs10 media type [RFC5967] to extract
certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- certificate requests and application/pkcs7-mime [RFC8551] to
bis] to return the issued certificate, return the issued certificate,
- Using FTP or HTTP per [RFC2585], and o Using FTP or HTTP per [RFC2585], and
- Using Enrollment over Secure Transport (EST) protocol per o Using the Enrollment over Secure Transport (EST) protocol per
[RFC7030]. [RFC7030].
Despite the fact that Certificates are integrity-protected and do not Despite the fact that certificates are integrity-protected and do not
necessarily need additional protection, transports that also provide necessarily need additional protection, transports that also provide
integrity protection are RECOMMENDED. integrity protection are RECOMMENDED.
4. Set-Up 5. Setup
To start, the operator uses the protected channel to install the To start, the operator uses the protected channel to install the
appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. appropriate RPKI Trust Anchor's Certificate (TA Certificate) in the
This will later enable the router to validate the router certificate router. This will later enable the router to validate the router
returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. certificate returned in the PKCS#7 certs-only message [RFC8551].
The operator configures the Autonomous System (AS) number to be used The operator configures the Autonomous System (AS) number to be used
in the generated router certificate. This may be the sole AS in the generated router certificate. This may be the sole AS
configured on the router, or an operator choice if the router is configured on the router or an operator choice if the router is
configured with multiple ASs. A router with multiple ASs can be configured with multiple ASes. A router with multiple ASes can
configured with multiple router certificates by following the process generate multiple router certificates by following the process
of this document for each desired certificate. This configured AS described in this document for each desired certificate. This
number is also used during verification of keys, if generated by the configured AS number is also used during verification of keys, if
operator (see Section 5.2), as well as during certificate generated by the operator (see Section 6.2), as well as during
verification steps (see Sections 6, 7, and 8). certificate verification steps (see Sections 7, 8, and 9).
The operator configures or extracts from the router the BGP The operator configures or extracts from the router the BGP
Identifier [RFC6286] to be used in the generated router certificate. Identifier [RFC6286] to be used in the generated router certificate.
In the case where the operator has chosen not to use unique In the case where the operator has chosen not to use unique per-
per-router certificates, a BGP Identifier of 0 MAY be used. router certificates, a BGP Identifier of 0 MAY be used.
The operator configures the router's access control mechanism to The operator configures the router's access control mechanism to
ensure that only authorized users are able to later access the ensure that only authorized users are able to later access the
router's configuration. router's configuration.
5. Generate PKCS#10 6. Generate PKCS#10
The private key, and hence the PKCS#10 certification request, which The private key, and hence the PKCS#10 certification request, which
is sometimes referred to as a Certificate Signing Request (CSR), may is sometimes referred to as a Certificate Signing Request (CSR), may
be generated by the router or by the operator. be generated by the router or by the operator.
Retaining the CSR allows for verifying that the returned public key Retaining the CSR allows for verifying that the returned public key
in the certificate corresponds to the private key used to generate in the certificate corresponds to the private key used to generate
the signature on the CSR. the signature on the CSR.
NOTE: The PKCS#10 certification request does not include the AS NOTE: The PKCS#10 certification request does not include the AS
number or the BGP Identifier for the router certificate. Therefore, number or the BGP Identifier for the router certificate. Therefore,
the operator transmits the AS it has chosen on the router and the BGP the operator transmits the AS it has chosen on the router as well as
Identifier as well when it sends the CSR to the CA. the BGP Identifier when it sends the CSR to the CA.
5.1. Router-Generated Keys 6.1. Router-Driven Keys
In the router-generated method, once the protected channel is In the router-driven method, once the protected channel is
established and the initial Set-Up (Section 4) performed, the established and the initial setup (Section 5) performed, the operator
operator issues a command or commands for the router to generate the issues a command or commands for the router to generate the public-
public/private key pair, to generate the PKCS#10 certification private key pair, to generate the PKCS#10 certification request, and
request, and to sign the PKCS#10 certification request with the to sign the PKCS#10 certification request with the private key. Once
private key. Once the router has generated the PKCS#10 certification the router has generated the PKCS#10 certification request, it
request, it returns it to the operator over the protected channel. returns it to the operator over the protected channel.
The operator includes the chosen AS number and the BGP Identifier The operator includes the chosen AS number and the BGP Identifier
when it sends the CSR to the CA. when it sends the CSR to the CA.
Even if the operator cannot extract the private key from the router, Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a this signature still provides a link between a private key and a
router. That is, the operator can verify the proof of possession router. That is, the operator can verify the proof of possession
(POP), as required by [RFC6484]. (POP), as required by [RFC6484].
NOTE: The CA needs to know that the router-generated CSR is NOTE: The CA needs to know that the router-driven CSR is authorized.
authorized. The easiest way to accomplish this for the operator to The easiest way to accomplish this is for the operator to mediate the
mediate the communication with the CA. Other workflows are possible, communication with the CA. Other workflows are possible, e.g., where
e.g., where the router sends the CSR to the CA but the operator logs the router sends the CSR to the CA but the operator logs in to the CA
in to the CA independently and is presented with a list of pending independently and is presented with a list of pending requests to
requests to approve. See Section 8 for an additional workflow. approve. See Section 9 for an additional workflow.
If a router were to communicate directly with a CA to have the CA 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 certify the PKCS#10 certification request, there would be no way for
the CA to authenticate the router. As the operator knows the the CA to authenticate the router. As the operator knows the
authenticity of the router, the operator mediates the communication authenticity of the router, the operator mediates the communication
with the CA. with the CA.
5.2. Operator-Generated Keys 6.2. Operator-Driven Keys
In the operator-generated method, the operator generates the In the operator-driven method, the operator generates the public-
public/private key pair on a management station and installs the private key pair on a management station and installs the private key
private key into the router over the protected channel. Beware that into the router over the protected channel. Beware that experience
experience has shown that copy-and-paste from a management station to has shown that copy-and-paste from a management station to a router
a router can be unreliable for long texts. can be unreliable for long texts.
The operator then creates and signs the PKCS#10 certification request The operator then creates and signs the PKCS#10 certification request
with the private key; the operator includes the chosen AS number and with the private key; the operator includes the chosen AS number and
the BGP Identifier when it sends the CSR to the CA. the BGP Identifier when it sends the CSR to the CA.
5.2.1. Using PKCS#8 to Transfer Private Key 6.2.1. Using PKCS#8 to Transfer Private Keys
A private key can be encapsulated in a PKCS#8 Asymmetric Key Package A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
[RFC5958] and SHOULD be further encapsulated in Cryptographic Message [RFC5958] and SHOULD be further encapsulated in Cryptographic Message
Syntax (CMS) SignedData [RFC5652] and signed with the operators's End Syntax (CMS) SignedData [RFC5652] and signed with the operator's End
Entity (EE) private key. Entity (EE) private key.
The router SHOULD verify the signature of the encapsulated PKCS#8 to The router SHOULD verify the signature of the encapsulated PKCS#8 to
ensure the returned private key did in fact come from the operator, ensure the returned private key did in fact come from the operator,
but this requires that the operator also provision via the CLI or but this requires that the operator also provision via the CLI or
include in the SignedData the RPKI CA certificate and relevant include in the SignedData the RPKI CA certificate and relevant
operators' EE certificate(s). The router SHOULD inform the operator operators' EE certificate(s). The router SHOULD inform the operator
whether or not the signature validates to a trust anchor; this whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope. notification mechanism is out of scope.
6. Send PKCS#10 and Receive PKCS#7 7. Send PKCS#10 and Receive PKCS#7
The operator uses RPKI management tools to communicate with the The operator uses RPKI management tools to communicate with the
global RPKI system to have the appropriate CA validate the PKCS#10 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) certification request, sign the key in the PKCS#10 (i.e., certify
and generate a PKCS#7 certs-only message, as well as publishing the it), generate a PKCS#7 certs-only message, and publish the
certificate in the Global RPKI. External network connectivity may be certificate in the Global RPKI. External network connectivity may be
needed if the certificate is to be published in the Global RPKI. needed if the certificate is to be published in the Global RPKI.
After the CA certifies the key, it does two things: After the CA certifies the key, it does two things:
1. Publishes the certificate in the Global RPKI. The CA must have 1. Publishes the certificate in the Global RPKI. The CA must have
connectivity to the relevant publication point, which in turn connectivity to the relevant publication point, which, in turn,
must have external network connectivity as it is part of the must have external network connectivity as it is part of the
Global RPKI. Global RPKI.
2. Returns the certificate to the operator's management station, 2. Returns the certificate to the operator's management station,
packaged in a PKCS#7 certs-only message, using the corresponding packaged in a PKCS#7 certs-only message, using the corresponding
method by which it received the certificate request. It SHOULD method by which it received the certificate request. It SHOULD
include the certificate chain below the TA Certificate so that include the certificate chain below the TA Certificate so that
the router can validate the router certificate. the router can validate the router certificate.
In the operator-generated method, the operator SHOULD extract the In the operator-driven method, the operator SHOULD extract the
certificate from the PKCS#7 certs-only message, and verify that the certificate from the PKCS#7 certs-only message and verify that the
public key the operator holds corresponds to the returned public key 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 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 it can check this correspondence by comparing the public key in the
CSR to the public key in the returned certificate. If the operator CSR to the public key in the returned certificate. If the operator
has not saved the PKCS#10, it can check this correspondence by has not saved the PKCS#10, it can check this correspondence by
regenerating the public key from the private key and then verifying regenerating the public key from the private key and then verifying
that the regenerated public key matches the public key returned in that the regenerated public key matches the public key returned in
the certificate. the certificate.
In the operator-generated method, the operator has already installed In the operator-driven method, the operator has already installed the
the private key in the router (see Section 5.2). private key in the router (see Section 6.2).
7. Install Certificate 8. Install Certificate
The operator provisions the PKCS#7 certs-only message into the router The operator provisions the PKCS#7 certs-only message into the router
over the protected channel. over the protected channel.
The router SHOULD extract the certificate from the PKCS#7 certs-only The router SHOULD extract the certificate from the PKCS#7 certs-only
message and verify that the public key corresponds to the stored message and verify that the public key corresponds to the stored
private key. If the router stored the PKCS#10, it can check this 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 correspondence by comparing the public key in the CSR to the public
key in the returned certificate. If the router did not store the key in the returned certificate. If the router did not store the
PKCS#10, it can check this correspondence by generating a signature PKCS#10, it can check this correspondence by generating a signature
skipping to change at page 8, line 23 skipping to change at page 8, line 22
The router SHOULD also verify that the returned certificate validates The router SHOULD also verify that the returned certificate validates
back to the installed TA Certificate, i.e., the entire chain from the back to the installed TA Certificate, i.e., the entire chain from the
installed TA Certificate through subordinate CAs to the BGPsec installed TA Certificate through subordinate CAs to the BGPsec
certificate validate. To perform this verification, the CA certificate validate. To perform this verification, the CA
certificate chain needs to be returned along with the router's certificate chain needs to be returned along with the router's
certificate in the PKCS#7 certs-only message. The router SHOULD certificate in the PKCS#7 certs-only message. The router SHOULD
inform the operator whether or not the signature validates to a trust inform the operator whether or not the signature validates to a trust
anchor; this notification mechanism is out of scope. anchor; this notification mechanism is out of scope.
NOTE: The signature on the PKCS#8 and Certificate need not be made by NOTE: The signature on the PKCS#8 and Certificate need not be made by
the same entity. Signing the PKCS#8 permits more advanced the same entity. Signing the PKCS#8 permits more-advanced
configurations where the entity that generates the keys is not the configurations where the entity that generates the keys is not the
direct CA. direct CA.
8. Advanced Deployment Scenarios 9. Advanced Deployment Scenarios
More PKI-capable routers can take advantage of increased More PKI-capable routers can take advantage of increased
functionality and lighten the operator's burden. Typically, these functionality and lighten the operator's burden. Typically, these
routers include either pre-installed manufacturer-generated routers include either preinstalled manufacturer-driven certificates
certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed (e.g., IEEE 802.1 AR [IEEE802-1AR]) or preinstalled manufacturer-
manufacturer-generated Pre-Shared Keys (PSK) as well as driven Pre-Shared Keys (PSKs) as well as PKI-enrollment functionality
PKI-enrollment functionality and transport protocol, e.g., CMC's and transport protocol, e.g., CMC's "Secure Transport" [RFC7030] or
"Secure Transport" [RFC7030] or the original CMC transport protocol's the original CMC transport protocols [RFC5273]. When the operator
[RFC5273]. When the operator first establishes a protected channel first establishes a protected channel between the management system
between the management system and the router, this pre-installed key and the router, this preinstalled key material is used to
material is used to authenticate the router. authenticate the router.
The operator's burden shifts here to include: The operator's burden shifts here to include:
1. Securely communicating the router's authentication material to 1. Securely communicating the router's authentication material to
the CA prior to operator initiating the router's CSR. CAs use the CA prior to the operator initiating the router's CSR. CAs
authentication material to determine whether the router is use authentication material to determine whether the router is
eligible to receive a certificate. Authentication material at a eligible to receive a certificate. At a minimum, authentication
minimum includes the router's AS number and BGP Identifier as material includes the router's AS number and BGP Identifier as
well as the router's key material, but can also include well as the router's key material, but it can also include
additional information. Authentication material can be additional information. Authentication material can be
communicated to the CA (i.e., CSRs signed by this key material communicated to the CA (i.e., CSRs signed by this key material
are issued certificates with this AS and BGP Identifier) or to are issued certificates with this AS and BGP Identifier) or to
the router (i.e., the operator uses the vendor-supplied the router (i.e., the operator uses the vendor-supplied
management interface to include the AS number and BGP Identifier management interface to include the AS number and BGP Identifier
in the router-generated CSR). The CA stores this authentication in the router-driven CSR). The CA stores this authentication
material in an account entry for the router so that it can later 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 be compared against the CSR prior to the CA issuing a certificate
to the router. to the router.
2. Enabling the router to communicate with the CA. While the 2. Enabling the router to communicate with the CA. While the
router-to-CA communications are operator-initiated, the router-to-CA communications are operator-initiated, the
operator's management interface need not be involved in the operator's management interface need not be involved in the
communications path. Enabling the router-to-CA connectivity communications path. Enabling the router-to-CA connectivity may
requires connections to external networks (i.e., through require connections to external networks (i.e., through
firewalls, NATs, etc.). firewalls, NATs, etc.).
3. Ensuring the cryptographic chain of custody from the 3. Ensuring the cryptographic chain of custody from the
manufacturer. For the pre-installed key material, the operator manufacturer. For the preinstalled key material, the operator
needs guarantees that either no one has accessed the private key needs guarantees that either no one has accessed the private key
or an authenticated log of those who have accessed it has been or an authenticated log of those who have accessed it MUST be
provided to the operator. provided to the operator.
Once configured, the operator can begin the process of enrolling the Once configured, the operator can begin the process of enrolling the
router. Because the router is communicating directly with the CA, router. Because the router is communicating directly with the CA,
there is no need for the operator to retrieve the PKCS#10 there is no need for the operator to retrieve the PKCS#10
certification request from the router as in Section 5 or return the certification request from the router as in Section 6 or return the
PKCS#7 certs-only message to the router as in Section 6. Note that PKCS#7 certs-only message to the router as in Section 7. Note that
the checks performed by the router in Section 7, namely extracting the checks performed by the router in Section 8 (namely, extracting
the certificate from the PKCS#7 certs-only message, verifying the the certificate from the PKCS#7 certs-only message, verifying that
public key corresponds to the private key, and that the returned the public key corresponds to the private key, and verifying that the
certificate validated back to an installed trust anchor, SHOULD be returned certificate validated back to an installed trust anchor)
performed. Likewise, the router SHOULD notify the operator if any of SHOULD be performed. Likewise, the router SHOULD notify the operator
these fail, but this notification mechanism is out of scope. if any of these fail, but this notification mechanism is out of
scope.
When a router is so configured, the communication with the CA SHOULD When a router is so configured, the communication with the CA SHOULD
be automatically re-established by the router at future times to be automatically re-established by the router at future times to
renew the certificate automatically when necessary (See Section 9). renew the certificate automatically when necessary (see Section 10).
This further reduces the tasks required of the operator. This further reduces the tasks required of the operator.
9. Key Management 10. Key Management
Key management does not only include key generation, key Key management not only includes key generation, key provisioning,
provisioning, certificate issuance, and certificate distribution. It certificate issuance, and certificate distribution, it also includes
also includes assurance of key validity, key roll-over, and key assurance of key validity, key rollover, and key preservation during
preservation during router replacement. All of these router replacement. All of these responsibilities persist for as
responsibilities persist for as long as the operator wishes to long as the operator wishes to operate the BGPsec-speaking router.
operate the BGPsec-speaking router.
9.1. Key Validity 10.1. Key Validity
It is critical that a BGPsec-speaking router is signing with a valid 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 private key at all times. To this end, the operator needs to ensure
the router always has a non-expired certificate. I.e. the key used the router always has an unexpired certificate. That is, the key
to sign BGPsec announcements always has an associated certificate used to sign BGPsec announcements always has an associated
whose expiry time is after the current time. certificate whose expiry time is after the current time.
Ensuring this is not terribly difficult but requires that either: Ensuring this is not terribly difficult but requires that either:
1. The router have a mechanism to notify the operator that the 1. The router has a mechanism to notify the operator that the
certificate has an impending expiration, and/or certificate has an impending expiration, and/or
2. The operator note the expiry time of the certificate and uses a 2. The operator notes the expiry time of the certificate and uses a
calendaring program to remind them of the expiry time, and/or calendaring program to remind them of the expiry time, and/or
3. The RPKI CA warn the operator of pending expiration, and/or 3. The RPKI CA warns the operator of pending expiration, and/or
4. The operator use some other kind of automated process to search 4. The operator uses some other kind of automated process to search
for and track the expiry times of router certificates. for and track the expiry times of router certificates.
It is advisable that expiration warnings happen well in advance of It is advisable that expiration warnings happen well in advance of
the actual expiry time. the actual expiry time.
Regardless of the technique used to track router certificate expiry Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same times, additional operators in the same organization should be
organization as the expiry time approaches, thereby ensuring that the notified as the expiry time approaches, thereby ensuring that the
forgetfulness of one operator does not affect the entire forgetfulness of one operator does not affect the entire
organization. organization.
Depending on inter-operator relationship, it may be helpful to notify Depending on inter-operator relationships, it may be helpful to
a peer operator that one or more of their certificates are about to notify a peer operator that one or more of their certificates are
expire. about to expire.
9.2. Key Roll-Over 10.2. Key Rollover
Routers that support multiple private keys also greatly increase the Routers that support multiple private keys also greatly increase the
chance that routers can continuously speak BGPsec because the new chance that routers can continuously speak BGPsec because the new
private key and certificate can be obtained and distributed prior to private key and certificate can be obtained and distributed prior to
expiration of the operational key. Obviously, the router needs 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 know when to start using the new key. Once the new key is being
used, having the already distributed certificate ensures continuous used, having the already-distributed certificate ensures continuous
operation. operation.
More information on how to proceed with a Key Roll-Over is described More information on how to proceed with a key rollover is described
in [I-D.sidrops-bgpsec-rollover]. in [RFC8634].
9.3. Key Revocation 10.3. Key Revocation
In certain circumstances, a router's BGPsec certificate may need to In certain circumstances, a router's BGPsec certificate may need to
be revoked. When this occurs, the operator needs to use the RPKI CA be revoked. When this occurs, the operator needs to use the RPKI CA
system to revoke the certificate by placing the router's BGPsec system to revoke the certificate by placing the router's BGPsec
certificate on the Certificate Revocation List (CRL) as well as certificate on the Certificate Revocation List (CRL) as well as re-
re-keying the router's certificate. keying the router's certificate.
When an active router key is to be revoked, the process of requesting The process of revoking an active router key consists of requesting
the CA to revoke, the process of the CA actually revoking the the revocation from the CA, the CA actually revoking the router's
router's certificate, and then the process of re-keying/renewing the certificate, the re-keying/renewing of the router's certificate
router's certificate, (possibly distributing a new key and (possibly) distributing a new key and certificate to the router, and
certificate to the router), and distributing the status, takes time distributing the status. During the time this process takes, the
during which the operator must decide how they wish to maintain operator must decide how they wish to maintain continuity of
continuity of operations, with or without the compromised private operation (with or without the compromised private key) or whether
key, or whether they wish to bring the router offline to address the they wish to bring the router offline to address the compromise.
compromise.
Keeping the router operational and BGPsec-speaking is the ideal goal; Keeping the router operational and BGPsec-speaking is the ideal goal;
but, if operational practices do not allow this, then reconfiguring but, if operational practices do not allow this, then reconfiguring
the router to disable BGPsec is likely preferred to bringing the the router to disable BGPsec is likely preferred to bringing the
router offline. router offline.
Routers which support more than one private key, where one is Routers that support more than one private key, where one is
operational and other(s) are soon-to-be-operational, facilitate operational and other(s) are soon-to-be-operational, facilitate
revocation events because the operator can configure the router to revocation events because the operator can configure the router to
make a soon-to-be-operational key operational, request revocation of make a soon-to-be-operational key operational, request revocation of
the compromised key, and then make a next generation the compromised key, and then make a next generation soon-to-be-
soon-to-be-operational key. Hopefully, all this can be done without operational key. Hopefully, all this can be done without needing to
needing to take offline or reboot the router. For routers which take the router offline or reboot it. For routers that support only
support only one operational key, the operators should create or one operational key, the operators should create or install the new
install the new private key, and then request revocation of the private key and then request revocation of the certificate
certificate corresponding to the compromised private key. corresponding to the compromised private key.
9.4. Router Replacement 10.4. Router Replacement
Currently routers often generate private keys for uses such as SSH, At the time of writing, routers often generate private keys for uses
and the private keys may not be seen or exported from the router. such as Secure Shell (SSH), and the private keys may not be seen or
While this is good security, it creates difficulties when a routing exported from the router. While this is good security, it creates
engine or whole router must be replaced in the field and all software difficulties when a routing engine or whole router must be replaced
which accesses the router must be updated with the new keys. Also, in the field and all software that accesses the router must be
any network based initial contact with a new routing engine requires updated with the new keys. Also, any network-based initial contact
trust in the public key presented on first contact. with a new routing engine requires trust in the public key presented
on first contact.
To allow operators to quickly replace routers without requiring To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI, update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to be inserted via a routers SHOULD allow the private BGPsec key to be inserted via a
protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This protected channel, e.g., SSH, NETCONF (see [RFC6470]), and SNMP.
lets the operator escrow the old private key via the mechanism used
for operator-generated keys, see Section 5.2, such that it can be re- This lets the operator escrow the old private key via the mechanism
inserted into a replacement router. The router MAY allow the private used for operator-driven keys (see Section 6.2), such that it can be
key to be to be exported via the protected channel after key 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 generation, but this SHOULD be paired with functionality that sets
the newly generated key into a permanent non-exportable state to the newly generated key into a permanent non-exportable state to
ensure that it is not exported at a future time by unauthorized ensure that it is not exported at a future time by unauthorized
operations. operations.
10. Security Considerations 11. Security Considerations
The router's manual will describe whether the router supports one, The router's manual will describe which of the key-generation options
the other, or both of the key generation options discussed in the discussed in the earlier sections of this document a router supports
earlier sections of this draft as well as other important security- or if it supports both of them. The manual will also describe other
related information (e.g., how to SSH to the router). After important security-related information (e.g., how to SSH to the
familiarizing one's self with the capabilities of the router, an router). After becoming familiar with the capabilities of the
operator is encouraged to ensure that the router is patched with the router, an operator is encouraged to ensure that the router is
latest software updates available from the manufacturer. patched with the latest software updates available from the
manufacturer.
This document defines no protocols. So, in some sense, it introduces This document defines no protocols. So, in some sense, it introduces
no new security considerations. However, it relies on many others no new security considerations. However, it relies on many other
and the security considerations in the referenced documents should be protocols, and the security considerations in the referenced
consulted; notably, those document listed in Section 1 should be documents should be consulted; notably, the documents listed in
consulted first. PKI-relying protocols, of which BGPsec is one, have Section 1 should be consulted first. PKI-relying protocols, of which
many issues to consider - so many, in fact, entire books have been BGPsec is one, have many issues to consider -- so many, in fact,
written to address them; so listing all PKI-related security entire books have been written to address them -- so listing all PKI-
considerations is neither useful nor helpful. Regardless, some boot- related security considerations is neither useful nor helpful.
strapping-related issues are listed here that are worth repeating: Regardless, some bootstrapping-related issues that are worth
repeating are listed here:
Public-Private key pair generation: Mistakes here are, for all, o Public-private key pair generation: Mistakes here are, for all
practical purposes catastrophic because PKIs rely on the pairing practical purposes, catastrophic because PKIs rely on the pairing
of a difficult to generate public-private key pair with a signer; of a difficult-to-generate public-private key pair with a signer;
all key pairs MUST be generated from a good source of non- all key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086]. deterministic random input [RFC4086].
Private key protection at rest: Mistakes here are, for all, practical o Private key protection at rest: Mistakes here are, for all,
purposes catastrophic because disclosure of the private key allows practical purposes, catastrophic because disclosure of the private
another entity to masquerade as (i.e., impersonate) the signer; key allows another entity to masquerade as (i.e., impersonate) the
all private keys MUST be protected when at rest in a secure signer; all private keys MUST be protected when at rest in a
fashion. Obviously, how each router protects private keys is secure fashion. Obviously, how each router protects private keys
implementation specific. Likewise, the local storage format for is implementation specific. Likewise, the local storage format
the private key is just that, a local matter. for the private key is just that: a local matter.
Private key protection in transit: Mistakes here are, for all, o Private key protection in transit: Mistakes here are, for all
practical purposes catastrophic because disclosure of the private practical purposes, catastrophic because disclosure of the private
key allows another entity to masquerade as (i.e., impersonate) the key allows another entity to masquerade as (i.e., impersonate) the
signer; transport security is therefore strongly RECOMMENDED. The signer; therefore, transport security is strongly RECOMMENDED.
level of security provided by the transport layer's security The level of security provided by the transport layer's security
mechanism SHOULD be at least as good as the strength of the BGPsec 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 key; there's no point in spending time and energy to generate an
excellent public-private key pair and then transmit the private excellent public-private key pair and then transmit the private
key in the clear or with a known-to-be-broken algorithm, as it 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. just undermines trust that the private key has been kept private.
Additionally, operators SHOULD ensure the transport security Additionally, operators SHOULD ensure the transport security
mechanism is up to date, in order to addresses all known mechanism is up to date, in order to address all known
implementation bugs. implementation bugs.
Though the CA's certificate is installed on the router and used to 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 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 revocation status of the CA's certificate is rarely checked as the
router may not have global connectivity or CRL-aware software. The router may not have global connectivity or CRL-aware software. The
operator MUST ensure that the installed CA certificate is valid. operator MUST ensure that the installed CA certificate is valid.
11. IANA Considerations 12. IANA Considerations
This document has no IANA Considerations.
12. References This document has no IANA actions.
12.1. Normative References 13. References
[I-D.sidrops-bgpsec-rollover] 13.1. Normative References
Weis, B, R. Gagliano, and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidrops-bgpsec-
rollover (work in progress), December 2017.
[I-D.lamps-rfc5751-bis] [IEEE802-1AR]
Schaad, J., Ramsdell, B, S. Turner, IEEE, "IEEE Standard for Local and Metropolitan Area
"Secure/Multipurpose Internet Mail Extension (S/MIME) Networks - Secure Device Identity", IEEE Std 802.1AR,
Version 4.0", draft-ietf-lamps-rfc5751- <https://standards.ieee.org/standard/802_1AR-2018.html>.
bis (work in progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119,
10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <https://www.rfc- DOI 10.17487/RFC4086, June 2005,
editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
10.17487/RFC5958, August 2010, <https://www.rfc- DOI 10.17487/RFC5958, August 2010,
editor.org/info/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>. June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
RFC 2119 Key Words", BCP 14, RFC 8174, DOI 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
10.17487/RFC8174, May 2017, <https://www.rfc- May 2017, <https://www.rfc-editor.org/info/rfc8174>.
editor.org/info/rfc8174>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208, DOI Formats, and Signature Formats", RFC 8608,
10.17487/RFC8208, September 2017, <https://www.rfc- DOI 10.17487/RFC8608, June 2019,
editor.org/info/rfc8208>. <https://www.rfc-editor.org/info/rfc8608>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209, DOI and Certification Requests", RFC 8209,
10.17487/RFC8209, September 2017, <https://www.rfc- DOI 10.17487/RFC8209, September 2017,
editor.org/info/rfc8209>. <https://www.rfc-editor.org/info/rfc8209>.
[802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
metropolitan area networks - Secure Device Identity", Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
December 2009, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
<http://standards.ieee.org/findstds/standard/802.1AR- April 2019, <https://www.rfc-editor.org/info/rfc8551>.
2009.html>.
12.1. Informative References [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>.
13.2. Informative References
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004, RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>. <https://www.rfc-editor.org/info/rfc3766>.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, DOI (CMC): Transport Protocols", RFC 5273,
10.17487/RFC5273, June 2008, <https://www.rfc- DOI 10.17487/RFC5273, June 2008,
editor.org/info/rfc5273>. <https://www.rfc-editor.org/info/rfc5273>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>. <https://www.rfc-editor.org/info/rfc5480>.
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
Secure Shell Transport Layer Protocol", RFC 5647, DOI Secure Shell Transport Layer Protocol", RFC 5647,
10.17487/RFC5647, August 2009, <https://www.rfc- DOI 10.17487/RFC5647, August 2009,
editor.org/info/rfc5647>. <https://www.rfc-editor.org/info/rfc5647>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer", Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009, RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>. <https://www.rfc-editor.org/info/rfc5656>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
DOI 10.17487/RFC5967, August 2010, <https://www.rfc- DOI 10.17487/RFC5967, August 2010,
editor.org/info/rfc5967>. <https://www.rfc-editor.org/info/rfc5967>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
March 2011, <https://www.rfc-editor.org/info/rfc6187>. March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470, Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
February 2012, <https://www.rfc-editor.org/info/rfc6470>. February 2012, <https://www.rfc-editor.org/info/rfc6470>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource Public Key Infrastructure Policy (CP) for the Resource Public Key Infrastructure
(RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February
2012, <https://www.rfc-editor.org/info/rfc6484>. 2012, <https://www.rfc-editor.org/info/rfc6484>.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity
Verification for the Secure Shell (SSH) Transport Layer Verification for the Secure Shell (SSH) Transport Layer
Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012, Protocol", RFC 6668, DOI 10.17487/RFC6668, July 2012,
<https://www.rfc-editor.org/info/rfc6668>. <https://www.rfc-editor.org/info/rfc6668>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, DOI "Enrollment over Secure Transport", RFC 7030,
10.17487/RFC7030, October 2013, <https://www.rfc- DOI 10.17487/RFC7030, October 2013,
editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[SP800-57] National Institute of Standards and Technology (NIST), [SP800-57]
Special Publication 800-57: Recommendation for Key National Institute of Standards and Technology (NIST),
Management - Part 1 (Revised), March 2007. "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>.
Appendix A. Management/Router Channel Security Appendix A. Management/Router Channel Security
Encryption, integrity, authentication, and key exchange algorithms Encryption, integrity, authentication, and key-exchange algorithms
used by the protected channel should be of equal or greater strength used by the protected channel should be of equal or greater strength
than the BGPsec keys they protect, which for the algorithm specified than the BGPsec keys they protect, which for the algorithm specified
in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57] in [RFC8608] is 128 bits; see [RFC5480] and [SP800-57] for
for information about this strength claim as well as [RFC3766] for information about this strength claim as well as [RFC3766] for "how
"how to determine the length of an asymmetric key as a function of a to determine the length of an asymmetric key as a function of a
symmetric key strength requirement." In other words, for the symmetric key strength requirement". In other words, for the
encryption algorithm, do not use export grade crypto (40-56 bits of encryption algorithm, do not use export grade crypto (40-56 bits of
security), do not use Triple DES (112 bits of security). Suggested security), and do not use Triple-DES (112 bits of security).
minimum algorithms would be AES-128: aes128-cbc [RFC4253] and Suggested minimum algorithms would be AES-128, specifically the
AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or following:
AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256
[RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for o aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for
key exchange. encryption,
o hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for
integrity,
o ecdsa-sha2-nistp256 [RFC5656] for authentication, and
o ecdh-sha2-nistp256 [RFC5656] for key exchange.
Some routers support the use of public key certificates and SSH. The 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 the SSH session are different than the
certificates used for BGPsec. The certificates used with SSH should certificates used for BGPsec. The certificates used with SSH should
also enable a level of security at least as good as the security also enable a level of security at least as good as the security
offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could offered by the BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187]
be used for authentication. could be used for authentication.
The protected channel must provide confidentiality, authentication, The protected channel must provide confidentiality, authentication,
and integrity and replay protection. and integrity and replay protection.
Appendix B. An Introduction to BGPsec Key Management Appendix B. An Introduction to BGPsec Key Management
This appendix is informative. It attempts to explain some of the PKI This appendix is informative. It attempts to explain some of the PKI
lingo in plainer language. jargon.
BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers send signed BGPsec updates that are verified by other
BGPsec speakers. In PKI parlance, the senders are referred to as BGPsec speakers. In PKI parlance, the senders are referred to as
signers and the receivers are referred to as relying parties. The "signers", and the receivers are referred to as "relying parties".
signers with which we are concerned here are routers signing BGPsec The signers with which we are concerned here are routers signing
updates. Signers use private keys to sign and relying parties use BGPsec updates. Signers use private keys to sign, and relying
the corresponding public keys, in the form of X.509 public key parties use the corresponding public keys, in the form of X.509
certificates, to verify signatures. The third party involved is the public key certificates, to verify signatures. The third party
entity that issues the X.509 public key certificate, the involved is the entity that issues the X.509 public key certificate,
Certification Authority (CA). Key management is all about making the Certification Authority (CA). Key management is all about making
these key pairs and the certificates, as well as ensuring that the these key pairs and the certificates, as well as ensuring that the
relying parties trust that the certified public keys in fact relying parties trust that the certified public keys in fact
correspond to the signers' private keys. correspond to the signers' private keys.
The specifics of key management greatly depend on the routers as well The specifics of key management greatly depend on the routers as well
as management interfaces provided by the routers' vendor. Because of as management interfaces provided by the routers' vendor. Because of
these differences, it is hard to write a definitive "how to," but these differences, it is hard to write a definitive "how to", but
this guide is intended to arm operators with enough information to this guide is intended to arm operators with enough information to
ask the right questions. The other aspect that makes this guide ask the right questions. The other aspect that makes this guide
informative is that the steps for the do-it-yourself (DIY) approach informative is that the steps for the do-it-yourself (DIY) approach
involve arcane commands while the GUI-based vendor-assisted involve arcane commands while the GUI-based vendor-assisted
management console approach will likely hide all of those commands management console approach will likely hide all of those commands
behind some button clicks. Regardless, the operator will end up with behind some button clicks. Regardless, the operator will end up with
a BGPsec-enabled router. Initially, we focus on the DIY approach and a BGPsec-enabled router. Initially, we focus on the DIY approach and
then follow up with some information about the GUI-based approach. then follow up with some information about the GUI-based approach.
The first step in the DIY approach is to generate a private key; but The first step in the DIY approach is to generate a private key.
in fact what you do is create a key pair; one part, the private key, However, in fact, what you do is create a key pair: one part (the
is kept very private and the other part, the public key, is given out private key) is kept very private, and the other part (the public
to verify whatever is signed. The two methods for how to create the key) is given out to verify whatever is signed. The two methods for
key pair are the subject of this document, but it boils down to how to create the key pair are the subject of this document, but it
either doing it on-router (router-driven) or off-router (operator- boils down to either doing it on-router (router-driven) or off-router
driven). (operator-driven).
If you are generating keys on the router (router-driven), then you 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 will need to access the router. Again, how you access the router is
router-specific, but generally the DIY approach uses the CLI and router-specific, but generally the DIY approach involves using the
accessing the router either directly via the router's craft port or CLI and accessing the router either directly via the router's craft
over the network on an administrative interface. If accessing the port or over the network on an administrative interface. If
router over the network be sure to do it securely (i.e., use SSHv2). accessing the router over the network, be sure to do it securely
Once logged into the router, issue a command or a series of commands (i.e., use SSHv2). Once logged into the router, issue a command or a
that will generate the key pair for the algorithms referenced in the series of commands that will generate the key pair for the algorithms
main body of this document; consult your router's documentation for referenced in the main body of this document; consult your router's
the specific commands. The key generation process will yield one or documentation for the specific commands. The key-generation process
more files the private key and the public key; the file format varies will yield one or more files containing the private key and the
depending on the arcane command you issued, but generally the files public key; the file format varies depending on, among other things,
are DER or PEM-encoded. the arcane command the operator issued; however, the files are
generally DER- or PEM-encoded.
The second step is to generate the certification request, which is The second step is to generate the certification request, which is
often referred to as a certificate signing request (CSR) or PKCS#10 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 certification request, and to send it to the CA to be signed. To
generate the CSR, you issue some more arcane commands while logged generate the CSR, the operator issues some more arcane commands while
into the router; using the private key just generated to sign the logged into the router; using the private key just generated to sign
certification request with the algorithms referenced in the main body the certification request with the algorithms referenced in the main
of this document; the CSR is signed to prove to the CA that the 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 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 proof-of-possession). The output of the command is the CSR file; the
file format varies depending on the arcane command you issued, but file format varies depending on the arcane command you issued, but
generally the files are DER or PEM-encoded. generally the files are DER- or PEM-encoded.
The third step is to retrieve the signed CSR from the router and send 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 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 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 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 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 CSR to the CA is beyond the scope of this document. While you are
still connected to the router, install the Trust Anchor (TA) for the still connected to the router, install the trust anchor for the root
root of the PKI. At this point, you no longer need access to the of the PKI. At this point, you no longer need access to the router
router for BGPsec-related initiation purposes. for BGPsec-related initiation purposes.
The fourth step is for the CA to issue the certificate based on the 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 CSR you sent. The certificate will include the subject name, serial
number, public key, and other fields as well as being signed by the number, public key, and other fields; it will also be signed by the
CA. After the CA issues the certificate, the CA returns the CA. After the CA issues the certificate, the CA returns the
certificate, and posts the certificate to the RPKI repository. Check certificate and posts the certificate to the RPKI repository. Check
that the certificate corresponds to the public key contained in the that the certificate corresponds to the public key contained in the
certificate by verifying the signature on the CSR sent to the CA; 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 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., 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 the math will work when verifying a signature generated by the
private with the returned certificate). private key with the returned certificate).
If generating the keys off-router (operator-driven), then the same If generating the keys off-router (operator-driven), then the same
steps are used as the on-router key generation, (possibly with the steps are used as with on-router key generation (possibly with the
same arcane commands as those used in the on-router approach), but no same arcane commands as those used in the on-router approach).
access to the router is needed the first three steps are done on an However, no access to the router is needed, and the first three steps
administrative workstation: o Step 1: Generate key pair; o Step 2: are done on an administrative workstation:
Create CSR and sign CSR with private key, and; o Step 3: Send CSR
file with the subject name and serial number to CA. 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.
After the CA has returned the certificate and you have checked the After the CA has returned the certificate and you have checked the
certificate, you need to put the private key and TA in the router. certificate, you need to put the private key and trust anchor in the
Assuming the DIY approach, you will be using the CLI and accessing router. Assuming the DIY approach, you will be using the CLI and
the router either directly via the router's craft port or over the accessing the router either directly via the router's craft port or
network on an admin interface; if accessing the router over the over the network on an admin interface; if accessing the router over
network make doubly sure it is done securely (i.e., use SSHv2) 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 because the private key is being moved over the network. At this
point, access to the router is no longer needed for BGPsec-related point, access to the router is no longer needed for BGPsec-related
initiation purposes. initiation purposes.
NOTE: Regardless of the approach taken, the first three steps could NOTE: Regardless of the approach taken, the first three steps could
trivially be collapsed by a vendor-provided script to yield the trivially be collapsed by a vendor-provided script to yield the
private key and the signed CSR. private key and the signed CSR.
Given a GUI-based vendor-assisted management console, then all of Given a GUI-based vendor-assisted management console, all of these
these steps will likely be hidden behind pointing and clicking the steps will likely be hidden behind pointing and clicking the way
way through BGPsec-enabling the router. through BGPsec-enabling the router.
The scenarios described above require the operator to access each The scenarios described above require the operator to access each
router, which does not scale well to large networks. An alternative router, which does not scale well to large networks. An alternative
would be to create an image, perform the necessary steps to get the 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 private key and trust anchor on the image, and then install the image
via a management protocol. via a management protocol.
One final word of advice; certificates include a notAfter field that One final word of advice: certificates include a notAfter field that
unsurprisingly indicates when relying parties should no longer trust unsurprisingly indicates when relying parties should no longer trust
the certificate. To avoid having routers with expired certificates the certificate. To avoid having routers with expired certificates,
follow the recommendations in the Certification Policy (CP) [RFC6484] follow the recommendations in the Certification Policy (CP) [RFC6484]
and make sure to renew the certificate at least one week prior to the 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 date. Set a calendar reminder in order not to forget!
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
IIJ / Dragon Research Labs IIJ & Arrcus
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US United States of America
Email: randy@psg.com Email: randy@psg.com
Sean Turner Sean Turner
sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
 End of changes. 130 change blocks. 
396 lines changed or deleted 409 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/