< draft-ietf-sidrops-rtr-keying-01.txt   draft-ietf-sidrops-rtr-keying-02.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: June 7, 2019 sn3rd Expires: June 21, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
December 4, 2018 December 18, 2018
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-01 draft-ietf-sidrops-rtr-keying-02
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 43 skipping to change at page 2, line 43
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 . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.1. Informative References . . . . . . . . . . . . . . . . . 13 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 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 methods, router-
router-driven and operator-driven. 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 router in the router-driven method, and elsewhere in the
operator-driven method. Routers are required to support at least one operator-driven method. Routers are required to support at least one
of the methods in order to work in various deployment environments. of the methods in order to work in various deployment environments.
Some routers may not allow the private key to be off-loaded while Some routers may not allow the private key to be off-loaded while
others may. While off-loading private keys would ease swapping of others may. While off-loading private keys would ease swapping of
routing engines, exposure of private keys is a well known security routing engines, exposure of private keys is a well known security
risk. risk.
In the operator-driven method, the operator generates the In the operator-driven method, the operator generates the
private/public key-pair and sends it to the router. private/public key-pair and sends it to the router.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
subscribers; the private key never leaves trusted storage (e.g., subscribers; the private key never leaves trusted storage (e.g.,
Hardware Security Module). This is by design and supports classic Hardware Security Module). This is by design and supports classic
PKI Certification Policies for (often human) subscribers which PKI Certification Policies for (often human) subscribers which
require the private key only ever be controlled by the subscriber to require the private key only ever be controlled by the subscriber to
ensure that no one can impersonate the subscriber. For non-humans, ensure that no one can impersonate the subscriber. For non-humans,
this model does not always work. For example, when an operator wants 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 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. soon-to-be offline router. This motivated the operator-driven model.
The remainder of this document describes how operators can use the Sections 2 through 7 describe the various steps involved for an
two methods to provision new and existing routers. The methods operator to use the two methods to provision new and existing
described involve the operator configuring the two end points (i.e., routers. The methods described involve the operator configuring the
the management station and the router) and acting as the two end points (i.e., the management station and the router) and
intermediary. Section 8 describes a method that requires more acting as the intermediary. Section 8 describes another method that
capable routers. requires more capable routers.
Useful References: [RFC8205] describes gritty details, [RFC8209] Useful References: [RFC8205] describes gritty details, [RFC8209]
specifies the format for the PKCS#10 certification request, and specifies the format for the PKCS#10 certification request, and
[RFC8208] specifies the algorithms used to generate the PKCS#10's [RFC8208] specifies the algorithms used to generate the PKCS#10's
signature. signature.
2. Management / Router Communication 2. Management / Router Communication
Operators are free to use either the router-driven or operator-driven Operators are free to use either the router-driven or operator-driven
method as supported by the platform. Regardless of the method method as supported by the platform. Regardless of the method
skipping to change at page 4, line 43 skipping to change at page 4, line 43
The operator also configures the Autonomous System (AS) number to be The operator also configures the Autonomous System (AS) number to be
used in the generated router certificate. This may be the sole AS 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 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 ASs. A router with multiple ASs can be
configured with multiple router certificates by following the process configured with multiple router certificates by following the process
of this document for each desired certificate. of this document for each desired certificate.
The operator configures or extracts from the router the BGP The operator configures or extracts from the router the BGP
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 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 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 The PKCS#10 request SHOULD be saved to enable verifying that the
returned public key in the certificate corresponds to the private returned public key in the certificate corresponds to the private
used to generate the signature on the CSR. 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 on 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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
Even if the operator cannot extract the private key from the router, Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a 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]. (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 operators's End
(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 AS's include in the SignedData the RPKI CA certificate and relevant
EE certificate(s). The router should inform the operator whether or operator's EE certificate(s). The router should inform the operator
not the signature validates to a trust anchor; this notification whether or not the signature validates to a trust anchor; this
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
needed if the certificate is to be published in the Global RPKI. needed if the certificate is to be published in the Global RPKI.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
verifying the signature using the returned certificate. 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-only
message and verify that the public key corresponds to the stored message and verify that the public key corresponds to the stored
private key. If the router stored the PKCS#10, it can check this 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 correspondence by comparing the public key in the CSR to the public
key in the returned certificate. If the router did not store the key in the returned certificate. If the router did not store the
PKCS#10, it can check this correspondence by generating a signature PKCS#10, it can check this correspondence by generating a signature
on any data and then verifying the signature using the returned on any data and then verifying the signature using the returned
certificate. The router SHOULD inform the operator whether it 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.
skipping to change at page 11, line 50 skipping to change at page 11, line 50
level of security provided by the transport layer's security level of security provided by the transport layer's security
mechanism SHOULD be commensurate with the strength of the BGPsec mechanism SHOULD be commensurate with the strength of the BGPsec
key; there's no point in spending time and energy to generate an key; there's no point in spending time and energy to generate an
excellent public-private key pair and then transmit the private excellent public-private key pair and then transmit the private
key in the clear or with a known-to-be-broken algorithm, as it 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. just undermines trust that the private key has been kept private.
Additionally, operators SHOULD ensure the transport security Additionally, operators SHOULD ensure the transport security
mechanism is up to date, in order to addresses all known mechanism is up to date, in order to addresses all known
implementation bugs. 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 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 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 revocation status of the CA's certificate is rarely checked as the
router may not have global connectivity or CRL-aware software. The router may not have global connectivity or CRL-aware software. The
operator MUST ensure that the installed CA certificate is valid. operator MUST ensure that the installed CA certificate is valid.
11. IANA Considerations 11. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
skipping to change at page 13, line 35 skipping to change at page 13, line 30
editor.org/info/rfc8209>. editor.org/info/rfc8209>.
[802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and [802.1AR] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, December 2009,
<http://standards.ieee.org/findstds/standard/802.1AR- <http://standards.ieee.org/findstds/standard/802.1AR-
2009.html>. 2009.html>.
12.1. Informative References 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 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004, RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>. <https://www.rfc-editor.org/info/rfc3766>.
skipping to change at page 17, line 8 skipping to change at page 16, line 46
into the router; using the private key just generated to sign the into the router; using the private key just generated to sign the
certification request with the algorithms referenced in the main body certification request with the algorithms referenced in the main body
of this document; the CSR is signed to prove to the CA that the 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 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 proof-of-possession). The output of the command is the CSR file; the
file format varies depending on the arcane command you issued, but file format varies depending on the arcane command you issued, but
generally the files are DER or PEM-encoded. generally the files are DER or PEM-encoded.
The third step is to retrieve the signed CSR from the router and send 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 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 the subject name (i.e., "ROUTER-" followed by the AS number) and
information to issue the certificate. How you get the CSR to the CA, serial number (i.e., the 32-bit BGP Identifier) for the router. The
is beyond the scope of this document. While you are still connected CA needs this information to issue the certificate. How you get the
to the router, install the Trust Anchor (TA) for the root of the PKI. CSR to the CA, is beyond the scope of this document. While you are
At this point, you no longer need access to the router for BGPsec- still connected to the router, install the Trust Anchor (TA) for the
related initiation purposes. 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 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 that includes a public key that 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 is the pair of the private key (i.e., the math will work when
 End of changes. 15 change blocks. 
38 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/