draft-ietf-sidr-rtr-keying-06.txt   draft-ietf-sidr-rtr-keying-07.txt 
SIDR Working Group S. Turner SIDR Working Group S. Turner
Internet-Draft IECA, Inc. Internet-Draft IECA, Inc.
Intended status: BCP K. Patel Intended status: BCP K. Patel
Expires: November 21, 2014 Cisco Systems Expires: November 24, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
May 20, 2014 May 23, 2014
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-06 draft-ietf-sidr-rtr-keying-07
Abstract Abstract
BGPsec-speaking routers are provisioned with private keys to sign BGP BGPsec-speaking routers are provisioned with private keys to sign BGP
messages; the corresponding public keys are published in the global messages; the corresponding public keys are published in the global
RPKI (Resource Public Key Infrastructure) thereby enabling RPKI (Resource Public Key Infrastructure) thereby enabling
verification of BGPsec messages. This document describes two ways of verification of BGPsec messages. This document describes two ways of
provisioning the public-private key-pairs: router-driven and provisioning the public-private key-pairs: router-driven and
operator-driven. operator-driven.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
case as English words, without normative meaning. case as English words, without normative meaning.
Readers are assumed to be familiar with the BGPsec protocol [I- Readers are assumed to be familiar with the BGPsec protocol [I-
D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the
RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key
Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I- Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I-
D.ietf-sidr-bgpsec-algs]. D.ietf-sidr-bgpsec-algs].
3. Provisioning a New Router 3. Provisioning a New Router
Depending on the options supported by the new router, operators are Depending on the options supported by the new router, operators are
free to use either the router-driven or operator-drive methods. free to use either the router-driven or operator-driven methods.
Regardless of the method chosen, operators first establish a secure Regardless of the method chosen, operators first establish a secure
communication channel (e.g., via SSH (Secure Shell)) between the communication channel (e.g., via SSH (Secure Shell)) between the
operator's management platform and the router to allow the operator operator's management platform and the router to allow the operator
to securely use the Command Line Interface (CLI). How this channel to securely use the Command Line Interface (CLI). How this channel
is established is router-specific and is not in scope of this is established is router-specific and is not in scope of this
document. Though other configuration mechanisms might be used, e.g. document. Though other configuration mechanisms might be used, e.g.
NetConf (see [RFC6470]), in the remainder of this document, the NetConf (see [RFC6470]), in the remainder of this document, the
secure communication channel between the server and the router is secure communication channel between the server and the router is
assumed to be an SSH-protected CLI. assumed to be an SSH-protected CLI.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
Note that even if the operator cannot extract the private key from Note that even if the operator cannot extract the private key from
the router, this signature still provides a linkage between a private the router, this signature still provides a linkage between a private
key and a router. That is the server can verify the proof of key and a router. That is the server can verify the proof of
possession (POP), as required by [RFC6484]. possession (POP), as required by [RFC6484].
3.2. Operator-Generated Keys 3.2. Operator-Generated Keys
In the operator-driven method, the operator generates the In the operator-driven method, the operator generates the
public/private key pair and installs the private key into the router public/private key pair and installs the private key into the router
over the SSH-protected CLI session. Note that cut/copy and paste over the SSH-protected CLI session. Note that cut/copy and paste
operations for keys over a certain sizes is error-prone. operations for keys over a certain sizes are error-prone.
The operator uses RPKI management tools to generate the keys, the The operator uses RPKI management tools to generate the keys, the
PKCS#10 certification request, the certificate, and the PKCS#7 PKCS#10 certification request, the certificate, and the PKCS#7
certification response, as well as publishing the certificate in the certification response, as well as publishing the certificate in the
Global RPKI. External network connectivity may needed if the Global RPKI. External network connectivity may be needed if the
certificate is to be published in the Global RPKI. certificate is to be published in the Global RPKI.
Along with the PKCS#7, the operator returns the private key. The Along with the PKCS#7, the operator returns the private key. The
private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is
further encapsulated in CMS (Cryptographic Message Syntax) SignedData further encapsulated in CMS (Cryptographic Message Syntax) SignedData
[RFC5652], and signed by the AS's EE (End Entity) certificate. [RFC5652], and signed by the AS's EE (End Entity) 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 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; this mechanism is out of scope. The router should
inform the operator whether or not the keys correspond; this inform the operator whether or not the keys correspond; this
mechanism is out of scope. The router SHOULD also verify the mechanism is out of scope. The router SHOULD also verify the
returned certificate back to a trust anchor, but to perform this returned certificate back to a trust anchor, but to perform this
skipping to change at page 7, line 24 skipping to change at page 7, line 24
placing the router's BGPsec certificate on the CRL (Certificate placing the router's BGPsec certificate on the CRL (Certificate
Revocation List) as well as rekeying the router's 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 When it is decided that an active router key is to be revoked, the
process of requesting the CA to revoke, the process of the CA process of requesting the CA to revoke, the process of the CA
actually revoking the router's certificate, and then the process of actually revoking the router's certificate, and then the process of
rekeying/renewing the router's certificate, (possibly distributing a rekeying/renewing the router's certificate, (possibly distributing a
new key and certificate to the router), and distributing the status new key and certificate to the router), and distributing the status
takes time during which the operator must decide how they wish to takes time during which the operator must decide how they wish to
maintain continuity of operations, with or without the compromised maintain continuity of operations, with or without the compromised
private key, or whether they wish to to bring the router offline to private key, or whether they wish to bring the router offline to
address the compromise. 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 the other(s) are soon-to-be-opertional, facilitate
revocation events because the operator can configure the router to revocation events because the operator can configure the router to
 End of changes. 8 change blocks. 
8 lines changed or deleted 8 lines changed or added

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