< draft-ietf-sidrops-rtr-keying-03.txt   draft-ietf-sidrops-rtr-keying-04.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Lab / Dragon Research Lab Internet-Draft IIJ Lab / Dragon Research Lab
Intended status: Best Current Practice S. Turner Intended status: Best Current Practice S. Turner
Expires: July 20, 2019 sn3rd Expires: August 31, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
January 16, 2019 February 27, 2019
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-03 draft-ietf-sidrops-rtr-keying-04
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, enabling
verification of BGPsec messages. This document describes two methods verification of BGPsec messages. This document describes two methods
of generating the public-private key-pairs: router-driven and of generating the public-private key-pairs: router-driven and
operator-driven. operator-driven.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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. Management / Router Communication . . . . . . . . . . . . . . 4
3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6
5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6
6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10
9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.1. Informative References . . . . . . . . . . . . . . . . . 13 12.1. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Management/Router Channel Security . . . . . . . . . 14 Appendix A. Management/Router Channel Security . . . . . . . . . 15
Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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-driven method. Routers are required to support at least one operator-driven method. Routers are required to support at least one
of the methods in order to work in various deployment environments. of the methods in order to work in various deployment environments.
Some routers may not allow the private key to be off-loaded while Some routers may not allow the private key to be exported while
others may. While off-loading private keys would ease swapping of others may. While exporting private keys would ease swapping of
routing engines, exposure of private keys is a well known security routing engines, exposure of private keys is a well known security
risk. risk.
In the operator-driven method, the operator generates the In the operator-driven method, the operator generates the
private/public key-pair and sends it to the router. private/public key-pair and sends it to the router.
In the router-driven method, the router generates its own In the router-driven method, the router generates its own
public/private key-pair. public/private key-pair.
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). This is by design and supports classic
PKI Certification Policies for (often human) subscribers which PKI Certification Policies for (often human) subscribers which
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. For example, when an operator this method does not always work. The operator-driven model is
wants to support hot-swappable routers, the same private key needs to motivated by the extreme importance placed on ensuring the continued
be installed in the soon-to-be online router that was used by the the operation of the network. In some deployments, the same private key
soon-to-be offline router. This motivated the operator-driven needs to be installed in the soon-to-be online router that was used
method. 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.
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 2 through 7 describe the various steps involved for an Sections 2 through 7 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 end points (i.e., the management station and the router) and
acting as the intermediary. Section 8 describes another method that acting as the intermediary. Section 8 describes another method that
requires more capable routers. requires more capable routers.
Useful References: [RFC8205] describes gritty details, [RFC8209] Useful References: [RFC8205] describes details of BGPsec, [RFC8209]
specifies the format for the PKCS#10 certification request, and specifies the format for the PKCS#10 certification request, and
[RFC8208] specifies the algorithms used to generate the PKCS#10's [RFC8208] specifies the algorithms used to generate the PKCS#10
signature. signature.
2. Management / Router Communication 2. Management / Router Communication
Operators are free to use either the router-driven or operator-driven Operators are free to use either the router-driven or operator-driven
method as supported by the platform. Regardless of the method method as supported by the platform. Prudent security practice
chosen, operators first establish a protected channel between the recommends router-generated keying, if the delay in replacing a
management system and the router. How this protected channel is 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. established is router-specific and is beyond scope of this document.
Though other configuration mechanisms might be used, e.g. NetConf Though other configuration mechanisms might be used, e.g. NETCONF
(see [RFC6470]), the protected the protected channel between the (see [RFC6470]), the protected channel used between the management
management platform and the router is assumed to be an SSH-protected platform and the router is assumed to be an SSH-protected CLI. See
CLI. See Appendix A for security considerations for this protected Appendix A for security considerations for this protected channel.
channel.
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.
3. Exchange Certificates 3. Exchange Certificates
A number of options exist for the operator management station to A number of options exist for the operator 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 - Using application/pkcs10 media type [RFC5967] to extract
certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751-
bis] to return the issued certificate, bis] to return the issued certificate,
- Using FTP or HTTP per [RFC2585], and - Using FTP or HTTP per [RFC2585], and
- Using Enrollment over Secure Transport (EST) protocol per - Using Enrollment over Secure Transport (EST) protocol per
[RFC7030]. [RFC7030].
Despite the fact that Certificates are integrity-protected and do not
necessarily need additional protection, transports that also provide
integrity protection are RECOMMENDED.
4. Set-Up 4. Set-Up
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 Cert) in the router.
This will later enable the router to validate the router certificate This will later enable the router to validate the router certificate
returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis].
The operator also configures the Autonomous System (AS) number to be The operator configures the Autonomous System (AS) number to be used
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 ASs. A router with multiple ASs can be
configured with multiple router certificates by following the process configured with multiple router certificates by following the process
of this document for each desired certificate. of this document for each desired certificate. This configured AS
number is also used during verification of keys, if generated by the
operator (see Section 5.2), as well as during certificate
verification steps (see Sections 6, 7, and 8).
The operator configures or extracts from the router the BGP The operator configures or extracts from the router the BGP
Identifier [RFC4271] 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-router certificates, a BGP Identifier of 0 MAY be used. per-router certificates, a BGP Identifier of 0 MAY be used.
The operator configures the router's access control mechanism to
ensure that only authorized users are able to later access the
router's configuration.
5. Generate PKCS#10 5. 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.
The PKCS#10 request SHOULD be saved to enable verifying that the Retaining the CSR allows for verifying that the returned public key
returned public key in the certificate corresponds to the private in the certificate corresponds to the private key used to generate
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 and the BGP
Identifier as well when it sends the CSR to the CA. Identifier as well when it sends the CSR to the CA.
5.1. Router-Generated Keys 5.1. Router-Generated Keys
In the router-generated method, once the protected channel is In the router-generated method, once the protected channel is
established and the initial Set-Up (Section 4) performed, the established and the initial Set-Up (Section 4) performed, the
operator issues a command or commands for the router to generate the operator issues a command or commands for the router to generate the
public/private key pair, to generate the PKCS#10 certification public/private key pair, to generate the PKCS#10 certification
request, and to sign the PKCS#10 certification request with the request, and to sign the PKCS#10 certification request with the
private key. Once the router has generated the PKCS#10 certification private key. Once the router has generated the PKCS#10 certification
request, it returns it to the operator over the protected channel. request, it 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.
NOTE: If a router were to communicate directly with a CA to have the Even if the operator cannot extract the private key from the router,
CA certify the PKCS#10 certification request, there would be no way this signature still provides a linkage between a private key and a
for the CA to authenticate the router. As the operator knows the router. That is, the operator can verify the proof of possession
(POP), as required by [RFC6484].
NOTE: The CA needs to know that the router-generated CSR is
authorized. The easiest way to accomplish this 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 8 for an additional workflow.
If a router were 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 authenticity of the router, the operator mediates the communication
with the CA. with the CA.
5.2. Operator-Generated Keys 5.2. Operator-Generated Keys
In the operator-generated method, the operator generates the In the operator-generated method, the operator generates the
public/private key pair on a management station and installs the public/private key pair on a management station and installs the
private key into the router over the protected channel. Beware that private key into the router over the protected channel. Beware that
experience has shown that copy-and-paste from a management station to experience has shown that copy-and-paste from a management station to
a router can be unreliable for long texts. a router 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.
Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a
router. That is, the operator can verify the proof of possession
(POP), as required by [RFC6484].
5.2.1. Using PKCS#8 to Transfer Private Key 5.2.1. Using PKCS#8 to Transfer Private Key
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 operators'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
operator's EE certificate(s). The router should inform the operator operator's 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 6. 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 it)
and generate a PKCS#7 certs-only message, as well as publishing the and generate a PKCS#7 certs-only message, as well as publishing the
certificate in the Global RPKI. External network connectivity may be certificate in the Global RPKI. External network connectivity may be
skipping to change at page 6, line 41 skipping to change at page 7, line 29
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-generated 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
private key it holds corresponds to the returned public key. If the public key the operator holds corresponds to the returned public key
operator saved the PKCS#10 it can check this correspondence by in the PKCS#7 certs-only message. If the operator saved the PKCS#10
comparing the public key in the CSR to the public key in the returned it can check this correspondence by comparing the public key in the
certificate. If the operator has not saved the PKCS#10, it can check CSR to the public key in the returned certificate. If the operator
this correspondence by generating a signature on any data and then has not saved the PKCS#10, it can check this correspondence by
verifying the signature using the returned certificate. regenerating the public key from the private key and then verifying
that the regenerated public key matches the public key returned in
the certificate.
In the operator-generated method, the operator has already installed In the operator-generated method, the operator has already installed
the private key in the router (see Section 5.2). the private key in the router (see Section 5.2).
7. Install Certificate 7. 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
on any data and then verifying the signature using the returned on any data and then verifying the signature using the returned
skipping to change at page 7, line 34 skipping to change at page 8, line 24
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 8. Advanced Deployment Scenarios
More PKI-capable routers can take advantage of this 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 pre-installed manufacturer-generated
certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed
manufacturer-generated Pre-Shared Keys (PSK) as well as manufacturer-generated Pre-Shared Keys (PSK) as well as
PKI-enrollment functionality and transport protocol, e.g., CMC's PKI-enrollment functionality and transport protocol, e.g., CMC's
"Secure Transport" [RFC7030] or the original CMC transport protocol's "Secure Transport" [RFC7030] or the original CMC transport protocol's
[RFC5273]. When the operator first establishes a protected channel [RFC5273]. When the operator first establishes a protected channel
between the management system and the router, this pre-installed key between the management system and the router, this pre-installed key
material is used to authenticate the router. material is used to authenticate the router.
skipping to change at page 8, line 15 skipping to change at page 9, line 5
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). in the router-generated CSR).
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 MAY communications path. Enabling the router-to-CA connectivity
require connections to external networks (i.e., through requires connections to external networks (i.e., through
firewalls, NATs, etc.). firewalls, NATs, etc.).
3. Ensuring the cryptographic chain of custody from the
manufacturer. For the pre-installed 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 has been
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 5 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 6. Note that
the checks performed by the router in Section 7, namely extracting the checks performed by the router in Section 7, namely extracting
the certificate from the PKCS#7 certs-only message, verifying the the certificate from the PKCS#7 certs-only message, verifying the
public key corresponds to the private key, and that the returned public key corresponds to the private key, and that the returned
certificate validated back to an installed trust anchor, SHOULD be certificate validated back to an installed trust anchor, SHOULD be
performed. Likewise, the router SHOULD notify the operator if any of performed. Likewise, the router SHOULD notify the operator if any of
these fail, but this notification mechanism is out of scope. 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 or rekey the certificate automatically when necessary (See renew the certificate automatically when necessary (See Section 9).
Section 9). This further reduces the tasks required of the operator. This further reduces the tasks required of the operator.
9. Key Management 9. Key Management
Key management does not only include key generation, key Key management does not only include key generation, key
provisioning, certificate issuance, and certificate distribution. It provisioning, certificate issuance, and certificate distribution. It
also includes assurance of key validity, key roll-over, and key also includes assurance of key validity, key roll-over, and key
preservation during router replacement. All of these preservation during router replacement. All of these
responsibilities persist for as long as the operator wishes to responsibilities persist for as long as the operator wishes to
operate the BGPsec-speaking router. operate the BGPsec-speaking router.
skipping to change at page 10, line 32 skipping to change at page 11, line 29
the compromised key, and then make a next generation the compromised key, and then make a next generation
soon-to-be-operational key. Hopefully, all this can be done without soon-to-be-operational key. Hopefully, all this can be done without
needing to take offline or reboot the router. For routers which needing to take offline or reboot the router. For routers which
support only one operational key, the operators should create or support only one operational key, the operators should create or
install the new private key, and then request revocation of the install the new private key, and then request revocation of the
certificate corresponding to the compromised private key. certificate corresponding to the compromised private key.
9.4. Router Replacement 9.4. Router Replacement
Currently routers often generate private keys for uses such as SSH, Currently routers often generate private keys for uses such as SSH,
and the private keys may not be seen or off-loaded from the router. and the private keys may not be seen or exported from the router.
While this is good security, it creates difficulties when a routing While this is good security, it creates difficulties when a routing
engine or whole router must be replaced in the field and all software engine or whole router must be replaced in the field and all software
which accesses the router must be updated with the new keys. Also, which accesses the router must be updated with the new keys. Also,
any network based initial contact with a new routing engine requires any network based initial contact with a new routing engine requires
trust in the public key presented on first contact. 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]), SNMP. This
lets the operator escrow the old private key via the mechanism used 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- for operator-generated keys, see Section 5.2, such that it can be re-
inserted into a replacement router. The router MAY allow the private inserted into a replacement router. The router MAY allow the private
key to be to be off-loaded via the protected channel, but this SHOULD key to be to be exported via the protected channel after key
be paired with functionality that sets the key into a permanent non- generation, but this SHOULD be paired with functionality that sets
exportable state to ensure that it is not off-loaded at a future time the newly generated key into a permanent non-exportable state to
by unauthorized operations. ensure that it is not exported at a future time by unauthorized
operations.
10. Security Considerations 10. Security Considerations
The router's manual will describe whether the router supports one, The router's manual will describe whether the router supports one,
the other, or both of the key generation options discussed in the the other, or both of the key generation options discussed in the
earlier sections of this draft as well as other important security- earlier sections of this draft as well as other important security-
related information (e.g., how to SSH to the router). After related information (e.g., how to SSH to the router). After
familiarizing one's self with the capabilities of the router, an familiarizing one's self with the capabilities of the router, an
operator is encouraged to ensure that the router is patched with the operator is encouraged to ensure that the router is patched with the
latest software updates available from the manufacturer. 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 others
skipping to change at page 11, line 41 skipping to change at page 12, line 40
all private keys MUST be protected when at rest in a secure all private keys MUST be protected when at rest in a secure
fashion. Obviously, how each router protects private keys is fashion. Obviously, how each router protects private keys is
implementation specific. Likewise, the local storage format for implementation specific. Likewise, the local storage format for
the private key is just that, a local matter. the private key is just that, a local matter.
Private key protection in transit: Mistakes here are, for all, 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; transport security is therefore strongly RECOMMENDED. The
level of security provided by the transport layer's security level of security provided by the transport layer's security
mechanism SHOULD be commensurate with 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 addresses 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
skipping to change at page 12, line 41 skipping to change at page 13, line 40
[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, <https://www.rfc-
editor.org/info/rfc4086>. 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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
10.17487/RFC4271, January 2006, <https://www.rfc-
editor.org/info/rfc4271>.
[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, DOI
10.17487/RFC5958, August 2010, <https://www.rfc- 10.17487/RFC5958, August 2010, <https://www.rfc-
editor.org/info/rfc5958>. 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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, DOI RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017, <https://www.rfc- 10.17487/RFC8174, May 2017, <https://www.rfc-
editor.org/info/rfc8174>. editor.org/info/rfc8174>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208, DOI Formats, and Signature Formats", RFC 8208, DOI
10.17487/RFC8208, September 2017, <https://www.rfc- 10.17487/RFC8208, September 2017, <https://www.rfc-
editor.org/info/rfc8208>. editor.org/info/rfc8208>.
skipping to change at page 15, line 4 skipping to change at page 15, line 49
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] National Institute of Standards and Technology (NIST),
Special Publication 800-57: Recommendation for Key Special Publication 800-57: Recommendation for Key
Management - Part 1 (Revised), March 2007. Management - Part 1 (Revised), March 2007.
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 [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57]
for information about this strength claim as well as [RFC3766] for 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 "how 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), do not use Triple DES (112 bits of security). Suggested
minimum algorithms would be AES-128: aes128-cbc [RFC4253] and minimum algorithms would be AES-128: aes128-cbc [RFC4253] and
AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or
AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256
skipping to change at page 15, line 30 skipping to change at page 16, line 28
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 commensurate with BGPsec keys; also enable a level of security commensurate with BGPsec keys;
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication. 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. The n00b Guide to BGPsec Key Management Appendix B. The n00b Guide to BGPsec Key Management
This appendix is informative. It attempts to explain all of the PKI This appendix is informative. It attempts to explain some of the PKI
technobabble in plainer language. lingo in plainer language.
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. The
signers with which we are concerned here are routers signing BGPsec signers with which we are concerned here are routers signing BGPsec
updates. Signers use private keys to sign and relying parties use updates. Signers use private keys to sign and relying parties use
the corresponding public keys, in the form of X.509 public key the corresponding public keys, in the form of X.509 public key
certificates, to verify signatures. The third party involved is the certificates, to verify signatures. The third party involved is the
entity that issues the X.509 public key certificate, the entity that issues the X.509 public key certificate, the
Certification Authority (CA). Key management is all about making Certification Authority (CA). Key management is all about making
skipping to change at page 16, line 27 skipping to change at page 17, line 25
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 uses the CLI and
accessing the router either directly via the router's craft port or accessing the router either directly via the router's craft port or
over the network on an administrative interface. If accessing the over the network on an administrative interface. If accessing the
router over the network be sure to do it securely (i.e., use SSHv2). 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 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 that will generate the key pair for the algorithms referenced in the
main body of this document; consult your router's documentation for main body of this document; consult your router's documentation for
the specific commands. The key generation process will yield the specific commands. The key generation process will yield one or
multiple files: the private key and the public key; the file format more files the private key and the public key; the file format varies
varies depending on the arcane command you issued, but generally the depending on the arcane command you issued, but generally the files
files are DER or PEM-encoded. are 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, you issue some more arcane commands while logged
into the router; using the private key just generated to sign the into the router; using the private key just generated to sign the
certification request with the algorithms referenced in the main body certification request with the algorithms referenced in the main body
of this document; the CSR is signed to prove to the CA that the 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
skipping to change at page 17, line 11 skipping to change at page 18, line 10
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 (TA) for the
root of the PKI. At this point, you no longer need access to the root of the PKI. At this point, you no longer need access to the
router for BGPsec-related initiation purposes. router 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 as well as being 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 private key by verifying the that the certificate corresponds to the pubic key contained in the
signature on the CSR sent to the CA; this is just a check to make certificate by verifying the signature on the CSR sent to the CA;
sure that the CA issued a certificate that includes a public key that this is just a check to make sure that the CA issued a certificate
is the pair of the private key (i.e., the math will work when that includes a public key that is the pair of the private key (i.e.,
verifying a signature generated by the private with the returned the math will work when verifying a signature generated by the
certificate). private 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 the 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), but no
access to the router is needed the first three steps are done on an access to the router is needed the first three steps are done on an
administrative workstation: o Step 1: Generate key pair; o Step 2: administrative workstation: o Step 1: Generate key pair; o Step 2:
Create CSR and sign CSR with private key, and; o Step 3: Send CSR Create CSR and sign CSR with private key, and; o Step 3: Send CSR
file with the subject name and serial number to CA. 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
 End of changes. 38 change blocks. 
94 lines changed or deleted 138 lines changed or added

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