draft-ietf-sidr-rtr-keying-09.txt   draft-ietf-sidr-rtr-keying-10.txt 
SIDR Working Group S. Turner Network Working Group R. Bush
Internet-Draft IECA, Inc. Internet-Draft IIJ Lab / Dragon Research Lab
Intended status: BCP K. Patel Intended status: Standards Track S. Turner
Expires: January 21, 2016 Cisco Systems Expires: May 5, 2016 IECA, Inc.
R. Bush K. Patel
Internet Initiative Japan, Inc. Cisco Systems
July 20, 2015 November 2, 2015
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-09 draft-ietf-sidr-rtr-keying-10
Abstract Abstract
BGPsec-speaking routers are provisioned with private keys to sign BGP BGPsec-speaking routers are provisioned with private keys in order to
messages; the corresponding public keys are published in the global sign BGPsec announcements. The corresponding public keys are
RPKI (Resource Public Key Infrastructure) thereby enabling published in the global Resource Public Key Infrastructure, enabling
verification of BGPsec messages. This document describes two ways of verification of BGPsec messages. This document describes two methods
provisioning the public-private key-pairs: router-driven and of generating the public-private key-pairs: router-driven and
operator-driven. operator-driven.
Status of this Memo Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in RFC 2119 [RFC2119] only when they
appear in all upper case. They may also appear in lower or mixed
case as English words, without normative meaning.
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 May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Management / Router Communication . . . . . . . . . . . . . . 3
3. Exchanging Certificates . . . . . . . . . . . . . . . . . . . 4
4. Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. PKCS#10 Generation . . . . . . . . . . . . . . . . . . . . . 4
5.1. Router-Generated Keys . . . . . . . . . . . . . . . . . . 4
5.2. Operator-Generated Keys . . . . . . . . . . . . . . . . . 5
6. Installing Signed Keys . . . . . . . . . . . . . . . . . . . 5
7. Key Management . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Key Validity . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Key Revocation . . . . . . . . . . . . . . . . . . . . . 8
7.4. Router Replacement . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Management/Router Channel Security . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 BGP messages. To verify the signature, allow them to digitally sign BGPsec announcements. To verify the
the public key, in the form of a certificate [I-D.ietf-sidr-bgpsec- signature, the public key, in the form of a certificate
pki-profiles], is published in the RPKI (Resource Public Key [I-D.ietf-sidr-bgpsec-pki-profiles], is published in the Resource
Infrastructure). This document describes two methods for Public Key Infrastructure (RPKI). This document describes
provisioning the necessary public-private key-pairs: router-driven provisioning of BGPsec-speaking routers with the appropriate public-
and operator-driven. private key-pairs. There are two sub-methods, router-driven and
operator-driven.
The difference between the two methods is where the keys are
generated: on the router in the router-driven method and elsewhere in
the operator-driven method. Routers are expected to support either
one, the other, or both methods to work in various deployment
environments. Some routers may not allow the private key to be off-
loaded while other routers may. Off-loading of private keys would
support swapping of routing engines which could then have the same
private key installed in the soon-to-be online engine that had
previously been installed in the soon-to-be removed card.
The remainder of this document describes how operators can use the These two sub-methods differ in where the keys are generated: on the
two methods to provision new and existing routers. router in the router-driven method, and elsewhere in the operator-
driven method. Routers are required to support at least one of the
methods in order to work in various deployment environments. Some
routers may not allow the private key to be off-loaded while others
may. While off-loading private keys would ease swapping of routing
engines, exposure of private keys is a well known security risk.
Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for In the operator-driven method, the operator generates the private/
the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies the public key-pair and sends it to the router, perhaps in a PKCS#8
algorithms used to generate the signature. package [RFC5958].
2. Terminology In the router-driven method, the router generates its own public/
private key-pair, uses the private key to sign a PKCS#10
certification request [I-D.ietf-sidr-bgpsec-pki-profiles], which
includes the public key), and returns the certification request to
the operator to be forwarded to the RPKI Certification Authority
(CA). The CA returns a PKCS#7, which includes the certified public
key in the form of a certificate, to the operator for loading into
the router; and the CA also publishes the certificate in the RPKI.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The router-driven model mirrors the model used by traditional PKI
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to subscribers; the private key never leaves trusted storage (e.g.,
be interpreted as described in RFC 2119 [RFC2119] only when they Hardware Security Module). This is by design and supports classic
appear in all upper case. They may also appear in lower or mixed PKI Certification Policies for (often human) subscribers which
case as English words, without normative meaning. require the private key only ever be controlled by the subscriber to
ensure that no one can impersonate the subscriber. For non-humans,
this model does not always work. For example, when an operator wants
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
soon-to-be offline router. This motivated the operator-driven model.
Readers are assumed to be familiar with the BGPsec protocol [I- The remainder of this document describes how operators can use the
D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the two methods to provision new and existing routers.
RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key
Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I-
D.ietf-sidr-bgpsec-algs].
3. Provisioning a New Router Useful References: [I-D.ietf-sidr-bgpsec-overview] gives an overview
of the BGPsec protocol, [I-D.ietf-sidr-bgpsec-protocol] gives the
gritty details, [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the
format for the PKCS #10 request, and [I-D.ietf-sidr-bgpsec-algs]
specifies the algorithms used to generate the signature.
Depending on the options supported by the new router, operators are 2. Management / Router Communication
free to use either the router-driven or operator-driven methods.
Regardless of the method chosen, operators first establish a secure Operators are free to use either the router-driven or operator-driven
communication channel (e.g., via SSH (Secure Shell)) between the method as supported by the platform. Regardless of the method
operator's management platform and the router to allow the operator chosen, operators first establish a secure communication channel
to securely use the Command Line Interface (CLI). How this channel between the management system and the router. How this channel is
is established is router-specific and is not in scope of this established is router-specific and is beyond scope of this document.
document. Though other configuration mechanisms might be used, e.g.
NetConf (see [RFC6470]), in the remainder of this document, the
secure communication channel between the server and the router is
assumed to be an SSH-protected CLI.
Encryption, integrity, authentication, and key exchange algorithms Though other configuration mechanisms might be used, e.g. NetConf
used by the secure communication channel SHOULD be of comparable (see [RFC6470]); for simplicity, in this document, the communication
strength to BGPsec keys, which currently is 128-bit, or stronger than channel between the management platform and the router is assumed to
BGPsec keys. In other words for the encryption algorithm, do not use be an SSH-protected CLI. See Appendix A for security considerations
export grade crypto (40-56 bits of security), do not use Triple DES for this channel.
(112 bits of security), do use something like or better than AES-128:
aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647]; for integrity
use something like hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM
[RFC5647]; for authentication use something like ecdsa-sha2-nistp256
[RFC5656], and; for key exchange use something like ecdh-sha2-
nistp256 [RFC5656].
Note that some routers support the use of public key certificates and 3. Exchanging Certificates
SSH. The certificates used for the SSH session are different than
the certificates used for BGPsec. The certificates used with SSH
should also enable a level of security commensurate with BGPsec keys;
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication.
3.1. Router-Generated Keys The operator management station can exchange certificate requests and
certificates with routers and with the RPKI CA infrastructure using
the application/pkcs10 media type [RFC5967] and application/
pkcs7-mime [RFC5751], respectively, and may use FTP or HTTP per
[RFC2585], or the Enrollment over Secure Transport [RFC7030].
In the router-driven method, once the SSH-protected CLI session is 4. Set-Up
established between the operator and the router, 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 the PKCS#10
with the private key. Once generated, the PKCS#10, which includes
the public key the router wants certified, is transmitted to the RPKI
CA for the CA to certify. This can be via a number of means, two of
which might be as follows:
o Through the SSH-protected CLI session with the operator's RPKI To start, the operator uses the communication channel to install the
management platform: The operator off-loads the PKCS#10 and appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.
uploads the request to the CA. If the CA is operated by an This will later enable the router to validate the router certificate
external entity, external network connectivity likely is returned in the PKCS#7.
required.
o Between the router and the CA: The operator, through a command or The operator also configures the Autonomous System (AS) number to be
commands, prompts the router to send/transfer the PKCS#10 request used in the generated router certificate. This may be the sole AS
to the CA over the network. Obviously for this to work, the configured on the router, or an operator choice if the router is
router requires network connectivity with the CA and if the CA is configured with multiple ASs.
operated by an external entity external network connectivity may
be required.
After the CA certifies the key, it does two things: The operator configures or extracts from the router the BGP RouterID
to be used in the generated certificate. In the case where the
operator has chosen not to use unique per-router certificates, a
RouterID of 0 may be used.
o Publishes the certificate in the Global RPKI. The CA must have 5. PKCS#10 Generation
connectivity to the relevant publication point, which in turn
must have external network connectivity as it is part of the
Global RPKI.
o Returns the certificate to the operator's management station or The private key, and hence the PKCS#10 request may be generated by
to the router, normally packaged in a PKCS#7, using the the router or by the operator.
corresponding method by which it received the certificate
request.
With network connectivity, the router and CA can exchange the 5.1. Router-Generated Keys
certificate request and the certificate using the application/pkcs10
media type [RFC5967] and application/pkcs7-mime [RFC5751],
respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST
(Enrollment over Secure Transport) [RFC7030].
The router SHOULD extract the certificate from the PCKCS#7 and verify In the router-generated method, once the protected session is
that the private key it holds corresponds to the returned public key. established and the initial Set-Up (Section 4) performed, the
The router SHOULD inform the operator that the certificate was operator issues a command or commands for the router to generate the
received; by some mechanism which is out of scope of this document. public/private key pair, to generate the PKCS#10 request, and to sign
The router SHOULD inform the operator whether or not the keys the PKCS#10 with the private key. Once generated, the PKCS#10 is
correspond, again by a mechanism which is out of scope for this returned to the operator over the protected channel.
document.
The router SHOULD also verify that the returned certificate validates If a router was to communicate directly with a CA to have the CA
back to a trust anchor. To perform this verification either the CA's certify the PKCS#10, there would be no way for the CA to authenticate
certificate needs to be installed on the router via the CLI or the the router. As the operator knows the authenticity of the router,
CA's certificate needs to be returned along with the router's the operator must mediate the communication with the CA.
certificate in the PKCS#7. The router SHOULD inform the operator
whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope. After performing these
checks, the router need not retain the CA's certificate because the
certificate is not transmitted as part of BGPsec messages.
Note that even if the operator cannot extract the private key from The operator adds the chosen AS number and the RouterID to send to
the router, this signature still provides a linkage between a private the RPKI CA for the CA to certify.
key and a router. That is the server can verify the proof of
possession (POP), as required by [RFC6484].
3.2. Operator-Generated Keys 5.2. Operator-Generated Keys
In the operator-driven method, the operator generates the
public/private key pair and installs the private key into the router
over the SSH-protected CLI session. Note that cut/copy and paste
operations for keys over a certain sizes are error-prone.
The operator uses RPKI management tools to generate the keys, the In the operator-generated method, the operator generates the public/
PKCS#10 certification request, the certificate, and the PKCS#7 private key pair on a management station and installs the private key
certification response, as well as publishing the certificate in the into the router over the protected channel. Beware that experience
Global RPKI. External network connectivity may be needed if the has shown that copy and paste from a management station to a router
certificate is to be published in the Global RPKI. can be unreliable for long texts.
Along with the PKCS#7, the operator returns the private key. The Alternatively, the private key may be encapsulated in a PKCS #8
private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is [RFC5958], the PKCS#8 is further encapsulated in Cryptographic
further encapsulated in CMS (Cryptographic Message Syntax) SignedData Message Syntax (CMS) SignedData [RFC5652], and signed by the AS's End
[RFC5652], and signed by the AS's EE (End Entity) certificate. Entity (EE) certificate.
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.
The operator then creates and signs the PKCS#10 with the private key,
and adds the chosen AS number and RouterID to be sent to the RPKI CA
for the CA to certify.
6. Installing Signed Keys
The operator uses RPKI management tools to communicate with the
global RPKI system to have the appropriate CA validate the PKCS#10
request, sign the key in the PKCS#10 and generated PKCS#7 response,
as well as publishing the certificate in the Global RPKI. External
network connectivity may be needed if the certificate is to be
published in the Global RPKI.
After the CA certifies the key, it does two things:
1. Publishes the certificate in the Global RPKI. The CA must have
connectivity to the relevant publication point, which in turn
must have external network connectivity as it is part of the
Global RPKI.
2. Returns the certificate to the operator's management station,
packaged in a PKCS#7, using the corresponding method by which it
received the certificate request. It SHOULD include the
certificate chain below the TA Certificate so that the router can
validate the router certificate.
In the operator-generated method, the operator SHOULD extract the
certificate from the PKCS#7, and verify that the private key it holds
corresponds to the returned public key.
In the operator-generated method, the operator has already installed
the private key in the router (see Section 5.2).
The operator provisions the PKCS#7 into the router over the secure
channel.
The router SHOULD extract the certificate from the PKCS#7 and verify The router SHOULD extract the certificate from the PKCS#7 and verify
that the private key corresponds to the returned public key. The that the private key corresponds to the returned public key. The
router SHOULD inform the operator whether it successfully received router SHOULD inform the operator whether it successfully received
the certificate; this mechanism is out of scope. The router should the certificate and whether or not the keys correspond; the mechanism
inform the operator whether or not the keys correspond; this is out of scope.
mechanism is out of scope. The router SHOULD also verify the
returned certificate back to a trust anchor, but to perform this The router SHOULD also verify that the returned certificate validates
verification either the CA's certificate needs to be installed on the back to the installed TA Certificate, i.e., the entire chain from the
router via the CLI or the CA's certificate needs to be returned along installed TA Certificate through subordinate CAs to the BGPsec
with the router's certificate in the PKCS#7. The router SHOULD certificate validate. To perform this verification the CA
inform the operator whether or not the signature validates to a trust certificate chain needs to be returned along with the router's
anchor; this notification mechanism is out of scope. After certificate in the PKCS#7. The router SHOULD inform the operator
performing these checks, the router need not retain the CA whether or not the signature validates to a trust anchor; this
certificate. 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 CA. configurations where the entity that generates the keys is not the
direct CA.
4. Key Management Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a
router. That is the server can verify the proof of possession (POP),
as required by [RFC6484].
7. Key Management
An operator's responsibilities do not end after key generation, key An operator's responsibilities do not end after key generation, key
provisioning, certificate issuance, and certificate distribution. provisioning, certificate issuance, and certificate distribution.
They persist for as long as the operator wishes to operate the They persist for as long as the operator wishes to operate the
BGPsec-speaking router. BGPsec-speaking router.
Paramount to maintaining a router that can be a continuous BPGsec 7.1. Key Validity
speaker is ensuring that the router has a valid certificate at all
times. To ensure this, the operator needs to ensure the router It is critical that a BGPsec speaking router ensures that it is
always has a non-expired certificate. That is the key used when BGP- signing with a valid certificate at all times. To this end, the
speaking always has an associated certificate whose expiry time is operator needs to ensure the router always has a non-expired
after the current time. certificate. I.e. the key used to sign BGPsec announcements always
has an associated certificate 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:
o 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
o 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. It is calendaring program to remind them of the expiry time, and/or
advisable that the expiration warning happen well in advance of
the actual expiry time, and/or
o The RPKI CA warns the operaor of pending expiration, and/or 3. The RPKI CA warns the operator of pending expiration, and/or
o Use some other kind of automated process to search for and track 4. Use some other kind of automated process to search for and track
the expiry times of router certificates. the expiry times of router certificates.
It is advisable that expiration warnings happen well in advance of
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.
Depending on inter-operator relationship, it may be appropriate to Depending on inter-operator relationship, it may be helpful to notify
notify a peer operator that one or more of their certificates are a peer operator that one or more of their certificates are about to
about to expire. expire.
7.2. Key Roll-Over
Routers that support multiple private keys also greatly increase the Routers that support multiple private keys also greatly increase the
chance that routers can continuously speak BGPsec because the new chance that routers can continuously speak BGPsec because the new
private key and certificate can be obtained prior to expiration of private key and certificate can be obtained and distributed prior to
the operational key. Obviously, the router needs to know when to expiration of the operational key. Obviously, the router needs to
start using the new key. Once the new key is being used, having the know when to start using the new key. Once the new key is being
already distributed certificate ensures continuous operation. used, having the already distributed certificate ensures continuous
operation.
Whether the certificate is rekeyed (i.e., different key in the Whether the certificate is re-keyed (i.e., different key in the
certificate with a new expiry time) or renewed (i.e., the same key in certificate with a new expiry time) or renewed (i.e., the same key in
the certificate with a new expiry time) depends on the key's lifetime the certificate with a new expiry time) depends on the key's lifetime
and operational use. Arguably, rekeying the router's BGPsec and operational use. Arguably, re-keying the router's BGPsec
certificate every time the certificate expires is more secure than certificate every time the certificate expires is more secure than
renewal because it limits the private key's exposure. However, if renewal because it limits the private key's exposure. However, if
the key is not compromised the certificate could be renewed as many the key is not compromised the certificate could be renewed as many
times as allowed by the operator's security policy. Routers that times as allowed by the operator's security policy. Routers that
support only one key can use renewal to ensure continuous operation, support only one key can use renewal to ensure continuous operation,
assuming the certificate is renewed and distributed prior to the assuming the certificate is renewed and distributed well in advance
operational's certificate expiry time. of the operational certificate's expiry time.
Certain unfortunate circumstances exist when the operator will need 7.3. Key Revocation
to revoke the router's BGPsec certificate. When this occurs, the
operator needs to use the RPKI CA system to revoke the certificate by
placing the router's BGPsec certificate on the CRL (Certificate
Revocation List) as well as rekeying the router's certificate.
When it is decided that an active router key is to be revoked, the Certain unfortunate circumstances may occur causing a need to revoke
process of requesting the CA to revoke, the process of the CA a router's BGPsec certificate. When this occurs, the operator needs
actually revoking the router's certificate, and then the process of to use the RPKI CA system to revoke the certificate by placing the
rekeying/renewing the router's certificate, (possibly distributing a router's BGPsec certificate on the Certificate Revocation List (CRL)
new key and certificate to the router), and distributing the status as well as re-keying the router's certificate.
takes time during which the operator must decide how they wish to
maintain continuity of operations, with or without the compromised When an active router key is to be revoked, the process of requesting
private key, or whether they wish to bring the router offline to the CA to revoke, the process of the CA actually revoking the
address the compromise. router's certificate, and then the process of re-keying/renewing the
router's certificate, (possibly distributing a new key and
certificate to the router), and distributing the status takes time
during which the operator must decide how they wish to maintain
continuity of operations, with or without the compromised private
key, or whether they wish to bring the router offline to address the
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 disabling 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 the other(s) are soon-to-be-opertional, 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 new soon-to-be-operational key, the compromised key, and then make a next generation soon-to-be-
all hopefully without needing to take offline or reboot the router. operational key, all hopefully without needing to take offline or
For routers which support only one operational key, the operators reboot the router. For routers which support only one operational
should create or install the new private key, and then request key, the operators should create or install the new private key, and
revocation of the compromised private key. then request revocation of the compromised private key.
5. Other Use Cases 7.4. Router Replacement
Current router code generates private keys for uses such as SSH, but Currently routers often generate private keys for uses such as SSH,
the private keys may not be seen or off-loaded via the SSH-protected and the private keys may not be seen or off-loaded from the router.
CLI session or any other means. While this is good security, it While this is good security, it creates difficulties when a routing
creates difficulties when a routing engine or whole router must be engine or whole router must be replaced in the field and all software
replaced in the field and all software which accesses the router must which accesses the router must be updated with the new keys. Also,
be updated with the new keys. Also, any network based initial contact any network based initial contact with a new routing engine requires
with a new routing engine requires trust in the public key presented trust in the public key presented on first contact.
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 be off-loaded via the routers SHOULD allow the private BGPsec key to be off-loaded via a
SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the protected session, e.g. SSH, NetConf (see [RFC6470]), SNMP, etc.
operator upload the old private key via the mechanism used for This lets the operator upload the old private key via the mechanism
operator-generated keys, see Section 3.2. used for operator-generated keys, see Section 5.2.
6. Security Considerations 8. Security Considerations
Operator-generated keys could be intercepted in transport and the The router's manual will describe whether the router supports one,
recipient router would have no way of knowing a substitution had been the other, or both of the key generation options discussed in the
made or that the key had been disclosed by a monkey in the middle. earlier sections of this draft as well as other important security-
Hence transport security is strongly RECOMMENDED. As noted in related information (e.g., how to SSH to the router). After
Section 3, the level of security provided by the transport security familiarizing one's self with the capabilities of the router,
SHOULD be commensurate with the BGPsec key. Additionally, operators operators are encouraged to ensure that the router is patched with
SHOULD ensure the transport security implementation is up to date and the latest software updates available from the manufacturer.
addresses all known implementation bugs.
All generated key pairs MUST be generated from a good source of non- This document defines no protocols so in some sense introduces no new
deterministic random input [RFC4086] and the private key MUST be security considerations. However, it relies on many others and the
protected in a secure fashion. Disclosure of the private key leads security considerations in the referenced documents should be
to masquerade [RFC4949]. The local storage format for the private consulted; notably, those document listed in Section 1 should be
key is a local matter. consulted first. PKI-relying protocols, of which BGPsec is one, have
many issues to consider so many in fact entire books have been
written to address them; so listing all PKI-related security
considerations is neither useful nor helpful; regardless, some boot-
strapping-related issues are listed here that are worth repeating:
Public-Private key pair generation: Mistakes here are for all
practical purposes catastrophic because PKIs rely on the pairing
of a difficult to generate public-private key pair with a signer;
all key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086].
Private key protection at rest: Mistakes here are for all practical
purposes catastrophic because disclosure of the private key allows
another entity to masquerade as (i.e., impersonate) the signer;
all private keys MUST be protected when at rest in a secure
fashion. Obviously, how each router protects private keys is
implementation specific. Likewise, the local storage format for
the private key is just that, a local matter.
Private key protection in transit: Mistakes here are for all
practical purposes catastrophic because disclosure of the private
key allows another entity to masquerade as (i.e., impersonate) the
signer; transport security is therefore strongly RECOMMENDED. The
level of security provided by the transport layer's security
mechanism SHOULD be commensurate with the strength of the BGPsec
key; there's no point in spending time and energy to generate an
excellent public-private key pair and then transmit the private
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.
Additionally, operators SHOULD ensure the transport security
mechanism is up to date, in order to addresses all known
implementation bugs.
SSH key management is known, in some cases, to be lax
[I-D.ylonen-sshkeybcp]; employees that no longer need access to
routers SHOULD be removed the router to ensure only those authorized
have access to a router.
Though the CA's certificate is installed on the router and used to Though the CA's certificate is installed on the router and used to
verify 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 not checked. The revocation status of the CA's certificate is rarely checked as 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 installed CA certificate is valid.
Operators need to manage their SSH keys to ensure only those 9. IANA Considerations
authorized to access the router may do so. As employees no longer
need access to the router, their keys SHOULD be removed from the
router.
7. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
8. References 10. References
8.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs-04 (work in
progress), March 2013.
[I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-04 (work in progress), October 2012.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
"Randomness Requirements for Security", BCP 106, RFC 4086, Requirements for Security", BCP 106, RFC 4086, June 2005.
June 2005.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
2010. 2010.
[I-D.ietf-sidr-bgpsec-algs] 10.2. Informative References
Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs (work in progress).
[I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests",
draft-ietf-sidr-bgpsec-pki-profiles (work in progress).
8.2. Informative References
[I-D.ietf-sidr-bgpsec-overview] [I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC", Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-ietf-sidr-bgpsec-overview (work in progress). draft-ietf-sidr-bgpsec-overview-02 (work in progress), May
2012.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", Lepinski, M., "BGPSEC Protocol Specification", draft-ietf-
draft-ietf-sidr-bgpsec-protocol (work in progress). sidr-bgpsec-protocol-07 (work in progress), February 2013.
[I-D.ylonen-sshkeybcp]
Ylonen, T. and G. Kent, "Managing SSH Keys for Automated
Access - Current Recommended Practice", draft-ylonen-
sshkeybcp-01 (work in progress), April 2013.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Transport Layer Protocol", RFC 4253, January 2006. Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
36, RFC 4949, August 2007. "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[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, August Secure Shell Transport Layer Protocol", RFC 5647, August
2009. 2009.
[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, December 2009. RFC 5656, December 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
skipping to change at page 10, line 27 skipping to change at page 12, line 14
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
August 2010. August 2010.
[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, March 2011. Shell Authentication", RFC 6187, March 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012. Base Notifications", RFC 6470, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource Public Key Infrastructure Policy (CP) for the Resource Public Key Infrastructure
(RPKI)", BCP 173, RFC 6484, February 2012. (RPKI)", BCP 173, RFC 6484, February 2012.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity [RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity
Verification for the Secure Shell (SSH) Transport Layer Verification for the Secure Shell (SSH) Transport Layer
Protocol", RFC 6668, July 2012. Protocol", RFC 6668, July 2012.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, October "Enrollment over Secure Transport", RFC 7030,
2013. DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>.
Appendix A. Management/Router Channel Security
Encryption, integrity, authentication, and key exchange algorithms
used by the secure communication channel SHOULD be of equal or
greater strength than the BGPsec keys they protect, which for the
algorithm specified in [I-D.ietf-sidr-bgpsec-algs] is 128-bit; see
[RFC5480] and by reference [SP800-57] for information about this
strength claim as well as [RFC3766] for "how to determine the length
of an asymmetric key as a function of a symmetric key strength
requirement." In other words, for the encryption algorithm, do not
use export grade crypto (40-56 bits of security), do not use Triple
DES (112 bits of security). Suggested minimum algorithms would be
AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for
encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647]
for integrity, ecdsa-sha2-nistp256 [RFC5656] for authentication, and
ecdh-sha2-nistp256 [RFC5656] for key exchange.
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 BGPsec. The certificates used with SSH should
also enable a level of security commensurate with BGPsec keys;
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication.
Authors' Addresses Authors' Addresses
Randy Bush
IIJ / Dragon Research Labs
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Email: randy@psg.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, Virginia 22031 Fairfax, Virginia 22031
US US
Email: turners@ieca.com Email: sean@sn3rd.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 West Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Randy Bush
Internet Initiative Japan, Inc.
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Phone: +1 206 780 0431 x1
Email: randy@psg.com
 End of changes. 76 change blocks. 
269 lines changed or deleted 390 lines changed or added

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