draft-ietf-sidr-rtr-keying-15.txt   draft-ietf-sidr-rtr-keying-16.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: October 25, 2018 sn3rd Expires: March 3, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
April 23, 2018 August 30, 2018
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-15 draft-ietf-sidr-rtr-keying-16
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 39 skipping to change at page 2, line 39
5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5
6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 6
7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 6
8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 7
9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9
9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.1. Informative References . . . . . . . . . . . . . . . . . 13 12.1. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Management/Router Channel Security . . . . . . . . . 14 Appendix A. Management/Router Channel Security . . . . . . . . . 15
Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 sub-methods, appropriate public-private key-pairs. There are two sub-methods,
router-driven and operator-driven. router-driven and operator-driven.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
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 per-
router certificates, a BGP Identifier of 0 may be used. 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
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 NOTE: The PKCS#10 certification request does not include the AS
number or the BGP Identifier for the router certificate. Therefore, 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 or the router and the BGP
Identifier as well when it sends the CSR to the CA. Identifier as well when it sends the CSR to the CA.
5.1. Router-Generated Keys 5.1. Router-Generated Keys
In the router-generated method, once the protected channel is In the router-generated method, once the protected channel is
established and the initial Set-Up (Section 4) performed, the established and the initial Set-Up (Section 4) performed, the
operator issues a command or commands for the router to generate the operator issues a command or commands for the router to generate the
public/private key pair, to generate the PKCS#10 certification public/private key pair, to generate the PKCS#10 certification
request, and to sign the PKCS#10 certification request with the request, and to sign the PKCS#10 certification request with the
private key. Once generated, the PKCS#10 certification request is private key. Once generated, the PKCS#10 certification request is
returned to the operator over the protected channel. returned to the operator over the protected channel.
The operator includes the chosen AS number and the BPG Identifier The operator includes the chosen AS number and the BGP Identifier
when it sends the CSR to the CA. when it sends the CSR to the CA.
NOTE: If a router were to communicate directly with a CA to have the NOTE: If a router were to communicate directly with a CA to have the
CA certify the PKCS#10 certification request, there would be no way CA certify the PKCS#10 certification request, there would be no way
for the CA to authenticate the router. As the operator knows the for the CA to authenticate the router. As the operator knows the
authenticity of the router, the operator mediates the communication authenticity of the router, the operator mediates the communication
with the CA. with the CA.
5.2. Operator-Generated Keys 5.2. Operator-Generated Keys
In the operator-generated method, the operator generates the In the operator-generated method, the operator generates the
public/private key pair on a management station and installs the public/private key pair on a management station and installs the
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 BPG 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,
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 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
ensure the returned private key did in fact come from the operator, ensure the returned private key did in fact come from the operator,
skipping to change at page 6, line 29 skipping to change at page 6, line 38
Global RPKI. Global RPKI.
2. Returns the certificate to the operator's management station, 2. Returns the certificate to the operator's management station,
packaged in a PKCS#7 certs-only message, using the corresponding packaged in a PKCS#7 certs-only message, using the corresponding
method by which it received the certificate request. It SHOULD method by which it received the certificate request. It SHOULD
include the certificate chain below the TA Certificate so that include the certificate chain below the TA Certificate so that
the router can validate the router certificate. the router can validate the router certificate.
In the operator-generated method, the operator SHOULD extract the In the operator-generated method, the operator SHOULD extract the
certificate from the PKCS#7 certs-only message, and verify that the certificate from the PKCS#7 certs-only message, and verify that the
private key it holds corresponds to the returned public key. private key it holds corresponds to the returned public key. If the
operator saved 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 operator has not saved the PKCS#10, it can check
this correspondence by generating a signature on any data and then
verifying the signature using the returned certificate.
In the operator-generated method, the operator has already installed In the operator-generated method, the operator has already installed
the private key in the router (see Section 5.2). the private key in the router (see Section 5.2).
7. Install Certificate 7. Install Certificate
The operator provisions the PKCS#7 certs-only message into the router The operator provisions the PKCS#7 certs-only message into the router
over the protected channel. 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-ony
message and verify that the public key corresponds to the stored message and verify that the public key corresponds to the stored
private key. The router SHOULD inform the operator whether it 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 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.
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].
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
skipping to change at page 12, line 8 skipping to change at page 12, line 23
This document has no IANA Considerations. This document has no IANA Considerations.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.sidrops-bgpsec-rollover] [I-D.sidrops-bgpsec-rollover]
Weis, B, R. Gagliano, and K. Patel, "BGPsec Router Weis, B, R. Gagliano, and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidrops-bgpsec- Certificate Rollover", draft-ietf-sidrops-bgpsec-
rollover (work in progress), October 2017. rollover (work in progress), December 2017.
[I-D.lamps-rfc5751-bis] [I-D.lamps-rfc5751-bis]
Schaad, J., Ramsdell, B, S. Turner, Schaad, J., Ramsdell, B, S. Turner,
"Secure/Multipurpose Internet Mail Extension (S/MIME) "Secure/Multipurpose Internet Mail Extension (S/MIME)
Version 4.0", draft-ietf-lamps-rfc5751- Version 4.0", draft-ietf-lamps-rfc5751-
bis (work in progress), April 2013. bis (work in progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc- 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <https://www.rfc- DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
editor.org/info/rfc4086>. editor.org/info/rfc4086>.
skipping to change at page 17, line 5 skipping to change at page 17, line 18
At this point, you no longer need access to the router for BGPsec- At this point, you no longer need access to the router for BGPsec-
related initiation purposes. 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 private key by verifying the 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 signature on the CSR sent to the CA; this is just a check to make
sure that the CA issued a certificate corresponding to the private sure that the CA issued a certificate that includes a public key that
key on the router. 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 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
administrative workstation: o Step 1: Generate key pair; o Step 2: administrative workstation: o Step 1: Generate key pair; o Step 2:
Create CSR and sign CSR with private key, and; o Step 3: Send CSR Create CSR and sign CSR with private key, and; o Step 3: Send CSR
file with the subject name and serial number to CA. file with the subject name and serial number to CA.
After the CA has returned the certificate and you have checked the After the CA has returned the certificate and you have checked the
 End of changes. 15 change blocks. 
21 lines changed or deleted 37 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/