draft-ietf-sidrops-rtr-keying-05.txt   draft-ietf-sidrops-rtr-keying-06.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: Best Current Practice S. Turner Intended status: Best Current Practice S. Turner
Expires: October 13, 2019 sn3rd Expires: November 15, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
April 11, 2019 May 14, 2019
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-05 draft-ietf-sidrops-rtr-keying-06
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 44 skipping to change at page 2, line 44
9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 10
9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.1. Informative References . . . . . . . . . . . . . . . . . 14 12.1. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Management/Router Channel Security . . . . . . . . . 16 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 [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 methods, router- appropriate public-private key-pairs. There are two methods, router-
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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 operators's End Syntax (CMS) SignedData [RFC5652] and signed with the operators's End
Entity (EE) private key. 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 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 whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope. notification mechanism is out of scope.
6. Send PKCS#10 and Receive PKCS#7 6. Send PKCS#10 and Receive PKCS#7
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
certification request, sign the key in the PKCS#10 (i.e., certify it) 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 and generate a PKCS#7 certs-only message, as well as publishing the
certificate in the Global RPKI. External network connectivity may be certificate in the Global RPKI. External network connectivity may be
skipping to change at page 16, line 34 skipping to change at page 16, line 34
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 at least as good as the security also enable a level of security at least as good as the security
offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could
be used for authentication. be used for authentication.
The protected channel must provide confidentiality, authentication, The protected channel must provide confidentiality, authentication,
and integrity and replay protection. 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 This appendix is informative. It attempts to explain some of the PKI
lingo in plainer language. lingo in plainer language.
BGPsec speakers send signed BGPsec updates that are verified by other BGPsec speakers send signed BGPsec updates that are verified by other
BGPsec speakers. In PKI parlance, the senders are referred to as BGPsec speakers. In PKI parlance, the senders are referred to as
signers and the receivers are referred to as relying parties. The signers and the receivers are referred to as relying parties. The
signers with which we are concerned here are routers signing BGPsec signers with which we are concerned here are routers signing BGPsec
updates. Signers use private keys to sign and relying parties use updates. Signers use private keys to sign and relying parties use
the corresponding public keys, in the form of X.509 public key the corresponding public keys, in the form of X.509 public key
skipping to change at page 18, line 17 skipping to change at page 18, line 17
CSR to the CA, is beyond the scope of this document. While you are 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 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 root of the PKI. At this point, you no longer need access to the
router for BGPsec-related initiation purposes. router for BGPsec-related initiation purposes.
The fourth step is for the CA to issue the certificate based on the 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 CSR you sent; the certificate will include the subject name, serial
number, public key, and other fields as well as being signed by the number, public key, and other fields as well as being signed by the
CA. After the CA issues the certificate, the CA returns the CA. After the CA issues the certificate, the CA returns the
certificate, and posts the certificate to the RPKI repository. Check 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; 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 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., 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 the math will work when verifying a signature generated by the
private with the returned certificate). private with the returned certificate).
If generating the keys off-router (operator-driven), then the same If generating the keys off-router (operator-driven), then the same
steps are used as the on-router key generation, (possibly with the 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 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 access to the router is needed the first three steps are done on an
 End of changes. 7 change blocks. 
7 lines changed or deleted 7 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/