draft-ietf-sidrops-rtr-keying-00.txt   draft-ietf-sidrops-rtr-keying-01.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: March 25, 2019 sn3rd Expires: June 7, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
September 21, 2018 December 4, 2018
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-00 draft-ietf-sidrops-rtr-keying-01
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 3, line 10 skipping to change at page 3, line 10
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 sub-methods, appropriate public-private key-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
driven method. Routers are required to support at least one of the operator-driven method. Routers are required to support at least one
methods in order to work in various deployment environments. Some of the methods in order to work in various deployment environments.
routers may not allow the private key to be off-loaded while others Some routers may not allow the private key to be off-loaded while
may. While off-loading private keys would ease swapping of routing others may. While off-loading private keys would ease swapping of
engines, exposure of private keys is a well known security risk. routing 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
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 public/ In the router-driven method, the router generates its own
private key-pair. public/private key-pair.
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 (i.e., described involve the operator configuring the two end points (i.e.,
the management station and the router) and acting as the the management station and the router) and acting as the
intermediary. Section 7 describes a method that requires more intermediary. Section 8 describes a method that requires more
capable routers. capable routers.
Useful References: [RFC8205] describes gritty details, [RFC8209] Useful References: [RFC8205] describes gritty details, [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's
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
skipping to change at page 4, line 41 skipping to change at page 4, line 42
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. 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.
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 [RFC4271] to be used in the generated router certificate.
In the case where the operator has chosen not to use unique per- In the case where the operator has chosen not to use unique
router certificates, a BGP Identifier of 0 may be used. per-router certificates, a BGP Identifier of 0 may be used.
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 The PKCS#10 request SHOULD be saved to enable verifying that the
returned public key in the certificate corresponds to the private returned public key in the certificate corresponds to the private
used to generate the signature on the CSR. used to generate the signature on the CSR.
skipping to change at page 5, line 44 skipping to change at page 5, line 45
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, Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a this signature still provides a linkage between a private key and a
router. That is the operator can verify the proof of possession router. That is, the operator can verify the proof of possession
(POP), as required by [RFC6484]. (POP), as required by [RFC6484].
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 AS's End Entity Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity
(EE) private key. (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
skipping to change at page 7, line 19 skipping to change at page 7, line 20
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
certificate. The router SHOULD inform the operator whether it certificate. The router SHOULD inform the operator whether it
successfully received the certificate and whether or not the keys successfully received the certificate and whether or not the keys
correspond; the mechanism is out of scope. correspond; the mechanism 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 certs-only message. The router SHOULD certificate in the PKCS#7 certs-only message. The router SHOULD
inform the operator whether or not the signature validates to a trust inform the operator whether or not the signature validates to a trust
anchor; this notification mechanism is out of scope. anchor; this notification mechanism is out of scope.
NOTE: The signature on the PKCS#8 and Certificate need not be made by NOTE: The signature on the PKCS#8 and Certificate need not be made by
the same entity. Signing the PKCS#8, permits more advanced the same entity. Signing the PKCS#8, permits more advanced
configurations where the entity that generates the keys is not the configurations where the entity that generates the keys is not the
direct CA. direct CA.
8. Advanced Deployment Scenarios 8. 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
enrollment functionality and transport protocol, e.g., CMC's "Secure PKI-enrollment functionality and transport protocol, e.g., CMC's
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.
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 router'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
skipping to change at page 8, line 28 skipping to change at page 8, line 30
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 or rekey the certificate automatically when necessary (See
Section 8). This further reduces the tasks required of the operator. Section 9). 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 9, line 21 skipping to change at page 9, line 23
3. The RPKI CA warns the operator of pending expiration, and/or 3. The RPKI CA warns the operator of pending expiration, and/or
4. The operator uses some other kind of automated process to search 4. The operator uses some other kind of automated process to search
for and track the expiry times of router certificates. for and track the expiry times of router certificates.
It is advisable that expiration warnings happen well in advance of It is advisable that expiration warnings happen well in advance of
the actual expiry time. the actual expiry time.
Regardless of the technique used to track router certificate expiry Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same times, 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.
9.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
skipping to change at page 9, line 44 skipping to change at page 9, line 46
expiration of the operational key. Obviously, the router needs to expiration of the operational key. Obviously, the router needs to
know when to start using the new key. Once the new key is being know when to start using the new key. Once the new key is being
used, having the already distributed certificate ensures continuous used, having the already distributed certificate ensures continuous
operation. operation.
More information on how to proceed with a Key Roll-Over is described More information on how to proceed with a Key Roll-Over is described
in [I-D.sidrops-bgpsec-rollover]. in [I-D.sidrops-bgpsec-rollover].
9.3. Key Revocation 9.3. Key Revocation
Certain unfortunate circumstances may occur causing a need to revoke In certain circumstances, a router's BGPsec certificate may need to
a router's BGPsec certificate. When this occurs, the operator needs be revoked. When this occurs, the operator needs to use the RPKI CA
to use the RPKI CA system to revoke the certificate by placing the system to revoke the certificate by placing the router's BGPsec
router's BGPsec certificate on the Certificate Revocation List (CRL) certificate on the Certificate Revocation List (CRL) as well as
as well as re-keying the router's certificate. 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
router's certificate, (possibly distributing a new key and router's certificate, (possibly distributing a new key and
certificate to the router), and distributing the status takes time certificate to the router), and distributing the status, takes time
during which the operator must decide how they wish to maintain during which the operator must decide how they wish to maintain
continuity of operations, with or without the compromised private continuity of operations, with or without the compromised private
key, or whether they wish to bring the router offline to address the key, or whether they wish to bring the router offline to address the
compromise. compromise.
Keeping the router operational and BGPsec-speaking is the ideal goal, Keeping the router operational and BGPsec-speaking is the ideal goal;
but if operational practices do not allow this then reconfiguring the but, if operational practices do not allow this, then reconfiguring
router to disable BGPsec is likely preferred to bringing the router the router to disable BGPsec is likely preferred to bringing the
offline. router 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
operational key, all hopefully without needing to take offline or soon-to-be-operational key. Hopefully, all this can be done without
reboot the router. For routers which support only one operational needing to take offline or reboot the router. For routers which
key, the operators should create or install the new private key, and support only one operational key, the operators should create or
then request revocation of the certificate corresponding to the install the new private key, and then request revocation of 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 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 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 off-loaded via the protected channel, 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.
10. Security Considerations 10. Security Considerations
skipping to change at page 10, line 50 skipping to change at page 11, line 4
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 off-loaded via the protected channel, 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.
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 introduces no new This document defines no protocols. So, in some sense, it introduces
security considerations. However, it relies on many others and the no new security considerations. However, it relies on many others
security considerations in the referenced documents should be and the security considerations in the referenced documents should be
consulted; notably, those document listed in Section 1 should be consulted; notably, those document listed in Section 1 should be
consulted first. PKI-relying protocols, of which BGPsec is one, have consulted first. PKI-relying protocols, of which BGPsec is one, have
many issues to consider so many in fact entire books have been many issues to consider - so many, in fact, entire books have been
written to address them; so listing all PKI-related security written to address them; so listing all PKI-related security
considerations is neither useful nor helpful; regardless, some boot- considerations is neither useful nor helpful. Regardless, some boot-
strapping-related issues are listed here that are worth repeating: strapping-related issues are listed here that are worth repeating:
Public-Private key pair generation: Mistakes here are for all Public-Private key pair generation: Mistakes here are, for all,
practical purposes catastrophic because PKIs rely on the pairing practical purposes catastrophic because PKIs rely on the pairing
of a difficult to generate public-private key pair with a signer; of a difficult to generate public-private key pair with a signer;
all key pairs MUST be generated from a good source of non- all key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086]. deterministic random input [RFC4086].
Private key protection at rest: Mistakes here are for all practical Private key protection at rest: Mistakes here are, for all, practical
purposes catastrophic because disclosure of the private key allows purposes catastrophic because disclosure of the private key allows
another entity to masquerade as (i.e., impersonate) the signer; another entity to masquerade as (i.e., impersonate) the signer;
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 commensurate with 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
 End of changes. 27 change blocks. 
51 lines changed or deleted 51 lines changed or added

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