draft-ietf-sidr-rtr-keying-02.txt   draft-ietf-sidr-rtr-keying-03.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: March 16, 2014 Cisco Systems Expires: March 21, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
September 12, 2013 September 17, 2013
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-02 draft-ietf-sidr-rtr-keying-03
Abstract Abstract
BGPsec-speaking routers must be provisioned with private keys and the BGPsec-speaking routers must be provisioned with private keys and the
corresponding public key must be published in the global RPKI corresponding public key must be published in the global RPKI
(Resource Public Key Infrastructure). This document describes two (Resource Public Key Infrastructure). This document describes two
ways of provisioning public/private keys, router-driven and operator- ways of provisioning public/private keys, router-driven and operator-
driven. driven.
Status of this Memo Status of this Memo
skipping to change at page 3, line 32 skipping to change at page 3, line 32
between the operator and the router the operator issues a command, or between the operator and the router the operator issues a command, or
commands, to generate the public/private key pair on the router, to commands, to generate the public/private key pair on the router, to
generate the PKCS#10 request that includes the router number and generate the PKCS#10 request that includes the router number and
public key, and to sign the PKCS#10 with the private key. [I-D.ietf- public key, and to sign the PKCS#10 with the private key. [I-D.ietf-
sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10 sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10
request and the algorithm used to generate the signature is specified request and the algorithm used to generate the signature is specified
in [I-D.ietf-sidr-bgpsec-algs]. in [I-D.ietf-sidr-bgpsec-algs].
The PKCS#10 request, which includes the public key the router wants The PKCS#10 request, which includes the public key the router wants
certified, can be directly transferred to the RPKI CA over the certified, can be directly transferred to the RPKI CA over the
Ethernet port if the router supports protocols such as FTP and HTTP network if the router supports protocols such as FTP and HTTP
[RFC2585] using the application/pkcs10 media type [RFC5967] or EST [RFC2585] using the application/pkcs10 media type [RFC5967] or EST
(Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA (Enrollment over Secure Transport) [I-D.ietf-pkix-est]; direct
returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki- transfer assumes that the router has direct connectivity to the CA.
profiles], which includes the certificate, and uploads the The CA returns a successful request as a PKCS#7 [I-D.ietf-sidr-
bgpsec-pki-profiles], which includes the certificate, and uploads the
certificate to the global RPKI. The response can be returned using certificate to the global RPKI. The response can be returned using
the application/pkcs7-mime media type [RFC5751] if the router the application/pkcs7-mime media type [RFC5751] if the router
supports protocols such as FTP and HTTP. supports protocols such as FTP and HTTP.
The PKCS#10 request can also be indirectly transferred to the RPKI CA The PKCS#10 request can also be indirectly transferred to the RPKI CA
through the operator. The operator off-loads the PKCS#10 and uploads through the operator. The operator off-loads the PKCS#10 and uploads
the request to their RPKI software management tools. The tools the request to its RPKI software management tools; external network
create and publish the certificate for the public key, and return the connectivity is not required when the operator acts as the CA. The
PKCS#7 to the router. tools create the certificate and publish the certificate in the
global RPKI, and return the PKCS#7 to the router; publication of the
certificate in the global RPKI requires external network
connectivity.
The router SHOULD extract the certificate from the PCKCS#7 and verify The router SHOULD extract the certificate from the PCKCS#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 that it has successfully received router SHOULD inform the operator that it has successfully received
its certificate; this mechanism is out of scope. When the keys do its certificate; this mechanism is out of scope. When the keys do
not correspond, the router SHOULD inform the operator; this mechanism not correspond, the router SHOULD inform the operator; this mechanism
is out of scope. The router SHOULD also verify the returned is out of scope. The router SHOULD also verify the returned
certificate back to a trust anchor, but to perform this verification certificate back to a trust anchor, but to perform this verification
either the CA's certificate needs to be installed on the router via either the CA's certificate needs to be installed on the router via
the CLI or the CA's certificate needs to be returned along with the the CLI or the CA's certificate needs to be returned along with the
skipping to change at page 4, line 27 skipping to change at page 4, line 31
3.2. Operator-Generated Keys 3.2. Operator-Generated Keys
In the operator-driven method, the operator generates the private key In the operator-driven method, the operator generates the private key
and it is installed over the SSH connection established between the and it is installed over the SSH connection established between the
operator and the router. Note that cut/copy and paste operations for operator and the router. Note that cut/copy and paste operations for
keys over a certain sizes is error-prone. keys over a certain sizes is error-prone.
The operator uses their RPKI management tools to generate the keys, The operator uses their RPKI management tools to generate the keys,
the PKCS#10 certification request, the certificate, and the PKCS#7 the PKCS#10 certification request, the certificate, and the PKCS#7
certification response as well as publish the certificate for the certification response as well as publish the certificate for the
public key in the global RPKI. The private key MUST support the public key in the global RPKI. External network connectivity is not
algorithm specified in [I-D.ietf-sidr-bgpsec-algs], which for ECDSA required but only to publish the certificate in the global RPKI. The
is specified in [RFC5915]. The PKCS#10 and PKCS#7 are as specified private key MUST support the algorithm specified in [I-D.ietf-sidr-
in [I-D.ietf-sidr-bgpsec-pki-profiles]. bgpsec-algs], which for ECDSA is specified in [RFC5915]. The PKCS#10
and PKCS#7 are as specified in [I-D.ietf-sidr-bgpsec-pki-profiles].
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 a CMS (Cryptographic Message Syntax) further encapsulated in a CMS (Cryptographic Message Syntax)
SignedData [RFC5652], and signed by the operator's EE certificate. SignedData [RFC5652], and signed by the operator's EE certificate.
The router SHOULD verify the signature on the encapsulated PKCS#8 to The router SHOULD verify the signature on the encapsulated PKCS#8 to
ensure the returned private key in fact came from the operator, but ensure the returned private key in fact came from the operator, but
this requires that the operator also provision via the CLI or include this requires that the operator also provision via the CLI or include
in the SignedData the RPKI CA certificates and operator's EE in the SignedData the RPKI CA certificates and operator's EE
skipping to change at page 5, line 11 skipping to change at page 5, line 16
not correspond, the router SHOULD inform the operator; this mechanism not correspond, the router SHOULD inform the operator; this mechanism
is out of scope. The router SHOULD also verify the returned is out of scope. The router SHOULD also verify the returned
certificate back to a trust anchor, but to perform this verification certificate back to a trust anchor, but to perform this verification
either the CA's certificate needs to be installed on the router via either the CA's certificate needs to be installed on the router via
the CLI or the CA's certificate needs to be returned along with the the CLI or the CA's certificate needs to be returned along with the
router's certificate in the PKCS#7. The router SHOULD inform the router's certificate in the PKCS#7. The router SHOULD inform the
operator if the signature does not validate to a trust anchor; this operator if the signature does not validate to a trust anchor; this
notification mechanism is out of scope. After performing these notification mechanism is out of scope. After performing these
checks, the router need not retain the certificate. checks, the router need not retain the certificate.
4. Key rollover
TBD
5. Other Use Cases 5. Other Use Cases
Current router code generates private keys for uses such as SSH, but Current router code generates private keys for uses such as SSH, but
the private keys may not be seen or off-loaded via CLI or any other the private keys may not be seen or off-loaded via CLI or any other
means. While this is good security, it creates difficulties when a means. While this is good security, it creates difficulties when a
routing engine or whole router must be replaced in the field and all routing engine or whole router must be replaced in the field and all
software which accesses the router must be updated with the new keys. software which accesses the router must be updated with the new keys.
Also, the initial contact with a new routing engine requires trust in Also, the initial contact with a new routing engine requires trust in
the public key presented on first contact. the public key presented on first contact.
 End of changes. 8 change blocks. 
14 lines changed or deleted 23 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/