--- 1/draft-ietf-sidrops-rtr-keying-00.txt 2018-12-04 07:13:28.460789845 -0800 +++ 2/draft-ietf-sidrops-rtr-keying-01.txt 2018-12-04 07:13:28.504790899 -0800 @@ -1,21 +1,21 @@ Network Working Group R. Bush Internet-Draft IIJ Lab / Dragon Research Lab Intended status: Standards Track S. Turner -Expires: March 25, 2019 sn3rd +Expires: June 7, 2019 sn3rd K. Patel Arrcus, Inc. - September 21, 2018 + December 4, 2018 Router Keying for BGPsec - draft-ietf-sidrops-rtr-keying-00 + draft-ietf-sidrops-rtr-keying-01 Abstract BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. @@ -90,49 +90,50 @@ BGPsec-speaking routers are provisioned with private keys, which allow them to digitally sign BGPsec announcements. To verify the signature, the public key, in the form of a certificate [RFC8209], is published in the Resource Public Key Infrastructure (RPKI). This document describes provisioning of BGPsec-speaking routers with the appropriate public-private key-pairs. There are two sub-methods, router-driven and operator-driven. These two sub-methods differ in where the keys are generated: on the - router in the router-driven method, and elsewhere in the operator- - driven method. Routers are required to support at least one of the - methods in order to work in various deployment environments. Some - routers may not allow the private key to be off-loaded while others - may. While off-loading private keys would ease swapping of routing - engines, exposure of private keys is a well known security risk. + router in the router-driven method, and elsewhere in the + operator-driven method. Routers are required to support at least one + of the methods in order to work in various deployment environments. + Some routers may not allow the private key to be off-loaded while + others may. While off-loading private keys would ease swapping of + routing engines, exposure of private keys is a well known security + risk. - In the operator-driven method, the operator generates the private/ - public key-pair and sends it to the router. + In the operator-driven method, the operator generates the + private/public key-pair and sends it to the router. - In the router-driven method, the router generates its own public/ - private key-pair. + In the router-driven method, the router generates its own + public/private key-pair. The router-driven model mirrors the model used by traditional PKI subscribers; the private key never leaves trusted storage (e.g., Hardware Security Module). This is by design and supports classic PKI Certification Policies for (often human) subscribers which require the private key only ever be controlled by the subscriber to ensure that no one can impersonate the subscriber. For non-humans, 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 soon-to-be offline router. This motivated the operator-driven model. The remainder of this document describes how operators can use the two methods to provision new and existing routers. The methods described involve the operator configuring the two end points (i.e., 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. Useful References: [RFC8205] describes gritty details, [RFC8209] specifies the format for the PKCS#10 certification request, and [RFC8208] specifies the algorithms used to generate the PKCS#10's signature. 2. Management / Router Communication Operators are free to use either the router-driven or operator-driven @@ -169,22 +170,22 @@ The operator also configures the Autonomous System (AS) number to be used in the generated router certificate. This may be the sole AS configured on the router, or an operator choice if the router is configured with multiple ASs. A router with multiple ASs can be configured with multiple router certificates by following the process of this document for each desired certificate. The operator configures or extracts from the router the BGP Identifier [RFC4271] to be used in the generated router certificate. - In the case where the operator has chosen not to use unique per- - router certificates, a BGP Identifier of 0 may be used. + In the case where the operator has chosen not to use unique + per-router certificates, a BGP Identifier of 0 may be used. 5. Generate PKCS#10 The private key, and hence the PKCS#10 certification request, which is sometimes referred to as a Certificate Signing Request (CSR), may be generated by the router or by the operator. The PKCS#10 request SHOULD be saved to enable verifying that the returned public key in the certificate corresponds to the private used to generate the signature on the CSR. @@ -220,21 +221,21 @@ private key into the router over the protected channel. Beware that experience has shown that copy and paste from a management station to a router can be unreliable for long texts. The operator then creates and signs the PKCS#10 certification request with the private key; the operator includes the chosen AS number and the BGP Identifier when it sends the CSR to the CA. 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 + 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 A private key can be encapsulated in a PKCS#8 Asymmetric Key Package [RFC5958] and should be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity (EE) private key. The router SHOULD verify the signature of the encapsulated PKCS#8 to @@ -291,40 +292,40 @@ key in the returned certificate. If the router did not store the PKCS#10, it can check this correspondence by generating a signature on any data and then verifying the signature using the returned certificate. The router SHOULD inform the operator whether it successfully received the certificate and whether or not the keys correspond; the mechanism is out of scope. The router SHOULD also verify that the returned certificate validates back to the installed TA Certificate, i.e., the entire chain from the installed TA Certificate through subordinate CAs to the BGPsec - certificate validate. To perform this verification the CA + certificate validate. To perform this verification, the CA certificate chain needs to be returned along with the router's certificate in the PKCS#7 certs-only message. The router SHOULD inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope. NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8, permits more advanced configurations where the entity that generates the keys is not the direct CA. 8. Advanced Deployment Scenarios More PKI-capable routers can take advantage of this increased functionality and lighten the operator's burden. Typically, these routers include either pre-installed manufacturer-generated certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed - manufacturer-generated Pre-Shared Keys (PSK) as well as PKI- - enrollment functionality and transport protocol, e.g., CMC's "Secure - Transport" [RFC7030] or the original CMC transport protocol's + manufacturer-generated Pre-Shared Keys (PSK) as well as + PKI-enrollment functionality and transport protocol, e.g., CMC's + "Secure Transport" [RFC7030] or the original CMC transport protocol's [RFC5273]. When the operator first establishes a protected channel between the management system and the router, this pre-installed key material is used to authenticate the router. The operator burden shifts here to include: 1. Securely communicating the router's authentication material to the CA prior to operator initiating the router's CSR. CAs use authentication material to determine whether the router is eligible to receive a certificate. Authentication material at a @@ -349,24 +350,24 @@ there is no need for the operator to retrieve the PKCS#10 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 the checks performed by the router in Section 7, namely extracting the certificate from the PKCS#7 certs-only message, verifying the public key corresponds to the private key, and that the returned certificate validated back to an installed trust anchor, SHOULD be performed. Likewise, the router SHOULD notify the operator if any of these fail, but this notification mechanism is out of scope. - 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 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 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. @@ -389,21 +390,21 @@ 3. The RPKI CA warns the operator of pending expiration, and/or 4. The operator uses some other kind of automated process to search for and track the expiry times of router certificates. It is advisable that expiration warnings happen well in advance of the actual expiry time. Regardless of the technique used to track router certificate expiry times, 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 organization. Depending on inter-operator relationship, it may be helpful to notify a peer operator that one or more of their certificates are about to expire. 9.2. Key Roll-Over Routers that support multiple private keys also greatly increase the @@ -412,65 +413,65 @@ expiration of the operational key. Obviously, the router needs to know when to start using the new key. Once the new key is being used, having the already distributed certificate ensures continuous operation. More information on how to proceed with a Key Roll-Over is described in [I-D.sidrops-bgpsec-rollover]. 9.3. Key Revocation - Certain unfortunate circumstances may occur causing a need to revoke - a router's BGPsec certificate. When this occurs, the operator needs - to use the RPKI CA system to revoke the certificate by placing the - router's BGPsec certificate on the Certificate Revocation List (CRL) - as well as re-keying the router's certificate. + In certain circumstances, a router's BGPsec certificate may need to + be revoked. When this occurs, the operator needs to use the RPKI CA + system to revoke the certificate by placing the router's BGPsec + certificate on the Certificate Revocation List (CRL) as well as + re-keying the router's certificate. 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 router's certificate, and then the process of re-keying/renewing the 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 continuity of operations, with or without the compromised private key, or whether they wish to bring the router offline to address the compromise. - Keeping the router operational and BGPsec-speaking is the ideal goal, - but if operational practices do not allow this then reconfiguring the - router to disable BGPsec is likely preferred to bringing the router - offline. + Keeping the router operational and BGPsec-speaking is the ideal goal; + but, if operational practices do not allow this, then reconfiguring + the router to disable BGPsec is likely preferred to bringing the + router offline. Routers which support more than one private key, where one is operational and other(s) are soon-to-be-operational, facilitate revocation events because the operator can configure the router to make a soon-to-be-operational key operational, request revocation of - the compromised key, and then make a next generation soon-to-be- - operational key, all hopefully without needing to take offline or - reboot the router. For routers which support only one operational - key, the operators should create or install the new private key, and - then request revocation of the certificate corresponding to the - compromised private key. + the compromised key, and then make a next generation + soon-to-be-operational key. Hopefully, all this can be done without + needing to take offline or reboot the router. For routers which + support only one operational key, the operators should create or + install the new private key, and then request revocation of the + certificate corresponding to the compromised private key. 9.4. Router Replacement 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. While this is good security, it creates difficulties when a routing 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, any network based initial contact with a new routing engine requires trust in the public key presented on first contact. To allow operators to quickly replace routers without requiring 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 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- 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 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 by unauthorized operations. 10. Security Considerations @@ -467,54 +468,53 @@ protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This 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- 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 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 by unauthorized operations. 10. Security Considerations - The router's manual will describe whether the router supports one, the other, or both of the key generation options discussed in the earlier sections of this draft as well as other important security- related information (e.g., how to SSH to the router). After familiarizing one's self with the capabilities of the router, an operator is encouraged to ensure that the router is patched with the latest software updates available from the manufacturer. - This document defines no protocols so in some sense introduces no new - security considerations. However, it relies on many others and the - security considerations in the referenced documents should be + This document defines no protocols. So, in some sense, it introduces + no new security considerations. However, it relies on many others + and the security considerations in the referenced documents should be consulted; notably, those document listed in Section 1 should be consulted first. PKI-relying protocols, of which BGPsec is one, have - many issues to consider so many in fact entire books have been + many issues to consider - so many, in fact, entire books have been written to address them; so listing all PKI-related security - considerations is neither useful nor helpful; regardless, some boot- + considerations is neither useful nor helpful. Regardless, some boot- 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 of a difficult to generate public-private key pair with a signer; all key pairs MUST be generated from a good source of non- deterministic random input [RFC4086]. - 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 another entity to masquerade as (i.e., impersonate) the signer; all private keys MUST be protected when at rest in a secure fashion. Obviously, how each router protects private keys is implementation specific. Likewise, the local storage format for the private key is just that, a local matter. - 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 key allows another entity to masquerade as (i.e., impersonate) the signer; transport security is therefore strongly RECOMMENDED. The level of security provided by the transport layer's security mechanism SHOULD be commensurate with the strength of the BGPsec key; there's no point in spending time and energy to generate an excellent public-private key pair and then transmit the private key in the clear or with a known-to-be-broken algorithm, as it just undermines trust that the private key has been kept private. Additionally, operators SHOULD ensure the transport security