draft-ietf-sidr-rtr-keying-13.txt   draft-ietf-sidr-rtr-keying-14.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: Standards Track S. Turner Intended status: Standards Track S. Turner
Expires: October 7, 2017 sn3rd Expires: April 23, 2018 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
April 5, 2017 October 20, 2017
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-13 draft-ietf-sidr-rtr-keying-14
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 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . 3
3. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 4 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. PKCS#10 Generation . . . . . . . . . . . . . . . . . . . . . . 4 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 4 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 4
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5
6. Installing Certified Keys . . . . . . . . . . . . . . . . . . 5 5.2.1. Using PKCS#8 to Transfer Public Key . . . . . . . . . 5
7. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 6 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 5
8. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6
8.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7
8.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 8 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8
8.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 9 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11.1. Informative References . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.1. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Management/Router Channel Security . . . . . . . . . 14 Appendix A. Management/Router Channel Security . . . . . . . . . 14
Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 14 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 [I-D.ietf- signature, the public key, in the form of a certificate [RFC8209], is
sidr-bgpsec-pki-profiles], is published in the Resource Public Key published in the Resource Public Key Infrastructure (RPKI). This
Infrastructure (RPKI). This document describes provisioning of document describes provisioning of BGPsec-speaking routers with the
BGPsec-speaking routers with the appropriate public-private key- appropriate public-private key-pairs. There are two sub-methods,
pairs. There are two sub-methods, router-driven and operator-driven. router-driven and operator-driven.
These two sub-methods differ in where the keys are generated: on the These two sub-methods differ in where the keys are generated: on the
router in the router-driven method, and elsewhere in the operator- router in the router-driven method, and elsewhere in the operator-
driven method. Routers are required to support at least one of the driven method. Routers are required to support at least one of the
methods in order to work in various deployment environments. Some methods in order to work in various deployment environments. Some
routers may not allow the private key to be off-loaded while others routers may not allow the private key to be off-loaded while others
may. While off-loading private keys would ease swapping of routing may. While off-loading private keys would ease swapping of routing
engines, exposure of private keys is a well known security risk. engines, exposure of private keys is a well known security risk.
In the operator-driven method, the operator generates the private/ In the operator-driven method, the operator generates the private/
public key-pair and sends it to the router, perhaps in a PKCS#8 public key-pair and sends it to the router.
package [RFC5958].
In the router-driven method, the router generates its own public/ In the router-driven method, the router generates its own public/
private key-pair, uses the private key to sign a PKCS#10 private key-pair.
certification request [I-D.ietf-sidr-bgpsec-pki-profiles], which
includes the public key), and returns the certification request to
the operator to be forwarded to the RPKI Certification Authority
(CA). The CA returns a PKCS#7, which includes the certified public
key in the form of a certificate, to the operator for loading into
the router; and the CA also publishes the certificate in the RPKI.
The router-driven model mirrors the model used by traditional PKI The router-driven model 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 model does not always work. For example, when an operator wants this model does not always work. For example, when an operator wants
to support hot-swappable routers the same private key needs to be 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 the installed in the soon-to-be online router that was used by the the
soon-to-be offline router. This motivated the operator-driven model. soon-to-be offline router. This motivated the operator-driven model.
The remainder of this document describes how operators can use the The remainder of this document describes how operators can use the
two methods to provision new and existing routers. The methods two methods to provision new and existing routers. The methods
described involve the operator configuring the two end points and described involve the operator configuring the two end points and
acting as the intermediary. Section 7 describes a method that acting as the intermediary. Section 7 describes a method that
requires more capable routers. requires more capable routers.
Useful References: [I-D.ietf-sidr-bgpsec-protocol] describes gritty Useful References: [RFC8205] describes gritty details, [RFC8209]
details, [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for specifies the format for the PKCS #10 request, and [RFC8208]
the PKCS #10 request, and [I-D.ietf-sidr-bgpsec-algs] specifies the specifies the algorithms used to generate the signature.
algorithms used to generate the 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. Regardless of the method
chosen, operators first establish a secure communication channel chosen, operators first establish a secure communication channel
between the management system and the router. How this channel is between the management system and the router. How this 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]); for simplicity, in this document, the communication (see [RFC6470]); for simplicity, in this document, the communication
channel between the management platform and the router is assumed to channel between the management platform and the router is assumed to
be an SSH-protected CLI. See Appendix A for security considerations be an SSH-protected CLI. See Appendix A for security considerations
for this channel. for this channel.
skipping to change at page 4, line 15 skipping to change at page 4, line 9
method as supported by the platform. Regardless of the method method as supported by the platform. Regardless of the method
chosen, operators first establish a secure communication channel chosen, operators first establish a secure communication channel
between the management system and the router. How this channel is between the management system and the router. How this 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]); for simplicity, in this document, the communication (see [RFC6470]); for simplicity, in this document, the communication
channel between the management platform and the router is assumed to channel between the management platform and the router is assumed to
be an SSH-protected CLI. See Appendix A for security considerations be an SSH-protected CLI. See Appendix A for security considerations
for this channel. for this channel.
3. Exchanging Certificates 3. Exchange Certificates
The operator management station can exchange certificate requests and A number of options exist for the operator management station to
certificates with routers and with the RPKI CA infrastructure using exchange PKI-related information with routers and with the RPKI
the application/pkcs10 media type [RFC5967] and application/ including:
pkcs7-mime [RFC5751], respectively, and may use FTP or HTTP per
[RFC2585], or the Enrollment over Secure Transport (EST) [RFC7030]. - Use application/pkcs10 media type [RFC5967] to extract certificate
requests and application/pkcs7-mime [RFC5751] to return the issued
certificate,
- Use FTP or HTTP per [RFC2585], and
- Use Enrollment over Secure Transport (EST) protocol per [RFC7030].
4. Set-Up 4. Set-Up
To start, the operator uses the communication channel to install the To start, the operator uses the communication channel to install the
appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. appropriate RPKI Trust Anchor' 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. returned in the PKCS#7.
The operator also configures the Autonomous System (AS) number to be The operator also configures the Autonomous System (AS) number to be
used in the generated router certificate. This may be the sole AS used in the generated router certificate. This may be the sole AS
configured on the router, or an operator choice if the router is configured on the router, or an operator choice if the router is
configured with multiple ASs. configured with multiple ASs.
The operator configures or extracts from the router the BGP RouterID The operator configures or extracts from the router the BGP RouterID
to be used in the generated certificate. In the case where the to be used in the generated certificate. In the case where the
operator has chosen not to use unique per-router certificates, a operator has chosen not to use unique per-router certificates, a
RouterID of 0 may be used. RouterID of 0 may be used.
5. PKCS#10 Generation 5. Generate PKCS#10
The private key, and hence the PKCS#10 request, which is sometimes The private key, and hence the PKCS#10 request, which is sometimes
referred to as a Certificate Signing Request (CSR), may be generated referred to as a Certificate Signing Request (CSR), may be generated
by the router or by the operator. by the router or by the operator.
5.1. Router-Generated Keys 5.1. Router-Generated Keys
In the router-generated method, once the protected session is In the router-generated method, once the protected session 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 request, and to sign public/private key pair, to generate the PKCS#10 request, and to sign
the PKCS#10 with the private key. Once generated, the PKCS#10 is the PKCS#10 with the private key. Once generated, the PKCS#10 is
returned to the operator over the protected channel. returned to the operator over the protected channel.
If a router was to communicate directly with a CA to have the CA
certify the PKCS#10, there would be no way for the CA to authenticate
the router. As the operator knows the authenticity of the router,
the operator mediates the communication with the CA.
The operator adds the chosen AS number and the RouterID to send to The operator adds the chosen AS number and the RouterID to send to
the RPKI CA for the CA to certify. the RPKI CA for the CA to certify.
NOTE: If a router was to communicate directly with a CA to have the
CA certify the PKCS#10, there would be no way for the CA to
authenticate the router. As the operator knows the authenticity of
the router, the operator mediates the communication with the CA.
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.
Alternatively, the private key may be encapsulated in a PKCS #8 The operator then creates and signs the PKCS#10 with the private key,
[RFC5958], the PKCS#8 is further encapsulated in Cryptographic and adds the chosen AS number and RouterID to be sent to the RPKI CA
Message Syntax (CMS) SignedData [RFC5652], and signed by the AS's End for the CA to certify.
Entity (EE) certificate.
5.2.1. Using PKCS#8 to Transfer Public Key
A private key encapsulated in a PKCS #8 [RFC5958] should be further
encapsulated in Cryptographic Message Syntax (CMS) SignedData
[RFC5652] and signed with the AS's End 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 AS's include in the SignedData the RPKI CA certificate and relevant AS's
EE certificate(s). The router should inform the operator whether or EE certificate(s). The router should inform the operator whether or
not the signature validates to a trust anchor; this notification not the signature validates to a trust anchor; this notification
mechanism is out of scope. mechanism is out of scope.
The operator then creates and signs the PKCS#10 with the private key, 6. Send PKCS#10 and Receive PKCS#7
and adds the chosen AS number and RouterID to be sent to the RPKI CA
for the CA to certify.
6. Installing Certified Keys
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
request, sign the key in the PKCS#10 (i.e., certify it) and generated request, sign the key in the PKCS#10 (i.e., certify it) and generated
PKCS#7 response, as well as publishing the certificate in the Global PKCS#7 response, as well as publishing the certificate in the Global
RPKI. External network connectivity may be needed if the certificate RPKI. External network connectivity may be needed if the certificate
is to be published in the Global RPKI. 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:
skipping to change at page 6, line 21 skipping to change at page 6, line 23
certificate chain below the TA Certificate so that the router can certificate chain below the TA Certificate so that the router can
validate the router certificate. 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, and verify that the private key it holds certificate from the PKCS#7, and verify that the private key it holds
corresponds to the returned public key. corresponds to the returned public key.
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
The operator provisions the PKCS#7 into the router over the secure The operator provisions the PKCS#7 into the router over the secure
channel. channel.
The router SHOULD extract the certificate from the PKCS#7 and verify The router SHOULD extract the certificate from the PKCS#7 and verify
that the private key corresponds to the returned public key. The that the public key corresponds to the stored private key. The
router SHOULD inform the operator whether it successfully received router SHOULD inform the operator whether it successfully received
the certificate and whether or not the keys correspond; the mechanism the certificate and whether or not the keys correspond; the mechanism
is out of scope. is out of scope.
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. The router SHOULD inform the operator certificate in the PKCS#7. 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.
Note: The signature on the PKCS#8 and Certificate need not be made by 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].
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.
Even if the operator cannot extract the private key from the router, 8. Advanced Deployment Scenarios
this signature still provides a linkage between a private key and a
router. That is the server can verify the proof of possession (POP),
as required by [RFC6484].
7. Advanced Deployment Scenarios
More PKI-capable routers can take advantage of this increased More PKI-capable routers can take advantage of this 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 PKI- manufacturer-generated Pre-Shared Keys (PSK) as well as PKI-
enrollment functionality and transport protocol, e.g., CMC's "Secure enrollment functionality and transport protocol, e.g., CMC's "Secure
Transport" [RFC7030] or the original CMC transport protocol's Transport" [RFC7030] or the original CMC transport protocol's
[RFC5273]. When the operator first establishes a secure [RFC5273]. When the operator first establishes a secure
communication channel between the management system and the router, communication channel between the management system and the router,
this pre-installed key material is used to authenticate the router. this pre-installed key material is used to authenticate the router.
The operator burden shifts here to include: The operator 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 server's CSR. CAs use the CA prior to operator initiating the router's CSR. CAs use
authentication material to determine whether the router is authentication material to determine whether the router is
eligible to receive a certificate. Authentication material at a eligible to receive a certificate. Authentication material at a
minimum includes the router's AS number and RouterID as well as minimum includes the router's AS number and RouterID as well as
the router's key material, but can also include additional the router's key material, but can also include additional
information. Authentication material can can be communicated to information. Authentication material can be communicated to the
the CA (i.e., CSRs signed by this key material are issued CA (i.e., CSRs signed by this key material are issued
certificates with this AS and RouterID) or to the router (i.e., certificates with this AS and RouterID) or to the router (i.e.,
the operator uses the vendor-supplied management interface to the operator uses the vendor-supplied management interface to
include the AS number and routerID in the router-generated CSR). include the AS number and routerID 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 MAY
require connections to external networks (i.e., through require connections to external networks (i.e., through
firewalls, NATs, etc.). firewalls, NATs, etc.).
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 from the there is no need for the operator to retrieve the PKCS#10 from the
router or return the PKCS#7 to the router as in Section 6. Note that router or return the PKCS#7 to the router as in Section 6. Note that
the checks performed by the router, namely extracting the certificate the checks performed by the router, namely extracting the certificate
from the PKCS#7, verifying the private key corresponds to the from the PKCS#7, verifying the public key corresponds to the private
returned public key, and that the returned certificate validated back key, and that the returned certificate validated back to an installed
to an installed trust anchor, SHOULD be performed. Likewise, the trust anchor, SHOULD be performed. Likewise, the router SHOULD
router SHOULD notify the operator if any of these fail, but this notify the operator if any of these fail, but this notification
notification mechanism is out of scope. 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 or rekey the certificate automatically when necessary (See
Section 8). This further reduces the tasks required of the operator. Section 8). This further reduces the tasks required of the operator.
8. Key Management 9. Key Management
An operator's responsibilities do not end after key generation, key
provisioning, certificate issuance, and certificate distribution.
They persist for as long as the operator wishes to operate the
BGPsec-speaking router.
8.1. Key Validity Key management does not only include key generation, key
provisioning, certificate issuance, and certificate distribution. It
also includes assurance of key validity, key roll-over, and key
preservation during router replacement. All of these
responsibilities persist for as long as the operator wishes to
operate the BGPsec-speaking router.
It is critical that a BGPsec speaking router ensures that it is 9.1. Key Validity
signing with a valid private key at all times. To this end, the
operator needs to ensure the router always has a non-expired It is critical that a BGPsec speaking router is signing with a valid
certificate. I.e. the key used to sign BGPsec announcements always private key at all times. To this end, the operator needs to ensure
has an associated certificate whose expiry time is after the current the router always has a non-expired certificate. I.e. the key used
time. to sign BGPsec announcements always has an associated 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 has 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 notes 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 warns the operator of pending expiration, and/or 3. The RPKI CA warns the operator of pending expiration, and/or
skipping to change at page 8, line 44 skipping to change at page 8, line 49
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, it is advisable to notify additional operators in the same
organization as the expiry time approaches thereby ensuring that the organization 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 relationship, it may be helpful to notify
a peer operator that one or more of their certificates are about to a peer operator that one or more of their certificates are about to
expire. expire.
8.2. Key Roll-Over 9.2. Key Roll-Over
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.
Whether the certificate is re-keyed (i.e., different key in the More information on how to proceed with a Key Roll-Over is described
certificate with a new expiry time) or renewed (i.e., the same key in in [I-D.sidrops-bgpsec-rollover].
the certificate with a new expiry time) depends on the key's lifetime
and operational use. Arguably, re-keying the router's BGPsec
certificate every time the certificate expires is more secure than
renewal because it limits the private key's exposure. However, if
the key is not compromised the certificate could be renewed as many
times as allowed by the operator's security policy. Routers that
support only one key can use renewal to ensure continuous operation,
assuming the certificate is renewed and distributed well in advance
of the operational certificate's expiry time.
7.3. Key Revocation 9.3. Key Revocation
Certain unfortunate circumstances may occur causing a need to revoke Certain unfortunate circumstances may occur causing a need to revoke
a router's BGPsec certificate. When this occurs, the operator needs a router's BGPsec certificate. When this occurs, the operator needs
to use the RPKI CA system to revoke the certificate by placing the to use the RPKI CA system to revoke the certificate by placing the
router's BGPsec certificate on the Certificate Revocation List (CRL) router's BGPsec certificate on the Certificate Revocation List (CRL)
as well as re-keying the router's certificate. as well as re-keying the router's certificate.
When an active router key is to be revoked, the process of requesting When an active router key is to be revoked, the process of requesting
the CA to revoke, the process of the CA actually revoking the the CA to revoke, the process of the CA actually revoking the
router's certificate, and then the process of re-keying/renewing the router's certificate, and then the process of re-keying/renewing the
skipping to change at page 9, line 49 skipping to change at page 9, line 45
offline. offline.
Routers which support more than one private key, where one is Routers which 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 soon-to-be- the compromised key, and then make a next generation soon-to-be-
operational key, all hopefully without needing to take offline or operational key, all hopefully without needing to take offline or
reboot the router. For routers which support only one operational reboot the router. For routers which support only one operational
key, the operators should create or install the new private key, and key, the operators should create or install the new private key, and
then request revocation of the compromised private key. then request revocation of the certificate corresponding to the
compromised private key.
9.4. Router Replacement
8.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 off-loaded 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 inserted via a routers SHOULD allow the private BGPsec key to inserted via a
protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This
skipping to change at page 10, line 24 skipping to change at page 10, line 23
routers SHOULD allow the private BGPsec key to inserted via a routers SHOULD allow the private BGPsec key to inserted via a
protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This protected session, 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 session, but this SHOULD key to be to be off-loaded via the protected session, but this SHOULD
be paired with functionality that sets the key into a permanent non- be paired with functionality that sets the key into a permanent non-
exportable state to ensure that it is not off-loaded at a future time exportable state to ensure that it is not off-loaded at a future time
by unauthorized operations. by unauthorized operations.
9. 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, familiarizing one's self with the capabilities of the router,
operators are encouraged to ensure that the router is patched with operators are encouraged to ensure that the router is patched with
the latest software updates available from the manufacturer. the latest software updates available from the manufacturer.
This document defines no protocols so in some sense introduces no new This document defines no protocols so in some sense introduces no new
skipping to change at page 11, line 35 skipping to change at page 11, line 33
[I-D.ylonen-sshkeybcp]; employees that no longer need access to [I-D.ylonen-sshkeybcp]; employees that no longer need access to
routers SHOULD be removed the router to ensure only those authorized routers SHOULD be removed the router to ensure only those authorized
have access to a router. have access to a router.
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 installed CA certificate is valid. operator MUST ensure that installed CA certificate is valid.
10. IANA Considerations 11. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
11. References 12. References
11.1. Normative References
[I-D.ietf-sidr-bgpsec-algs] 12.1. Normative References
Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs (work in
progress), March 2013.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.sidrops-bgpsec-rollover]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Weis, B, R. Gagliano, and K. Patel, "BGPsec Router
BGPSEC Router Certificates, Certificate Revocation Lists, Certificate Rollover", draft-ietf-sidrops-bgpsec-
and Certification Requests", draft-ietf-sidr-bgpsec-pki- rollover (work in progress), October 2017.
profiles (work in progress), October 2012.
[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, DOI
10.17487/RFC2119, March 1997, <http://www.rfc- 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. 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, <http://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, <http://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,
<http://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, <http://www.rfc- 10.17487/RFC5958, August 2010, <https://www.rfc-
editor.org/info/rfc5958>. editor.org/info/rfc5958>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208, DOI
10.17487/RFC8208, September 2017, <https://www.rfc-
editor.org/info/rfc8208>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209, DOI
10.17487/RFC8209, September 2017, <https://www.rfc-
editor.org/info/rfc8209>.
[802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
2009.html>. 2009.html>.
11.1. Informative References 12.1. Informative References
[I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", draft-ietf-
sidr-bgpsec-protocol (work in progress), February 2013.
[I-D.ylonen-sshkeybcp] [I-D.ylonen-sshkeybcp]
Ylonen, T. and G. Kent, "Managing SSH Keys for Automated Ylonen, T. and G. Kent, "Managing SSH Keys for Automated
Access - Current Recommended Practice", draft-ylonen- Access - Current Recommended Practice", draft-ylonen-
sshkeybcp (work in progress), April 2013. sshkeybcp (work in progress), April 2013.
[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, <http://www.rfc- RFC 2585, DOI 10.17487/RFC2585, May 1999,
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,
<http://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, DOI
10.17487/RFC5273, June 2008, <http://www.rfc- 10.17487/RFC5273, June 2008, <https://www.rfc-
editor.org/info/rfc5273>. 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,
<http://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, DOI
10.17487/RFC5647, August 2009, <http://www.rfc- 10.17487/RFC5647, August 2009, <https://www.rfc-
editor.org/info/rfc5647>. 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,
<http://www.rfc-editor.org/info/rfc5656>. <https://www.rfc-editor.org/info/rfc5656>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[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, <http://www.rfc- DOI 10.17487/RFC5967, August 2010, <https://www.rfc-
editor.org/info/rfc5967>. 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, <http://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, <http://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, <http://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,
<http://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, DOI
10.17487/RFC7030, October 2013, <http://www.rfc- 10.17487/RFC7030, October 2013, <https://www.rfc-
editor.org/info/rfc7030>. editor.org/info/rfc7030>.
[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[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 secure communication channel SHOULD be of equal or used by the secure communication channel SHOULD be of equal or
greater strength than the BGPsec keys they protect, which for the greater strength than the BGPsec keys they protect, which for the
algorithm specified in [I-D.ietf-sidr-bgpsec-algs] is 128-bit; see algorithm specified in [RFC8208] is 128-bit; see [RFC5480] and by
[RFC5480] and by reference [SP800-57] for information about this reference [SP800-57] for information about this strength claim as
strength claim as well as [RFC3766] for "how to determine the length well as [RFC3766] for "how to determine the length of an asymmetric
of an asymmetric key as a function of a symmetric key strength key as a function of a symmetric key strength requirement." In other
requirement." In other words, for the encryption algorithm, do not words, for the encryption algorithm, do not use export grade crypto
use export grade crypto (40-56 bits of security), do not use Triple (40-56 bits of security), do not use Triple DES (112 bits of
DES (112 bits of security). Suggested minimum algorithms would be security). Suggested minimum algorithms would be AES-128: aes128-cbc
AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for [RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-
encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] 256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-
for integrity, ecdsa-sha2-nistp256 [RFC5656] for authentication, and sha2-nistp256 [RFC5656] for authentication, and ecdh-sha2-nistp256
ecdh-sha2-nistp256 [RFC5656] for key exchange. [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 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.
Appendix B. The n00b Guide to BGPsec Key Management Appendix B. The n00b Guide to BGPsec Key Management
 End of changes. 61 change blocks. 
148 lines changed or deleted 153 lines changed or added

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