draft-ietf-sidr-rtr-keying-05.txt   draft-ietf-sidr-rtr-keying-06.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: October 31, 2014 Cisco Systems Expires: November 21, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
April 29, 2014 May 20, 2014
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-05 draft-ietf-sidr-rtr-keying-06
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 4, line 28 skipping to change at page 4, line 28
o Returns the certificate to the operator's management station or o Returns the certificate to the operator's management station or
to the router, normally packaged in a PKCS#7, using the to the router, normally packaged in a PKCS#7, using the
corresponding method by which it received the certificate corresponding method by which it received the certificate
request. request.
With network connectivity, the router and CA can exchange the With network connectivity, the router and CA can exchange the
certificate request and the certificate using the application/pkcs10 certificate request and the certificate using the application/pkcs10
media type [RFC5967] and application/pkcs7-mime [RFC5751], media type [RFC5967] and application/pkcs7-mime [RFC5751],
respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST
(Enrollment over Secure Transport) [I-D.ietf-pkix-est]. (Enrollment over Secure Transport) [RFC7030].
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 it holds corresponds to the returned public key. that the private key it holds corresponds to the returned public key.
The router SHOULD inform the operator that the certificate was The router SHOULD inform the operator that the certificate was
received; by some mechanism which is out of scope of this document. received; by some mechanism which is out of scope of this document.
The router SHOULD inform the operator whether or not the keys The router SHOULD inform the operator whether or not the keys
correspond, again by a mechanism which is out of scope for this correspond, again by a mechanism which is out of scope for this
document. document.
The router SHOULD also verify that the returned certificate validates The router SHOULD also verify that the returned certificate validates
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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 prior to the
operational's certificate expiry time. operational's certificate expiry time.
Certain unfortunate circumstances exist when the operator will need Certain unfortunate circumstances exist when the operator will need
to revoke the router's BGPsec certificate. When this occurs, the to revoke the router's BGPsec certificate. When this occurs, the
operator needs to use the RPKI CA system to revoke the certificate by operator needs to use the RPKI CA system to revoke the certificate by
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
process of requesting the CA to revoke, the process of the CA
actually revoking the router's certificate, and then the process of
rekeying/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 to bring the router offline to
address the compromise.
Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the
router to disabling BGPsec is likely preferred to bringing the router
offline.
Routers which support more than one private key, where one is
operational and the other(s) are soon-to-be-opertional, facilitate
revocation events because the operator can configure the router to
make a soon-to-be-operational key operational, request revocation of
the compromised key, and then make a new soon-to-be-operational key,
all hopefully without needing to take offline or reboot the router.
For routers which support only one operational key, the operators
should create or install the new private key, and then request
revocation of the compromised private key.
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 the SSH-protected the private keys may not be seen or off-loaded via the SSH-protected
CLI session or any other means. While this is good security, it CLI session or any other means. While this is good security, it
creates difficulties when a routing engine or whole router must be creates difficulties when a routing engine or whole router must be
replaced in the field and all software which accesses the router must replaced in the field and all software which accesses the router must
be updated with the new keys. Also, any network based initial contact be updated with the new keys. Also, any network based initial contact
with a new routing engine requires trust in the public key presented with a new routing engine requires trust in the public key presented
on first contact. on first contact.
skipping to change at page 8, line 36 skipping to change at page 9, line 22
[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,
June 2005. June 2005.
[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, 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)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
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).
[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,
skipping to change at page 9, line 13 skipping to change at page 9, line 45
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).
[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).
[IEEE-802.3]
ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD)
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
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) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006. Transport Layer Protocol", RFC 4253, January 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007. 36, RFC 4949, August 2007.
skipping to change at page 10, line 6 skipping to change at page 10, line 30
[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 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
Policy (CP) for the Resource Public Key Infrastructure
(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, October
2013. 2013.
Authors' Addresses Authors' Addresses
 End of changes. 8 change blocks. 
15 lines changed or deleted 33 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/