draft-ietf-sidrops-rtr-keying-02.txt   draft-ietf-sidrops-rtr-keying-03.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: Best Current Practice S. Turner
Expires: June 21, 2019 sn3rd Expires: July 20, 2019 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
December 18, 2018 January 16, 2019
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-02 draft-ietf-sidrops-rtr-keying-03
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 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2017. This Internet-Draft will expire on January 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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.
In the router-driven method, the router generates its own In the router-driven method, the router generates its own
public/private key-pair. public/private key-pair.
The router-driven model 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 model does not always work. For example, when an operator wants this method does not always work. For example, when an operator
to support hot-swappable routers, the same private key needs to be wants to support hot-swappable routers, the same private key needs to
installed in the soon-to-be online router that was used by the the be 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
method.
Sections 2 through 7 describe the various steps involved for an Sections 2 through 7 describe the various steps involved for an
operator to use the two methods to provision new and existing operator to use the two methods to provision new and existing
routers. The methods described involve the operator configuring the routers. The methods described involve the operator configuring the
two end points (i.e., the management station and the router) and two end points (i.e., the management station and the router) and
acting as the intermediary. Section 8 describes another method that acting as the intermediary. Section 8 describes another method that
requires more 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
skipping to change at page 4, line 7 skipping to change at page 4, line 8
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
chosen, operators first establish a protected channel between the chosen, operators first establish a protected channel between the
management system and the router. How this protected channel is management system and the router. How this protected channel is
established is router-specific and is beyond scope of this document. established is router-specific and is beyond scope of this document.
Though other configuration mechanisms might be used, e.g. NetConf Though other configuration mechanisms might be used, e.g. NetConf
(see [RFC6470]); for simplicity, in this document, the protected (see [RFC6470]), the protected the protected channel between the
channel between the management platform and the router is assumed to management platform and the router is assumed to be an SSH-protected
be an SSH-protected CLI. See Appendix A for security considerations CLI. See Appendix A for security considerations for this protected
for this protected channel. channel.
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:
- Use application/pkcs10 media type [RFC5967] to extract certificate - Using application/pkcs10 media type [RFC5967] to extract
requests and application/pkcs7-mime [I-D.lamps-rfc5751-bis] to return certificate requests and application/pkcs7-mime [I-D.lamps-rfc5751-
the issued certificate, bis] to return the issued certificate,
- Use FTP or HTTP per [RFC2585], and - Using FTP or HTTP per [RFC2585], and
- Use Enrollment over Secure Transport (EST) protocol per [RFC7030]. - Using Enrollment over Secure Transport (EST) protocol per
[RFC7030].
4. Set-Up 4. Set-Up
To start, the operator uses the protected channel to install the To start, the operator uses the protected channel to install the
appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router. appropriate RPKI Trust Anchor's Certificate (TA Cert) in the router.
This will later enable the router to validate the router certificate This will later enable the router to validate the router certificate
returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis]. returned in the PKCS#7 certs-only message [I-D.lamps-rfc5751-bis].
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
skipping to change at page 5, line 19 skipping to change at page 5, line 21
the operator transmits the AS it has chosen on 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 the router has generated the PKCS#10 certification
returned to the operator over the protected channel. request, it returns it to the operator over the protected channel.
The operator includes the chosen AS number and the BGP 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 BGP 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, 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].
skipping to change at page 7, line 27 skipping to change at page 7, line 28
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.
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
certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed
manufacturer-generated Pre-Shared Keys (PSK) as well as manufacturer-generated Pre-Shared Keys (PSK) as well as
PKI-enrollment functionality and transport protocol, e.g., CMC's PKI-enrollment functionality and transport protocol, e.g., CMC's
"Secure Transport" [RFC7030] or the original CMC transport protocol's "Secure Transport" [RFC7030] or the original CMC transport protocol's
[RFC5273]. When the operator first establishes a protected channel [RFC5273]. When the operator first establishes a protected channel
between the management system and the router, this pre-installed key between the management system and the router, this pre-installed key
material is used to authenticate the router. material is used to authenticate the router.
The operator burden shifts here to include: The operator's burden shifts here to include:
1. Securely communicating the router's authentication material to 1. Securely communicating the router's authentication material to
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
skipping to change at page 8, line 46 skipping to change at page 8, line 47
Key management does not only include key generation, key Key management does not only include key generation, key
provisioning, certificate issuance, and certificate distribution. It provisioning, certificate issuance, and certificate distribution. It
also includes assurance of key validity, key roll-over, and key also includes assurance of key validity, key roll-over, and key
preservation during router replacement. All of these preservation during router replacement. All of these
responsibilities persist for as long as the operator wishes to responsibilities persist for as long as the operator wishes to
operate the BGPsec-speaking router. operate the BGPsec-speaking router.
9.1. Key Validity 9.1. Key Validity
It is critical that a BGPsec speaking router is signing with a valid It is critical that a BGPsec-speaking router is signing with a valid
private key at all times. To this end, the operator needs to ensure private key at all times. To this end, the operator needs to ensure
the router always has a non-expired certificate. I.e. the key used the router always has a non-expired certificate. I.e. the key used
to sign BGPsec announcements always has an associated certificate to sign BGPsec announcements always has an associated certificate
whose expiry time is after the current time. whose expiry time is after the current time.
Ensuring this is not terribly difficult but requires that either: Ensuring this is not terribly difficult but requires that either:
1. The router has a mechanism to notify the operator that the 1. The router have a mechanism to notify the operator that the
certificate has an impending expiration, and/or certificate has an impending expiration, and/or
2. The operator notes the expiry time of the certificate and uses a 2. The operator note the expiry time of the certificate and uses a
calendaring program to remind them of the expiry time, and/or calendaring program to remind them of the expiry time, and/or
3. The RPKI CA warns the operator of pending expiration, and/or 3. The RPKI CA warn the operator of pending expiration, and/or
4. The operator uses some other kind of automated process to search 4. The operator use some other kind of automated process to search
for and track the expiry times of router certificates. for and track the expiry times of router certificates.
It is advisable that expiration warnings happen well in advance of It is advisable that expiration warnings happen well in advance of
the actual expiry time. the actual expiry time.
Regardless of the technique used to track router certificate expiry Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same times, it is advisable to notify additional operators in the same
organization as the expiry time approaches, thereby ensuring that the organization as the expiry time approaches, thereby ensuring that the
forgetfulness of one operator does not affect the entire forgetfulness of one operator does not affect the entire
organization. organization.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
informative is that the steps for the do-it-yourself (DIY) approach informative is that the steps for the do-it-yourself (DIY) approach
involve arcane commands while the GUI-based vendor-assisted involve arcane commands while the GUI-based vendor-assisted
management console approach will likely hide all of those commands management console approach will likely hide all of those commands
behind some button clicks. Regardless, the operator will end up with behind some button clicks. Regardless, the operator will end up with
a BGPsec-enabled router. Initially, we focus on the DIY approach and a BGPsec-enabled router. Initially, we focus on the DIY approach and
then follow up with some information about the GUI-based approach. then follow up with some information about the GUI-based approach.
The first step in the DIY approach is to generate a private key; but The first step in the DIY approach is to generate a private key; but
in fact what you do is create a key pair; one part, the private key, in fact what you do is create a key pair; one part, the private key,
is kept very private and the other part, the public key, is given out is kept very private and the other part, the public key, is given out
to verify whatever is signed. The two models for how to create the to verify whatever is signed. The two methods for how to create the
key pair are the subject of this document, but it boils down to key pair are the subject of this document, but it boils down to
either doing it on-router (router-driven) or off-router (operator- either doing it on-router (router-driven) or off-router (operator-
driven). driven).
If you are generating keys on the router (router-driven), then you If you are generating keys on the router (router-driven), then you
will need to access the router. Again, how you access the router is will need to access the router. Again, how you access the router is
router-specific, but generally the DIY approach uses the CLI and router-specific, but generally the DIY approach uses the CLI and
accessing the router either directly via the router's craft port or accessing the router either directly via the router's craft port or
over the network on an administrative interface. If accessing the over the network on an administrative interface. If accessing the
router over the network be sure to do it securely (i.e., use SSHv2). router over the network be sure to do it securely (i.e., use SSHv2).
 End of changes. 20 change blocks. 
30 lines changed or deleted 32 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/