draft-ietf-sidr-rtr-keying-01.txt   draft-ietf-sidr-rtr-keying-02.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: August 27, 2013 Cisco Systems Expires: March 16, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
February 23, 2013 September 12, 2013
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-01 draft-ietf-sidr-rtr-keying-02
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 2, line 17 skipping to change at page 2, line 17
1. Introduction 1. Introduction
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). The public key is published in (Resource Public Key Infrastructure). The public key is published in
the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki- the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki-
profiles]. This document describes two methods for generating the profiles]. This document describes two methods for generating the
necessary public/private key-pair: router-driven and operator-driven. necessary public/private key-pair: router-driven and operator-driven.
The difference between the two models is where the keys are The difference between the two methods is where the keys are
generated. Keys are generated on the router in the router-drive generated: on the router in the router-driven method and elsewhere in
method but elsewhere by the operator in the operator-drive model. the operator-driven model. Different equipment necessitates the two
The router-driven model is most familiar to PKI subscribers because methods. Some equipment doesn't allow the private key to be off-
its design supports CPs (Certification Policies), often times for loaded while other equipment does. Off-loading private keys supports
human subscribers, that require the private key only ever be hot-swappable routers that need to have the same private key needs
controlled by the subscriber to ensure that no one can impersonate installed in the soon-to-be online router that was installed in the
the subscriber. For non-humans, this model does not always work in soon-to-be offline router.
particular 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 installed in the soon-to-be offline router.
The remainder of this document describes how operators can use the The remainder of this document describes how operators can use the
two methods to provision new and existing routers. two methods to provision new and existing routers.
Note that in both models, the key pair is for algorithms defined in Note that in both models, the key pair is for algorithms defined in
[I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on [I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on
the P-256 curve. the P-256 curve.
2. Terminology 2. Terminology
skipping to change at page 3, line 4 skipping to change at page 2, line 49
It is assumed that the reader understands BGPsec [I-D.ietf-sidr- It is assumed that the reader understands BGPsec [I-D.ietf-sidr-
bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480], bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480],
and [I-D.ietf-sidr-bgpsec-pki-profiles]. and [I-D.ietf-sidr-bgpsec-pki-profiles].
3. Provisioning a New Router 3. Provisioning a New Router
When commissioning a new router, operators may use either the router- When commissioning a new router, operators may use either the router-
driven or operator-drive methods. Regardless of the method chosen, driven or operator-drive methods. Regardless of the method chosen,
the operator first needs to establish a secure communication channel the operator first needs to establish a secure communication channel
with the router. Today, this is done via a proprietary management with the router. Operators use the router-specific procedures to
box directly connected to the router on the serial/craft port {spt: enable them to connect to the router via an SSH session.
is serial/craft port the correct terminology?}. After the management
box has been physically connected to the router, the operator
authenticates to the management box, via a proprietary mechanism
{spt: is this really proprietary or it is leap-of-faith?}, and uses
the CLI (command line interface) to generate the router's SSH (Secure
Shell) key [RFC4253], retrieve the router's SSH public key, install
the operator's SSH key(s), configures the Ethernet port [IEEE-802.3],
BGPSEC-router number {spt: assume this is where the BGPSEC-router #
will get "installed" for the router-driven case to know what to put
in the PKCS#10}, etc. {spt: did I miss anything?}.
{spt: i added CA certificate in the above for the router to verify
that the CA actually signed the certificate. overkill?}
{spt: this could go here or in the security considerations. i am
ambivalent about where it ends up, but i think we should have this
data in here somewhere. i'd like to think if we're provisioning
these routers with ECDSA keys that we're going to be using algorithms
at least as good!? the one that gives me heartburn is hmac-sha2-256
seems like there ought to be a 128-bit truncated version to match
with the others.}
The SSH encryption, integrity, authentication, and key exchange The SSH encryption, integrity, authentication, and key exchange
mechanisms used by the router and operator SHOULD be of comparable mechanisms used by the router and operator SHOULD be of comparable
strength to BGPSEC key, which is 128-bit strength, e.g., for strength to BGPSEC key, which is 128-bit strength, e.g., for
encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for
integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647], integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647],
for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key
exchange: ecdh-sha2-nistp256 [RFC5656]. exchange: ecdh-sha2-nistp256 [RFC5656].
{spt: i'm unsure whether the following is being done, but it could be
done so i think it's worth mentioning it.}
Note that if the router supports public key certificates at this Note that if the router supports public key certificates at this
point, which would have had to have been provided by the operator at point, which would have had to have been provided by the operator at
this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
instead for authentication. The SSH certificate, profiled in authentication. The SSH certificate, profiled in [RFC6187], would be
[RFC6187], would be different than the BGPSEC certificate. different than the BGPSEC certificate.
{spt: do the commands to generate/deposit a key need to come over the
ethernet port or if they can come over the management port?}
Once generated, the operator establishes an SSH connection with the
router and the management box is no longer needed. At this point,
the choice of router-driven or operator-driven is vendor specific.
3.1. Router-Generated Keys 3.1. Router-Generated Keys
In the router-driven method, once an SSH connection 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 that includes the router number and public key, generate the PKCS#10 request that includes the router number and
and sign the PKCS#10 with the private key. [I-D.ietf-sidr-bgpsec- public key, and to sign the PKCS#10 with the private key. [I-D.ietf-
pki-profiles] specifies the format for the PKCS #10 and the algorithm sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10
used to generate the signature is specified in [I-D.ietf-sidr-bgpsec- request and the algorithm used to generate the signature is specified
algs]. in [I-D.ietf-sidr-bgpsec-algs].
{spt: Not sure if the distinction I made here between direct and
indirect makes any sense.}
The PKCS#10 request can be directly transferred to the RPKI CA over The PKCS#10 request, which includes the public key the router wants
the Ethernet port if the router supports protocols such as FTP and certified, can be directly transferred to the RPKI CA over the
HTTP [RFC2585] using the application/pkcs10 media type [RFC5967] or Ethernet port if the router supports protocols such as FTP and HTTP
EST (Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA [RFC2585] using the application/pkcs10 media type [RFC5967] or EST
(Enrollment over Secure Transport) [I-D.ietf-pkix-est]. The CA
returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki- returns a successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki-
profiles], which includes the certificate, and uploads the 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 their RPKI software management tools. The tools
create and publish the certificate for the public key, and return the create and publish the certificate for the public key, and return the
PKCS#7 to the router. PKCS#7 to the router.
{spt: the bit about checking the returned certificate is new, but i
think a good idea. but, does the CA's certificate get returned in
the PKCS#7 - I couldn't find that in the cert profile?}
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
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.
Note that even if the operator can not get the private key off the Note that even if the operator can not get the private key off the
router this still provides a linkage between a private key and a router this signature still provides a linkage between a private key
router. and a router. That is the server can verify the proof of 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 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. The operator uses their RPKI management operator and the router. Note that cut/copy and paste operations for
tools to generate the keys, the PKCS#10 certification request, the keys over a certain sizes is error-prone.
certificate, and the PKCS#7 certification response as well as publish
the certificate for the public key in the global RPKI. The private
key MUST support the algorithm specified in [I-D.ietf-sidr-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].
{spt: i figured maybe we could sign the PKCS#8, but that would have The operator uses their RPKI management tools to generate the keys,
to be done with a key other than the CA's key. It would have to be the PKCS#10 certification request, the certificate, and the PKCS#7
the operator's EE key.} certification response as well as publish the certificate for the
public key in the global RPKI. The private key MUST support the
algorithm specified in [I-D.ietf-sidr-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 7, line 27 skipping to change at page 6, line 36
[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),
September 2012. March 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),
October 2012. April 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),
December 2012. July 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),
October 2012. February 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", draft-ietf-pkix-est (work in progress),
February 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
 End of changes. 19 change blocks. 
84 lines changed or deleted 44 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/