--- 1/draft-ietf-sidrops-rtr-keying-05.txt 2019-05-14 19:13:18.396311439 -0700 +++ 2/draft-ietf-sidrops-rtr-keying-06.txt 2019-05-14 19:13:18.440312553 -0700 @@ -1,21 +1,21 @@ Network Working Group R. Bush Internet-Draft IIJ Lab / Dragon Research Lab Intended status: Best Current Practice S. Turner -Expires: October 13, 2019 sn3rd +Expires: November 15, 2019 sn3rd K. Patel Arrcus, Inc. - April 11, 2019 + May 14, 2019 Router Keying for BGPsec - draft-ietf-sidrops-rtr-keying-05 + draft-ietf-sidrops-rtr-keying-06 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. @@ -76,21 +76,21 @@ 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Management/Router Channel Security . . . . . . . . . 16 - Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16 + Appendix B. An Introduction to BGPsec Key Management . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 methods, router- @@ -276,21 +276,21 @@ 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 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 - operator's EE certificate(s). The router SHOULD inform the operator + operators' 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 @@ -735,21 +735,21 @@ 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 BGPsec. The certificates used with SSH should also enable a level of security at least as good as the security offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication. The protected channel must provide confidentiality, authentication, and integrity and replay protection. -Appendix B. The n00b Guide to BGPsec Key Management +Appendix B. An Introduction to BGPsec Key Management This appendix is informative. It attempts to explain some of the PKI lingo in plainer language. BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers. In PKI parlance, the senders are referred to as signers and the receivers are referred to as relying parties. The signers with which we are concerned here are routers signing BGPsec updates. Signers use private keys to sign and relying parties use the corresponding public keys, in the form of X.509 public key @@ -814,21 +814,21 @@ 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 pubic key contained in the + that the certificate corresponds to the public key contained in the certificate 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 verifying a signature generated by the private with the returned certificate). If generating the keys off-router (operator-driven), then the same steps are used as the on-router key generation, (possibly with the same arcane commands as those used in the on-router approach), but no access to the router is needed the first three steps are done on an