draft-ietf-sidr-rtr-keying-03.txt   draft-ietf-sidr-rtr-keying-04.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 21, 2014 Cisco Systems Expires: June 20, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
September 17, 2013 December 17, 2013
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-03 draft-ietf-sidr-rtr-keying-04
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 31 skipping to change at page 3, line 31
In the router-driven method, once an SSH session is established In the router-driven method, once an SSH session is established
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 transferred to the RPKI CA over the network if the
network if the router supports protocols such as FTP and HTTP router supports protocols such as FTP and HTTP [RFC2585] using the
[RFC2585] using the application/pkcs10 media type [RFC5967] or EST application/pkcs10 media type [RFC5967] or EST (Enrollment over
(Enrollment over Secure Transport) [I-D.ietf-pkix-est]; direct Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that
transfer assumes that the router has direct connectivity to the CA. the router has direct connectivity to the CA. The CA returns a
The CA returns a successful request as a PKCS#7 [I-D.ietf-sidr- successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki-profiles],
bgpsec-pki-profiles], which includes the certificate, and uploads the which includes the certificate, and uploads the certificate to the
certificate to the global RPKI. The response can be returned using global RPKI. The response can be returned using the
the application/pkcs7-mime media type [RFC5751] if the router application/pkcs7-mime media type [RFC5751] if the router supports
supports protocols such as FTP and HTTP. 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 its RPKI software management tools; external network the request to its RPKI software management tools; external network
connectivity is not required when the operator acts as the CA. The connectivity is not required when the operator acts as the CA. The
tools create the certificate and publish the certificate in the tools create the certificate and publish the certificate in the
global RPKI, and return the PKCS#7 to the router; publication of the global RPKI, and return the PKCS#7 to the router; publication of the
certificate in the global RPKI requires external network certificate in the global RPKI requires external network
connectivity. connectivity.
skipping to change at page 4, line 31 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. External network connectivity is not public key in the global RPKI. The only reason global network
required but only to publish the certificate in the global RPKI. The connectivity might be needed would be to publish the certificate in
private key MUST support the algorithm specified in [I-D.ietf-sidr- the global RPKI. The private key MUST support the algorithm
bgpsec-algs], which for ECDSA is specified in [RFC5915]. The PKCS#10 specified in [I-D.ietf-sidr-bgpsec-algs], which for ECDSA is
and PKCS#7 are as specified in [I-D.ietf-sidr-bgpsec-pki-profiles]. 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 6, line 45 skipping to change at page 6, line 46
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, June 2010. Structure", RFC 5915, June 2010.
[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] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGP Algorithms, Key Formats, & Signature Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs (work in progress), Formats", draft-ietf-sidr-bgpsec-algs (work in progress),
March 2013. September 2013.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for 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", and Certification Requests",
draft-ietf-sidr-bgpsec-pki-profiles (work in progress), draft-ietf-sidr-bgpsec-pki-profiles (work in progress),
April 2013. September 2013.
8.2. Informative References 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 (work in progress),
July 2013. December 2013.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", Lepinski, M., "BGPSEC Protocol Specification",
draft-ietf-sidr-bgpsec-protocol (work in progress), draft-ietf-sidr-bgpsec-protocol (work in progress),
February 2013. November 2013.
[I-D.ietf-pkix-est] [I-D.ietf-pkix-est]
Pritikin, M, Yee, P., and D. Harkins "Enrollment over Pritikin, M, Yee, P., and D. Harkins "Enrollment over
Secure Transport", draft-ietf-pkix-est (work in progress), Secure Transport", RFC 7030, October 2013.
August 2013.
[IEEE-802.3] [IEEE-802.3]
ISO/IEC 8802-3 Information technology - ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between Telecommunications and information exchange between
systems - Local and metropolitan area networks - systems - Local and metropolitan area networks -
Common specifications - Part 3: Carrier Sense Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications, 2008. Access Method and Physical Layer Specifications, 2008.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
skipping to change at page 8, line 12 skipping to change at page 8, line 12
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[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)
Base Notifications", RFC 6470, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity
Verification for the Secure Shell (SSH) Transport Layer
Protocol", RFC 6668, July 2012.
Authors' Addresses Authors' Addresses
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: turners@ieca.com
 End of changes. 11 change blocks. 
34 lines changed or deleted 24 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/