--- 1/draft-ietf-sidrops-rtr-keying-01.txt 2018-12-18 16:19:25.975609235 -0800 +++ 2/draft-ietf-sidrops-rtr-keying-02.txt 2018-12-18 16:19:26.163613826 -0800 @@ -1,21 +1,21 @@ Network Working Group R. Bush Internet-Draft IIJ Lab / Dragon Research Lab Intended status: Standards Track S. Turner -Expires: June 7, 2019 sn3rd +Expires: June 21, 2019 sn3rd K. Patel Arrcus, Inc. - December 4, 2018 + December 18, 2018 Router Keying for BGPsec - draft-ietf-sidrops-rtr-keying-01 + draft-ietf-sidrops-rtr-keying-02 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. @@ -75,35 +75,35 @@ 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Informative References . . . . . . . . . . . . . . . . . 13 - Appendix A. Management/Router Channel Security . . . . . . . . . 15 + Appendix A. Management/Router Channel Security . . . . . . . . . 14 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction 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. + appropriate public-private key-pairs. There are two methods, router- + driven and operator-driven. - These two sub-methods differ in where the keys are generated: on the + These two methods differ in where the keys are generated: on the router in the router-driven method, and elsewhere in the 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. @@ -115,26 +115,26 @@ 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 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 8 describes a method that requires more - capable routers. + Sections 2 through 7 describe the various steps involved for an + operator to 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 8 describes another 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 method as supported by the platform. Regardless of the method @@ -171,35 +171,35 @@ 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. + 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. NOTE: The PKCS#10 certification request does not include the AS number or the BGP Identifier for the router certificate. Therefore, - the operator transmits the AS it has chosen or the router and the BGP + the operator transmits the AS it has chosen on the router and the BGP Identifier as well when it sends the CSR to the CA. 5.1. Router-Generated Keys In the router-generated method, once the protected channel is established and the initial Set-Up (Section 4) performed, the operator issues a command or commands for the router to generate the public/private key pair, to generate the PKCS#10 certification request, and to sign the PKCS#10 certification request with the private key. Once generated, the PKCS#10 certification request is @@ -228,30 +228,30 @@ Even if the operator cannot extract the private key from the router, this signature still provides a linkage between a private key and a router. That is, the operator can verify the proof of possession (POP), as required by [RFC6484]. 5.2.1. Using PKCS#8 to Transfer Private Key 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. + Syntax (CMS) SignedData [RFC5652] and signed with the operators's End + Entity (EE) private key. The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key did in fact come from the operator, but this requires that the operator also provision via the CLI or - include in the SignedData the RPKI CA certificate and relevant AS's - EE certificate(s). The router should inform the operator whether or - not the signature validates to a trust anchor; this notification - mechanism is out of scope. + include in the SignedData the RPKI CA certificate and relevant + operator's EE certificate(s). The router should inform the operator + whether or not the signature validates to a trust anchor; this + notification mechanism is out of scope. 6. Send PKCS#10 and Receive PKCS#7 The operator uses RPKI management tools to communicate with the global RPKI system to have the appropriate CA validate the PKCS#10 certification request, sign the key in the PKCS#10 (i.e., certify it) and generate a PKCS#7 certs-only message, as well as publishing the certificate in the Global RPKI. External network connectivity may be needed if the certificate is to be published in the Global RPKI. @@ -278,21 +278,21 @@ verifying the signature using the returned certificate. In the operator-generated method, the operator has already installed the private key in the router (see Section 5.2). 7. Install Certificate The operator provisions the PKCS#7 certs-only message into the router over the protected channel. - The router SHOULD extract the certificate from the PKCS#7 certs-ony + The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. If the router stored the PKCS#10, it can check this correspondence by comparing the public key in the CSR to the public 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. @@ -514,25 +514,20 @@ 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 mechanism is up to date, in order to addresses all known implementation bugs. - SSH key management is known, in some cases, to be lax - [I-D.ylonen-sshkeybcp]; employees that no longer need access to a - routers SHOULD be removed the router to ensure only those authorized - have access to a router. - 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 revocation status of the CA's certificate is rarely checked as the router may not have global connectivity or CRL-aware software. The operator MUST ensure that the installed CA certificate is valid. 11. IANA Considerations This document has no IANA Considerations. @@ -595,25 +590,20 @@ editor.org/info/rfc8209>. [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, . 12.1. Informative References - [I-D.ylonen-sshkeybcp] - Ylonen, T. and G. Kent, "Managing SSH Keys for Automated - Access - Current Recommended Practice", draft-ylonen- - sshkeybcp (work in progress), April 2013. - [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, . [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, . @@ -758,26 +748,27 @@ into the router; using the private key just generated to sign the certification request with the algorithms referenced in the main body of this document; the CSR is signed to prove to the CA that the router has possession of the private key (i.e., the signature is the proof-of-possession). The output of the command is the CSR file; the file format varies depending on the arcane command you issued, but generally the files are DER or PEM-encoded. The third step is to retrieve the signed CSR from the router and send it to the CA. But before sending it, you need to also send the CA - the subject name and serial number for the router. The CA needs this - information to issue the certificate. How you get the CSR to the CA, - is beyond the scope of this document. While you are still connected - to the router, install the Trust Anchor (TA) for the root of the PKI. - At this point, you no longer need access to the router for BGPsec- - related initiation purposes. + the subject name (i.e., "ROUTER-" followed by the AS number) and + serial number (i.e., the 32-bit BGP Identifier) for the router. The + CA needs this information to issue the certificate. How you get the + CSR to the CA, is beyond the scope of this document. While you are + still connected to the router, install the Trust Anchor (TA) for the + root of the PKI. At this point, you no longer need access to the + router for BGPsec-related initiation purposes. The fourth step is for the CA to issue the certificate based on the CSR you sent; the certificate will include the subject name, serial number, public key, and other fields as well as being signed by the CA. After the CA issues the certificate, the CA returns the certificate, and posts the certificate to the RPKI repository. Check that the certificate corresponds to the private key by verifying the signature on the CSR sent to the CA; this is just a check to make sure that the CA issued a certificate that includes a public key that is the pair of the private key (i.e., the math will work when