draft-ietf-sidrops-rtr-keying-04.txt   draft-ietf-sidrops-rtr-keying-05.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: August 31, 2019 sn3rd Expires: October 13, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
February 27, 2019 April 11, 2019
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-04 draft-ietf-sidrops-rtr-keying-05
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 23 skipping to change at page 2, line 23
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Management / Router Communication . . . . . . . . . . . . . . 4 2. Management / Router Communication . . . . . . . . . . . . . . 3
3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 6
5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 6
6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7 6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 7
7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7 7. Install Certificate . . . . . . . . . . . . . . . . . . . . . 7
8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8 8. Advanced Deployment Scenarios . . . . . . . . . . . . . . . . 8
9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . 15 Appendix A. Management/Router Channel Security . . . . . . . . . 16
Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 16 Appendix B. The n00b Guide 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-
driven and operator-driven. driven and operator-driven.
These two 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.
of the methods in order to work in various deployment environments.
Some routers may not allow the private key to be exported while
others may. While exporting 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.
In the router-driven method, the router generates its own The two methods also differ in who generates the private/public key
public/private key-pair. pair: the operator generates the pair and sends it to the router in
the operator-driven method, and the router generates its own pair in
the router-drive method.
The router-driven method mirrors the model used by traditional PKI The router-driven method mirrors the model used by traditional PKI
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 method does not always work. The operator-driven model is this method does not always work. The operator-driven model is
motivated by the extreme importance placed on ensuring the continued motivated by the extreme importance placed on ensuring the continued
operation of the network. In some deployments, the same private key operation of the network. In some deployments, the same private key
skipping to change at page 4, line 30 skipping to change at page 4, line 24
(see [RFC6470]), the protected channel used between the management (see [RFC6470]), the protected channel used between the management
platform and the router is assumed to be an SSH-protected CLI. See platform and the router is assumed to be an SSH-protected CLI. See
Appendix A for security considerations for this protected channel. Appendix A for security considerations for this protected channel.
The previous paragraph assumes the management system-to-router The previous paragraph assumes the management system-to-router
communications are over a network. When the management system has a communications are over a network. When the management system has a
direct physical connection to the router, e.g., via the craft port, direct physical connection to the router, e.g., via the craft port,
there is no assumption that there is a protected channel between the there is no assumption that there is a protected channel between the
two. two.
To be clear: for both of these methods, an initial leap-of-faith is
required because the router has no keying material that it can use to
protect communications with anyone or anything. Because of this
initial leap of faith, a direct physical connection is safer than
connecting via a network connection because there is less chance of a
man in the middle. Once keying material is established on the
router, the communications channel must prevent eavesdropping,
tampering, and message forgery. This initial leap-of-faith will no
longer be required once routers are delivered to operators with
operator-trusted keying material
3. Exchange Certificates 3. Exchange Certificates
A number of options exist for the operator management station to A number of options exist for the operator management station to
exchange PKI-related information with routers and with the RPKI exchange PKI-related information with routers and with the RPKI
including: including:
- Using application/pkcs10 media type [RFC5967] to extract - Using application/pkcs10 media type [RFC5967] to extract
certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751- certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751-
bis] to return the issued certificate, bis] to return the issued certificate,
skipping to change at page 8, line 48 skipping to change at page 9, line 5
the CA prior to operator initiating the router's CSR. CAs use the CA prior to operator initiating the router's CSR. CAs use
authentication material to determine whether the router is authentication material to determine whether the router is
eligible to receive a certificate. Authentication material at a eligible to receive a certificate. Authentication material at a
minimum includes the router's AS number and BGP Identifier as minimum includes the router's AS number and BGP Identifier as
well as the router's key material, but can also include well as the router's key material, but can also include
additional information. Authentication material can be additional information. Authentication material can be
communicated to the CA (i.e., CSRs signed by this key material communicated to the CA (i.e., CSRs signed by this key material
are issued certificates with this AS and BGP Identifier) or to are issued certificates with this AS and BGP Identifier) or to
the router (i.e., the operator uses the vendor-supplied the router (i.e., the operator uses the vendor-supplied
management interface to include the AS number and BGP Identifier management interface to include the AS number and BGP Identifier
in the router-generated CSR). in the router-generated CSR). The CA stores this authentication
material in an account entry for the router so that it can later
be compared against the CSR prior to the CA issuing a certificate
to the router.
2. Enabling the router to communicate with the CA. While the 2. Enabling the router to communicate with the CA. While the
router-to-CA communications are operator-initiated, the router-to-CA communications are operator-initiated, the
operator's management interface need not be involved in the operator's management interface need not be involved in the
communications path. Enabling the router-to-CA connectivity communications path. Enabling the router-to-CA connectivity
requires connections to external networks (i.e., through requires connections to external networks (i.e., through
firewalls, NATs, etc.). firewalls, NATs, etc.).
3. Ensuring the cryptographic chain of custody from the 3. Ensuring the cryptographic chain of custody from the
manufacturer. For the pre-installed key material, the operator manufacturer. For the pre-installed key material, the operator
skipping to change at page 16, line 19 skipping to change at page 16, line 27
security), do not use Triple DES (112 bits of security). Suggested security), do not use Triple DES (112 bits of security). Suggested
minimum algorithms would be AES-128: aes128-cbc [RFC4253] and minimum algorithms would be AES-128: aes128-cbc [RFC4253] and
AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or
AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256 AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256
[RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for
key exchange. key exchange.
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 commensurate with BGPsec keys; also enable a level of security at least as good as the security
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for offered by th BGPsec keys; x509v3-ecdsa-sha2-nistp256 [RFC6187] could
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. The n00b Guide 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
 End of changes. 12 change blocks. 
22 lines changed or deleted 30 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/