SIDR Working Group                                             S. Turner
Internet-Draft                                                IECA, Inc.
Intended status: BCP                                            K. Patel
Expires: June 20, October 31, 2014                                  Cisco Systems
                                                                 R. Bush
                                         Internet Initiative Japan, Inc.
                                                       December 17, 2013
                                                          April 29, 2014

                        Router Keying for BGPsec
                     draft-ietf-sidr-rtr-keying-04
                     draft-ietf-sidr-rtr-keying-05

Abstract

   BGPsec-speaking routers must be are provisioned with private keys and to sign BGP
   messages; the corresponding public key must be keys are published in the global
   RPKI (Resource Public Key Infrastructure). Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning public/private keys, the public-private key-pairs: router-driven and operator-
   driven.
   operator-driven.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 27, 2013.

Copyright Notice

   Copyright (c) 2013 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   BGPsec-speaking routers must be are provisioned with private keys and keys, which
   allow them to digitally sign BGP messages.  To verify the signature,
   the
   corresponding public key must be key, in the form of a certificate [I-D.ietf-sidr-bgpsec-
   pki-profiles], is published in the global RPKI (Resource Public Key
   Infrastructure).  The public key is published in
   the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki-
   profiles].  This document describes two methods for generating
   provisioning the necessary public/private key-pair: public-private key-pairs: router-driven
   and operator-driven.

   The difference between the two methods is where the keys are
   generated: on the router in the router-driven method and elsewhere in
   the operator-driven model.  Different equipment necessitates method.  Routers are expected to support either
   one, the two
   methods. other, or both methods to work in various deployment
   environments.  Some equipment doesn't routers may not allow the private key to be off-
   loaded while other equipment does. routers may.  Off-loading of private keys supports
   hot-swappable routers that need to would
   support swapping of routing engines which could then have the same
   private key needs installed in the soon-to-be online router engine that was had
   previously been installed in the soon-to-be offline router. removed card.

   The remainder of this document describes how operators can use the
   two methods to provision new and existing routers.

   Note that in both models,

   Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the key pair is format for algorithms defined in
   [I-D.ietf-sidr-bgpsec-algs].  The first version
   the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies ECDSA on the P-256 curve.
   algorithms used to generate the signature.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
   be interpreted as described in RFC 2119 [RFC2119].

   It is [RFC2119] only when they
   appear in all upper case.  They may also appear in lower or mixed
   case as English words, without normative meaning.

   Readers are assumed that to be familiar with the reader understands BGPsec [I-D.ietf-sidr-
   bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], protocol [I-
   D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the
   RPKI [RFC6480],
   and [I-D.ietf-sidr-bgpsec-pki-profiles]. [RFC6480] as well as the BGPsec-specific PKI (Public Key
   Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I-
   D.ietf-sidr-bgpsec-algs].

3.  Provisioning a New Router

   When commissioning a
   Depending on the options supported by the new router, operators may are
   free to use either the router-
   driven router-driven or operator-drive methods.
   Regardless of the method chosen,
   the operator operators first needs to establish a secure
   communication channel
   with (e.g., via SSH (Secure Shell)) between the router.  Operators use
   operator's management platform and the router-specific procedures to
   enable them router to connect allow the operator
   to securely use the Command Line Interface (CLI).  How this channel
   is established is router-specific and is not in scope of this
   document.  Though other configuration mechanisms might be used, e.g.
   NetConf (see [RFC6470]), in the remainder of this document, the
   secure communication channel between the server and the router via is
   assumed to be an SSH session.

   The SSH encryption, SSH-protected CLI.

   Encryption, integrity, authentication, and key exchange
   mechanisms algorithms
   used by the router and operator secure communication channel SHOULD be of comparable
   strength to BGPSEC key, BGPsec keys, which currently is 128-bit strength, e.g., 128-bit, or stronger than
   BGPsec keys.  In other words for
   encryption: aes128-cbc [RFC4253] the encryption algorithm, do not use
   export grade crypto (40-56 bits of security), do not use Triple DES
   (112 bits of security), do use something like or better than AES-128:
   aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], [RFC5647]; for
   integrity: integrity
   use something like hmac-sha2-256 [RFC6668] and or AESAD_AES_128_GCM [RFC5647],
   [RFC5647]; for authentication: authentication use something like ecdsa-sha2-nistp256
   [RFC5656], and and; for key
   exchange: ecdh-sha2-nistp256 exchange use something like ecdh-sha2-
   nistp256 [RFC5656].

   Note that if some routers support the router supports use of public key certificates at this
   point, which would have had to have been provided by and
   SSH.  The certificates used for the operator at
   this point, SSH session are different than
   the certificates used for BGPsec.   The certificates used with SSH
   should also enable a level of security commensurate with BGPsec keys;
   x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
   authentication.  The SSH certificate, profiled in [RFC6187], would be
   different than the BGPSEC certificate.

3.1.  Router-Generated Keys

   In the router-driven method, once an SSH the SSH-protected CLI session is
   established between the operator and the router router, the operator issues
   a command, or commands, for the router to generate the public/private
   key pair on the router, pair, to generate the PKCS#10 request that includes the router number and
   public key, request, and to sign the PKCS#10
   with the private key. [I-D.ietf-
   sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10
   request and the algorithm used to generate  Once generated, the signature is specified
   in [I-D.ietf-sidr-bgpsec-algs].

   The PKCS#10 request, PKCS#10, which includes
   the public key the router wants certified, can be transferred is transmitted to the RPKI
   CA over the network if the
   router supports protocols such as FTP and HTTP [RFC2585] using the
   application/pkcs10 media type [RFC5967] or EST (Enrollment over
   Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that
   the router has direct connectivity to for the CA.  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 certify.  This can be returned using the
   application/pkcs7-mime media type [RFC5751] if the router supports
   protocols such as FTP and HTTP.

   The PKCS#10 request can also via a number of means, two of
   which might be indirectly transferred to as follows:

     o Through the RPKI CA
   through SSH-protected CLI session with the operator. operator's RPKI
       management platform: The operator off-loads the PKCS#10 and
       uploads the request to its RPKI software management tools; the CA.  If the CA is operated by an
       external entity, external network connectivity likely is not required when
       required.

     o Between the operator acts as the CA.  The
   tools create the certificate router and publish the certificate in the
   global RPKI, and return CA: The operator, through a command or
       commands, prompts the PKCS#7 router to send/transfer the router; publication of PKCS#10 request
       to the CA over the network.  Obviously for this to work, the
       router requires network connectivity with the CA and if the CA is
       operated by an external entity external network connectivity may
       be required.

   After the CA certifies the key, it does two things:

     o Publishes the certificate in the global RPKI requires Global RPKI.  The CA must have
       connectivity to the relevant publication point, which in turn
       must have external network
   connectivity. connectivity as it is part of the
       Global RPKI.

     o Returns the certificate to the operator's management station or
       to the router, normally packaged in a PKCS#7, using the
       corresponding method by which it received the certificate
       request.

   With network connectivity, the router and CA can exchange the
   certificate request and the certificate using the application/pkcs10
   media type [RFC5967] and application/pkcs7-mime [RFC5751],
   respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST
   (Enrollment over Secure Transport) [I-D.ietf-pkix-est].

   The router SHOULD extract the certificate from the PCKCS#7 and verify
   that the private key it holds corresponds to the returned public key.
   The router SHOULD inform the operator that it has successfully received
   its certificate; this the certificate was
   received; by some mechanism which is out of scope.  When the keys do
   not correspond, the scope of this document.
   The router SHOULD inform the operator; this operator whether or not the keys
   correspond, again by a mechanism which is out of scope. scope for this
   document.

   The router SHOULD also verify that the returned certificate validates
   back to a trust anchor,  but to anchor.  To perform this verification 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 router's
   certificate in the PKCS#7.  The router SHOULD inform the operator if
   whether or not the signature does not validate validates to a trust anchor; this
   notification mechanism is out of scope.  After performing these
   checks, the router need not retain the certificate. CA's certificate because the
   certificate is not transmitted as part of BGPsec messages.

   Note that even if the operator can not get cannot extract the private key off from
   the
   router router, this signature still provides a linkage between a private
   key and a router.  That is the server can verify the proof of
   possession (POP), as required by [RFC6484].

3.2.  Operator-Generated Keys

   In the operator-driven method, the operator generates the private
   public/private key pair and it is installed over installs the SSH connection established between private key into the
   operator and router
   over the router. SSH-protected CLI session.  Note that cut/copy and paste
   operations for keys over a certain sizes is error-prone.

   The operator uses their RPKI management tools to generate the keys, the
   PKCS#10 certification request, the certificate, and the PKCS#7
   certification response response, as well as publish publishing the certificate for the
   public key in the global
   Global RPKI.  The only reason global  External network connectivity might be may needed would be to publish if the
   certificate is to be published in the global 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
   private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is
   further encapsulated in a CMS (Cryptographic Message Syntax) SignedData
   [RFC5652], and signed by the operator's AS's EE (End Entity) certificate.

   The router SHOULD verify the signature on of the encapsulated PKCS#8 to
   ensure the returned private key did in fact came come from the operator,
   but this requires that the operator also provision via the CLI or
   include in the SignedData the RPKI CA certificates certificate and operator's relevant AS's
   EE
   certificates. certificate(s). The router SHOULD inform the operator if whether or
   not the signature
   does not validate validates to a trust anchor; this notification
   mechanism is out of scope.

   The router SHOULD extract the certificate for from the PKCS#7 and verify
   that the private key corresponds to the returned public key.  The
   router SHOULD inform the operator that whether it has successfully received
   its
   the certificate; this mechanism is out of scope.  When  The router should
   inform the operator whether or not the keys correspond; this
   mechanism is out of scope.  The router SHOULD also verify the
   returned certificate back to a trust anchor, but to perform this
   verification 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 router's certificate in the PKCS#7.  The router SHOULD
   inform the operator whether or not the signature validates to a trust
   anchor; this notification mechanism is out of scope.  After
   performing these checks, the router need not retain the CA
   certificate.

   Note: The signature on the PKCS#8 and Certificate need not be made by
   the same entity.  Signing the PKCS#8, permits more advanced
   configurations where the entity that generates the keys is not CA.

4.  Key Management

   An operator's responsibilities do not end after key generation, key
   provisioning, certificate issuance, and certificate distribution.
   They persist for as long as the operator wishes to operate the
   BGPsec-speaking router.

   Paramount to maintaining a router that can be a continuous BPGsec
   speaker is ensuring that the router has a valid certificate at all
   times.  To ensure this, the operator needs to ensure the router
   always has a non-expired certificate.  That is the key used when BGP-
   speaking always has an associated certificate whose expiry time is
   after the current time.

   Ensuring this is not terribly difficult but requires that either:

     o The router has a mechanism to notify the operator that the
       certificate has an impending expiration, and/or

     o The operator notes the expiry time of the certificate and uses a
       calendaring program to remind them of the expiry time.  It is
       advisable that the expiration warning happen well in advance of
       the actual expiry time, and/or

     o The RPKI CA warns the operaor of pending expiration, and/or

     o Use some other kind of automated process to search for and track
       the expiry times of router certificates.

   Regardless of the technique used to track router certificate expiry
   times, it is advisable to notify additional operators in the same
   organization as the expiry time approaches thereby ensuring that the
   forgetfulness of one operator does not affect the entire
   organization.

   Depending on inter-operator relationship, it may be appropriate to
   notify a peer operator that one or more of their certificates are
   about to expire.

   Routers that support multiple private keys do
   not correspond, also greatly increase the router SHOULD inform
   chance that routers can continuously speak BGPsec because the operator; this mechanism
   is out new
   private key and certificate can be obtained prior to expiration of scope.  The router SHOULD also verify
   the returned
   certificate back operational key.  Obviously, the router needs to a trust anchor,  but know when to perform this verification
   either
   start using the CA's new key.  Once the new key is being used, having the
   already distributed certificate needs to be installed on ensures continuous operation.

   Whether the router via certificate is rekeyed (i.e., different key in the CLI
   certificate with a new expiry time) or renewed (i.e., the same key in
   the CA's certificate needs to be returned along with a new expiry time) depends on the key's lifetime
   and operational use.  Arguably, rekeying the router's BGPsec
   certificate in every time the PKCS#7.  The router SHOULD inform certificate expires is more secure than
   renewal because it limits the
   operator private key's exposure.  However, if
   the signature does key is not validate compromised the certificate could be renewed as many
   times as allowed by the operator's security policy.  Routers that
   support only one key can use renewal to a trust anchor; this
   notification mechanism ensure continuous operation,
   assuming the certificate is out of scope.  After performing these
   checks, renewed and distributed prior to the router
   operational's certificate expiry time.

   Certain unfortunate circumstances exist when the operator will need not retain
   to revoke the router's BGPsec certificate.  When this occurs, the
   operator needs to use the RPKI CA system to revoke the certificate by
   placing the router's BGPsec certificate on the CRL (Certificate
   Revocation List) as well as rekeying the router's certificate.

4.  Key rollover

   TBD

5.  Other Use Cases

   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
   CLI session or any other means.  While this is good security, it
   creates difficulties when a 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. Also, the any network based initial contact
   with a new routing engine requires trust in the public key presented
   on first contact.

   To allow operators to quickly replace routers without requiring
   update and distribution of the corresponding public keys in the RPKI,
   routers SHOULD allow the private BGPsec key to be off-loaded via the
   SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc.  This lets the
   operator upload the old private key via the mechanism used for operator-
   generated
   operator-generated keys, see Section 3.2.

6.  Security Considerations

   Operator-generated keys could be intercepted in transport and the
   recipient router would have no way of knowing a substitution had been
   made or that the key had been disclosed by a monkey in the middle.
   Hence transport security is strongly RECOMMENDED.  As noted in
   Section 3, the level of security provided by the transport security
   SHOULD be commensurate with the BGPsec key.  Additionally, operators
   SHOULD ensure the transport security implementation is up to date and
   addresses all known implementation bugs.

   All generated key pairs MUST be generated from a good source of non-
   deterministic random input [RFC4086] and the private key MUST be
   protected in a secure fashion.  Disclosure of the private key leads
   to masquerade [RFC4949].  The local storage format for the private
   key is a local matter.

   Though the CA's certificate is installed on the router and used to
   verify the returned certificate is in fact signed by the CA, the
   revocation status of the CA's certificate is not checked.  The
   operator MUST ensure that installed CA certificate is valid.

   Operators need to manage their SSH keys to ensure only those
   authorized to access the router can. may do so.  As employees no longer
   need access to the router, their keys SHOULD be removed from the
   router.

7.  IANA Considerations

   This document has no IANA Considerations.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              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
              2010.

   [I-D.ietf-sidr-bgpsec-algs]
              Turner, S., "BGP Algorithms, Key Formats, & Signature
              Formats", draft-ietf-sidr-bgpsec-algs (work in progress),
              September 2013. progress).

   [I-D.ietf-sidr-bgpsec-pki-profiles]
              Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPSEC Router Certificates, Certificate Revocation Lists,
              and Certification Requests",
              draft-ietf-sidr-bgpsec-pki-profiles (work in progress),
              September 2013. progress).

8.2.  Informative References

   [I-D.ietf-sidr-bgpsec-overview]
              Lepinski, M. and S. Turner, "An Overview of BGPSEC",
              draft-ietf-sidr-bgpsec-overview (work in progress),
              December 2013. progress).

   [I-D.ietf-sidr-bgpsec-protocol]
              Lepinski, M., "BGPSEC Protocol Specification",
              draft-ietf-sidr-bgpsec-protocol (work in progress),
              November 2013.

   [I-D.ietf-pkix-est]
              Pritikin, M, Yee, P., and D. Harkins "Enrollment over
              Secure Transport", RFC 7030, October 2013. 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
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, May 1999.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", FYI
              36, RFC 4949, August 2007.

   [RFC5647]  Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
              Secure Shell Transport Layer Protocol", RFC 5647, August
              2009.

   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, December 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5967]  Turner, S., "The application/pkcs10 Media Type", RFC 5967,
              August 2010.

   [RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
              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.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030, October
              2013.

Authors' Addresses

   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, Virginia  22031
   US

   Email: turners@ieca.com

   Keyur Patel
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email: keyupate@cisco.com

   Randy Bush
   Internet Initiative Japan, Inc.
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Phone: +1 206 780 0431 x1
   Email: randy@psg.com