< draft-ietf-sidr-rtr-keying-14.txt   draft-ietf-sidr-rtr-keying-15.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: April 23, 2018 sn3rd Expires: October 25, 2018 sn3rd
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
October 20, 2017 April 23, 2018
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-14 draft-ietf-sidr-rtr-keying-15
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
be interpreted as described in RFC 2119 [RFC2119] only when they "OPTIONAL" in this document are to be interpreted as described in BCP
appear in all upper case. They may also appear in lower or mixed 14 [RFC2119] [RFC8174] when, and only when, they appear in all
case as English words, without normative meaning. capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
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 . . . . . . . . . . . . . . 3 2. Management / Router Communication . . . . . . . . . . . . . . 3
3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4 3. Exchange Certificates . . . . . . . . . . . . . . . . . . . . 4
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4 5. Generate PKCS#10 . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 4 5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 5
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5 5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5
5.2.1. Using PKCS#8 to Transfer Public Key . . . . . . . . . 5 5.2.1. Using PKCS#8 to Transfer Private Key . . . . . . . . . 5
6. Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9 9.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . . 9
9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 9 9.4. Router Replacement . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.1. Informative References . . . . . . . . . . . . . . . . . 12 12.1. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Management/Router Channel Security . . . . . . . . . 14 Appendix A. Management/Router Channel Security . . . . . . . . . 14
Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 14 Appendix B. The n00b Guide to BGPsec Key Management . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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,
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 The remainder of this document describes how operators can use the
two methods to provision new and existing routers. The methods two methods to provision new and existing routers. The methods
described involve the operator configuring the two end points and described involve the operator configuring the two end points (i.e.,
acting as the intermediary. Section 7 describes a method that the management station and the router) and acting as the
requires more capable routers. intermediary. Section 7 describes a method that 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 request, and [RFC8208] specifies the format for the PKCS#10 certification request, and
specifies the algorithms used to generate the signature. [RFC8208] specifies the algorithms used to generate the PKCS#10's
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 secure communication channel chosen, operators first establish a protected channel between the
between the management system and the router. How this 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 communication (see [RFC6470]); for simplicity, in this document, the protected
channel between the management platform and the router is assumed to channel between the management platform and the router is assumed to
be an SSH-protected CLI. See Appendix A for security considerations be an SSH-protected CLI. See Appendix A for security considerations
for this channel. for this protected 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 - Use application/pkcs10 media type [RFC5967] to extract certificate
requests and application/pkcs7-mime [RFC5751] to return the issued requests and application/pkcs7-mime [I-D.lamps-rfc5751-bis] to return
certificate, the issued certificate,
- Use FTP or HTTP per [RFC2585], and - Use FTP or HTTP per [RFC2585], and
- Use Enrollment over Secure Transport (EST) protocol per [RFC7030]. - Use Enrollment over Secure Transport (EST) protocol per [RFC7030].
4. Set-Up 4. Set-Up
To start, the operator uses the communication channel to install the To start, the operator uses the protected channel to install the
appropriate RPKI Trust Anchor' 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. 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
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. configured with multiple ASs. A router with multiple ASs can be
configured with multiple router certificates by following the process
of this document for each desired certificate.
The operator configures or extracts from the router the BGP RouterID The operator configures or extracts from the router the BGP
to be used in the generated certificate. In the case where the Identifier [RFC4271] to be used in the generated router certificate.
operator has chosen not to use unique per-router certificates, a In the case where the operator has chosen not to use unique per-
RouterID 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 request, which is sometimes The private key, and hence the PKCS#10 certification request, which
referred to as a Certificate Signing Request (CSR), may be generated is sometimes referred to as a Certificate Signing Request (CSR), may
by the router or by the operator. be generated by the router or by the operator.
NOTE: The PKCS#10 certification request does not include the AS
number or the BGP Identifier for the router certificate. Therefore,
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.
5.1. Router-Generated Keys 5.1. Router-Generated Keys
In the router-generated method, once the protected session 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 request, and to sign public/private key pair, to generate the PKCS#10 certification
the PKCS#10 with the private key. Once generated, the PKCS#10 is request, and to sign the PKCS#10 certification request with the
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 adds the chosen AS number and the RouterID to send to The operator includes the chosen AS number and the BPG Identifier
the RPKI CA for the CA to certify. when it sends the CSR to the CA.
NOTE: If a router was 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, there would be no way for the CA to CA certify the PKCS#10 certification request, there would be no way
authenticate the router. As the operator knows the authenticity of for the CA to authenticate the router. As the operator knows the
the router, the operator mediates the communication with the CA. authenticity of the router, the operator mediates the communication
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 with the private key, The operator then creates and signs the PKCS#10 certification request
and adds the chosen AS number and RouterID to be sent to the RPKI CA with the private key; the operator includes the chosen AS number and
for the CA to certify. the BPG Identifier when it sends the CSR to the CA.
5.2.1. Using PKCS#8 to Transfer Public Key 5.2.1. Using PKCS#8 to Transfer Private Key
A private key encapsulated in a PKCS #8 [RFC5958] should be further A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5958] and should be further encapsulated in Cryptographic Message
[RFC5652] and signed with the AS's End Entity (EE) private key. Syntax (CMS) SignedData [RFC5652] and signed with the AS's End 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 AS's
EE certificate(s). The router should inform the operator whether or EE certificate(s). The router should inform the operator whether or
not the signature validates to a trust anchor; this notification not the signature validates to a trust anchor; this notification
mechanism is out of scope. 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
request, sign the key in the PKCS#10 (i.e., certify it) and generated certification request, sign the key in the PKCS#10 (i.e., certify it)
PKCS#7 response, as well as publishing the certificate in the Global and generate a PKCS#7 certs-only message, as well as publishing the
RPKI. External network connectivity may be needed if the certificate certificate in the Global RPKI. External network connectivity may be
is to be published in the Global RPKI. needed if the certificate is to be published in the Global RPKI.
After the CA certifies the key, it does two things: After the CA certifies the key, it does two things:
1. Publishes the certificate in the Global RPKI. The CA must have 1. Publishes the certificate in the Global RPKI. The CA must have
connectivity to the relevant publication point, which in turn connectivity to the relevant publication point, which in turn
must have external network connectivity as it is part of the must have external network connectivity as it is part of the
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, using the corresponding method by which it packaged in a PKCS#7 certs-only message, using the corresponding
received the certificate request. It SHOULD include the method by which it received the certificate request. It SHOULD
certificate chain below the TA Certificate so that the router can include the certificate chain below the TA Certificate so that
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, and verify that the private key it holds certificate from the PKCS#7 certs-only message, and verify that the
corresponds to the returned public key. private key it holds corresponds to the returned public key.
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 into the router over the secure The operator provisions the PKCS#7 certs-only message into the router
channel. over the protected channel.
The router SHOULD extract the certificate from the PKCS#7 and verify The router SHOULD extract the certificate from the PKCS#7 certs-ony
that the public key corresponds to the stored private key. The message and verify that the public key corresponds to the stored
router SHOULD inform the operator whether it successfully received private key. The router SHOULD inform the operator whether it
the certificate and whether or not the keys correspond; the mechanism successfully received the certificate and whether or not the keys
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. The router SHOULD inform the operator certificate in the PKCS#7 certs-only message. The router SHOULD
whether or not the signature validates to a trust anchor; this inform the operator whether or not the signature validates to a trust
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, 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].
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 PKI- manufacturer-generated Pre-Shared Keys (PSK) as well as PKI-
enrollment functionality and transport protocol, e.g., CMC's "Secure enrollment functionality and transport protocol, e.g., CMC's "Secure
Transport" [RFC7030] or the original CMC transport protocol's Transport" [RFC7030] or the original CMC transport protocol's
[RFC5273]. When the operator first establishes a secure [RFC5273]. When the operator first establishes a protected channel
communication channel between the management system and the router, between the management system and the router, this pre-installed key
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 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 RouterID as well as minimum includes the router's AS number and BGP Identifier as
the router's key material, but can also include additional well as the router's key material, but can also include
information. Authentication material can be communicated to the additional information. Authentication material can be
CA (i.e., CSRs signed by this key material are issued communicated to the CA (i.e., CSRs signed by this key material
certificates with this AS and RouterID) or to the router (i.e., are issued certificates with this AS and BGP Identifier) or to
the operator uses the vendor-supplied management interface to the router (i.e., the operator uses the vendor-supplied
include the AS number and routerID in the router-generated CSR). management interface to include the AS number and BGP Identifier
in the router-generated CSR).
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 MAY communications path. Enabling the router-to-CA connectivity MAY
require connections to external networks (i.e., through require connections to external networks (i.e., through
firewalls, NATs, etc.). firewalls, NATs, etc.).
Once configured, the operator can begin the process of enrolling the Once configured, the operator can begin the process of enrolling the
router. Because the router is communicating directly with the CA, router. Because the router is communicating directly with the CA,
there is no need for the operator to retrieve the PKCS#10 from the there is no need for the operator to retrieve the PKCS#10
router or return the PKCS#7 to the router as in Section 6. Note that certification request from the router as in Section 5 or return the
the checks performed by the router, namely extracting the certificate PKCS#7 certs-only message to the router as in Section 6. Note that
from the PKCS#7, verifying the public key corresponds to the private the checks performed by the router in Section 7, namely extracting
key, and that the returned certificate validated back to an installed the certificate from the PKCS#7 certs-only message, verifying the
trust anchor, SHOULD be performed. Likewise, the router SHOULD public key corresponds to the private key, and that the returned
notify the operator if any of these fail, but this notification certificate validated back to an installed trust anchor, SHOULD be
mechanism is out of scope. performed. Likewise, the router SHOULD notify the operator if any of
these fail, but this notification mechanism is out of scope.
When a router is so configured the communication with the CA SHOULD When a router is so configured the communication with the CA SHOULD
be automatically re-established by the router at future times to be automatically re-established by the router at future times to
renew or rekey the certificate automatically when necessary (See renew or rekey the certificate automatically when necessary (See
Section 8). This further reduces the tasks required of the operator. Section 8). This further reduces the tasks required of the operator.
9. Key Management 9. Key Management
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
skipping to change at page 8, line 33 skipping to change at page 8, line 45
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 has 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 notes 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 warns the operator of pending expiration, and/or
4. Use some other kind of automated process to search for and track 4. The operator uses some other kind of automated process to search
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 9, line 34 skipping to change at page 9, line 46
router's certificate, and then the process of re-keying/renewing the router's certificate, and then the process of re-keying/renewing the
router's certificate, (possibly distributing a new key and router's certificate, (possibly distributing a new key and
certificate to the router), and distributing the status takes time certificate to the router), and distributing the status takes time
during which the operator must decide how they wish to maintain during which the operator must decide how they wish to maintain
continuity of operations, with or without the compromised private continuity of operations, with or without the compromised private
key, or whether they wish to bring the router offline to address the key, or whether they wish to bring the router offline to address the
compromise. compromise.
Keeping the router operational and BGPsec-speaking is the ideal goal, Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the but if operational practices do not allow this then reconfiguring the
router to disabling BGPsec is likely preferred to bringing the router router to disable BGPsec is likely preferred to bringing the router
offline. offline.
Routers which support more than one private key, where one is Routers which support more than one private key, where one is
operational and other(s) are soon-to-be-operational, facilitate operational and other(s) are soon-to-be-operational, facilitate
revocation events because the operator can configure the router to revocation events because the operator can configure the router to
make a soon-to-be-operational key operational, request revocation of make a soon-to-be-operational key operational, request revocation of
the compromised key, and then make a next generation soon-to-be- the compromised key, and then make a next generation soon-to-be-
operational key, all hopefully without needing to take offline or operational key, all hopefully without needing to take offline or
reboot the router. For routers which support only one operational reboot the router. For routers which support only one operational
key, the operators should create or install the new private key, and key, the operators should create or install the new private key, and
skipping to change at page 10, line 4 skipping to change at page 10, line 16
operational key, all hopefully without needing to take offline or operational key, all hopefully without needing to take offline or
reboot the router. For routers which support only one operational reboot the router. For routers which support only one operational
key, the operators should create or install the new private key, and key, the operators should create or install the new private key, and
then request revocation of the certificate corresponding to the then request revocation of the certificate corresponding to the
compromised private key. compromised private key.
9.4. Router Replacement 9.4. Router Replacement
Currently routers often generate private keys for uses such as SSH, Currently routers often generate private keys for uses such as SSH,
and the private keys may not be seen or off-loaded from the router. and the private keys may not be seen or off-loaded from the router.
While this is good security, it creates difficulties when a routing While this is good security, it creates difficulties when a routing
engine or whole router must be replaced in the field and all software engine or whole router must be replaced in the field and all software
which accesses the router must be updated with the new keys. Also, which accesses the router must be updated with the new keys. Also,
any network based initial contact with a new routing engine requires any network based initial contact with a new routing engine requires
trust in the public key presented on first contact. trust in the public key presented on first contact.
To allow operators to quickly replace routers without requiring To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI, update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to inserted via a routers SHOULD allow the private BGPsec key to inserted via a
protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This
lets the operator escrow the old private key via the mechanism used lets the operator escrow the old private key via the mechanism used
for operator-generated keys, see Section 5.2, such that it can be re- for operator-generated keys, see Section 5.2, such that it can be re-
inserted into a replacement router. The router MAY allow the private inserted into a replacement router. The router MAY allow the private
key to be to be off-loaded via the protected session, but this SHOULD key to be to be off-loaded via the protected channel, but this SHOULD
be paired with functionality that sets the key into a permanent non- be paired with functionality that sets the key into a permanent non-
exportable state to ensure that it is not off-loaded at a future time exportable state to ensure that it is not off-loaded at a future time
by unauthorized operations. by unauthorized operations.
10. Security Considerations 10. Security Considerations
The router's manual will describe whether the router supports one, The router's manual will describe whether the router supports one,
the other, or both of the key generation options discussed in the the other, or both of the key generation options discussed in the
earlier sections of this draft as well as other important security- earlier sections of this draft as well as other important security-
related information (e.g., how to SSH to the router). After related information (e.g., how to SSH to the router). After
familiarizing one's self with the capabilities of the router, familiarizing one's self with the capabilities of the router, an
operators are encouraged to ensure that the router is patched with operator is encouraged to ensure that the router is patched with the
the latest software updates available from the manufacturer. latest software updates available from the manufacturer.
This document defines no protocols so in some sense introduces no new This document defines no protocols so in some sense introduces no new
security considerations. However, it relies on many others and the security considerations. However, it relies on many others and the
security considerations in the referenced documents should be security considerations in the referenced documents should be
consulted; notably, those document listed in Section 1 should be consulted; notably, those document listed in Section 1 should be
consulted first. PKI-relying protocols, of which BGPsec is one, have consulted first. PKI-relying protocols, of which BGPsec is one, have
many issues to consider so many in fact entire books have been many issues to consider so many in fact entire books have been
written to address them; so listing all PKI-related security written to address them; so listing all PKI-related security
considerations is neither useful nor helpful; regardless, some boot- considerations is neither useful nor helpful; regardless, some boot-
strapping-related issues are listed here that are worth repeating: strapping-related issues are listed here that are worth repeating:
skipping to change at page 11, line 23 skipping to change at page 11, line 35
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 SSH key management is known, in some cases, to be lax
[I-D.ylonen-sshkeybcp]; employees that no longer need access to [I-D.ylonen-sshkeybcp]; employees that no longer need access to a
routers SHOULD be removed the router to ensure only those authorized routers SHOULD be removed the router to ensure only those authorized
have access to a router. 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 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.
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), October 2017.
[I-D.lamps-rfc5751-bis]
Schaad, J., Ramsdell, B, S. Turner,
"Secure/Multipurpose Internet Mail Extension (S/MIME)
Version 4.0", draft-ietf-lamps-rfc5751-
bis (work in progress), April 2013.
[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>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
10.17487/RFC4271, January 2006, <https://www.rfc-
editor.org/info/rfc4271>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI
10.17487/RFC5958, August 2010, <https://www.rfc- 10.17487/RFC5958, August 2010, <https://www.rfc-
editor.org/info/rfc5958>. editor.org/info/rfc5958>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174, May 2017, <https://www.rfc-
editor.org/info/rfc8174>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208, DOI Formats, and Signature Formats", RFC 8208, DOI
10.17487/RFC8208, September 2017, <https://www.rfc- 10.17487/RFC8208, September 2017, <https://www.rfc-
editor.org/info/rfc8208>. editor.org/info/rfc8208>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists, BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209, DOI and Certification Requests", RFC 8209, DOI
10.17487/RFC8209, September 2017, <https://www.rfc- 10.17487/RFC8209, September 2017, <https://www.rfc-
editor.org/info/rfc8209>. editor.org/info/rfc8209>.
skipping to change at page 13, line 27 skipping to change at page 14, line 6
[RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
Secure Shell Transport Layer Protocol", RFC 5647, DOI Secure Shell Transport Layer Protocol", RFC 5647, DOI
10.17487/RFC5647, August 2009, <https://www.rfc- 10.17487/RFC5647, August 2009, <https://www.rfc-
editor.org/info/rfc5647>. editor.org/info/rfc5647>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer", Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009, RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>. <https://www.rfc-editor.org/info/rfc5656>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
DOI 10.17487/RFC5967, August 2010, <https://www.rfc- DOI 10.17487/RFC5967, August 2010, <https://www.rfc-
editor.org/info/rfc5967>. editor.org/info/rfc5967>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
March 2011, <https://www.rfc-editor.org/info/rfc6187>. March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470, Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
skipping to change at page 14, line 22 skipping to change at page 14, line 44
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[SP800-57] National Institute of Standards and Technology (NIST), [SP800-57] National Institute of Standards and Technology (NIST),
Special Publication 800-57: Recommendation for Key Special Publication 800-57: Recommendation for Key
Management - Part 1 (Revised), March 2007. Management - Part 1 (Revised), March 2007.
Appendix A. Management/Router Channel Security Appendix A. Management/Router Channel Security
Encryption, integrity, authentication, and key exchange algorithms Encryption, integrity, authentication, and key exchange algorithms
used by the secure communication channel SHOULD be of equal or used by the protected channel SHOULD be of equal or greater strength
greater strength than the BGPsec keys they protect, which for the than the BGPsec keys they protect, which for the algorithm specified
algorithm specified in [RFC8208] is 128-bit; see [RFC5480] and by in [RFC8208] is 128-bit; see [RFC5480] and by reference [SP800-57]
reference [SP800-57] for information about this strength claim as for information about this strength claim as well as [RFC3766] for
well as [RFC3766] for "how to determine the length of an asymmetric "how to determine the length of an asymmetric key as a function of a
key as a function of a symmetric key strength requirement." In other symmetric key strength requirement." In other words, for the
words, for the encryption algorithm, do not use export grade crypto encryption algorithm, do not use export grade crypto (40-56 bits of
(40-56 bits of security), do not use Triple DES (112 bits of security), do not use Triple DES (112 bits of security). Suggested
security). Suggested minimum algorithms would be AES-128: aes128-cbc minimum algorithms would be AES-128: aes128-cbc [RFC4253] and
[RFC4253] and AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2- AEAD_AES_128_GCM [RFC5647] for encryption, hmac-sha2-256 [RFC6668] or
256 [RFC6668] or AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa- AESAD_AES_128_GCM [RFC5647] for integrity, ecdsa-sha2-nistp256
sha2-nistp256 [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for authentication, and ecdh-sha2-nistp256 [RFC5656] for
[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 commensurate with BGPsec keys;
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication. authentication.
The protected channel must provide confidentiality, authentication,
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 all of the PKI This appendix is informative. It attempts to explain all of the PKI
technobabble in plainer language. technobabble 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
skipping to change at page 15, line 41 skipping to change at page 16, line 18
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).
Once logged into the router, issue a command or a series of commands Once logged into the router, issue a command or a series of commands
that will generate the key pair for the algorithms noted in the main that will generate the key pair for the algorithms referenced in the
body of this document; consult your router's documentation for the main body of this document; consult your router's documentation for
specific commands. The key generation process will yield multiple the specific commands. The key generation process will yield
files: the private key and the public key; the file format varies multiple files: the private key and the public key; the file format
depending on the arcane command you issued, but generally the files varies depending on the arcane command you issued, but generally the
are DER or PEM-encoded. files are DER or PEM-encoded.
The second step is to generate the certification request, which is The second step is to generate the certification request, which is
often referred to as a certificate signing request (CSR) or PKCS#10, often referred to as a certificate signing request (CSR) or PKCS#10
and to send it to the CA to be signed. To generate the CSR, you certification request, and to send it to the CA to be signed. To
issue some more arcane commands while logged into the router; using generate the CSR, you issue some more arcane commands while logged
the private key just generated to sign the certification request with into the router; using the private key just generated to sign the
the algorithms specified in the main body of this document; the CSR certification request with the algorithms referenced in the main body
is signed to prove to the CA that the router has possession of the of this document; the CSR is signed to prove to the CA that the
private key (i.e., the signature is the proof-of-possession). The router has possession of the private key (i.e., the signature is the
output of the command is the CSR file; the file format varies proof-of-possession). The output of the command is the CSR file; the
depending on the arcane command you issued, but generally the files file format varies depending on the arcane command you issued, but
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 and serial number for the router. The CA needs this
information to issue the certificate. How you get the CSR to the CA, information to issue the certificate. How you get the CSR to the CA,
is beyond the scope of this document. While you are still connected is beyond the scope of this document. While you are still connected
to the router, install the Trust Anchor (TA) for the root of the PKI. to the router, install the Trust Anchor (TA) for the root of the PKI.
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.
skipping to change at page 17, line 7 skipping to change at page 17, line 32
because the private key is being moved over the network. At this because the private key is being moved over the network. At this
point, access to the router is no longer needed for BGPsec-related point, access to the router is no longer needed for BGPsec-related
initiation purposes. initiation purposes.
NOTE: Regardless of the approach taken, the first three steps could NOTE: Regardless of the approach taken, the first three steps could
trivially be collapsed by a vendor-provided script to yield the trivially be collapsed by a vendor-provided script to yield the
private key and the signed CSR. private key and the signed CSR.
Given a GUI-based vendor-assisted management console, then all of Given a GUI-based vendor-assisted management console, then all of
these steps will likely be hidden behind pointing and clicking the these steps will likely be hidden behind pointing and clicking the
way through GPsec-enabling the router. way through BGPsec-enabling the router.
The scenarios described above require the operator to access each The scenarios described above require the operator to access each
router, which does not scale well to large networks. An alternative router, which does not scale well to large networks. An alternative
would be to create an image, perform the necessary steps to get the would be to create an image, perform the necessary steps to get the
private key and trust anchor on the image, and then install the image private key and trust anchor on the image, and then install the image
via a management protocol. via a management protocol.
One final word of advice; certificates include a notAfter field that One final word of advice; certificates include a notAfter field that
unsurprisingly indicates when relying parties should no longer trust unsurprisingly indicates when relying parties should no longer trust
the certificate. To avoid having routers with expired certificates the certificate. To avoid having routers with expired certificates
 End of changes. 55 change blocks. 
137 lines changed or deleted 164 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/