SIDR
Network Working Group                                            R. Bush
Internet-Draft                             IIJ Lab / Dragon Research Lab
Intended status: Standards Track                               S. Turner
Internet-Draft
Expires: May 5, 2016                                          IECA, Inc.
Intended status: BCP
                                                                K. Patel
Expires: January 21, 2016
                                                           Cisco Systems
                                                                 R. Bush
                                         Internet Initiative Japan, Inc.
                                                           July 20,
                                                        November 2, 2015

                        Router Keying for BGPsec
                     draft-ietf-sidr-rtr-keying-09
                     draft-ietf-sidr-rtr-keying-10

Abstract

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

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in RFC 2119 [RFC2119] only when they
   appear in all upper case.  They may also appear in lower or mixed
   case as English words, without normative meaning.

Status of this 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 May 5, 2016.

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Management / Router Communication . . . . . . . . . . . . . .   3
   3.  Exchanging Certificates . . . . . . . . . . . . . . . . . . .   4
   4.  Set-Up  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  PKCS#10 Generation  . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Router-Generated Keys . . . . . . . . . . . . . . . . . .   4
     5.2.  Operator-Generated Keys . . . . . . . . . . . . . . . . .   5
   6.  Installing Signed Keys  . . . . . . . . . . . . . . . . . . .   5
   7.  Key Management  . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Key Validity  . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Key Roll-Over . . . . . . . . . . . . . . . . . . . . . .   7
     7.3.  Key Revocation  . . . . . . . . . . . . . . . . . . . . .   8
     7.4.  Router Replacement  . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Management/Router Channel Security . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

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

   The difference between the

   These two methods is sub-methods differ in where the keys are generated: on the
   router in the router-driven method method, and elsewhere in the operator-driven operator-
   driven method.  Routers are expected required to support either
   one, at least one of the other, or both
   methods in order to work in various deployment environments.  Some
   routers may not allow the private key to be off-
   loaded off-loaded while other routers others
   may.  Off-loading of  While off-loading private keys would
   support ease swapping of routing engines which could then have the same
   engines, exposure of private key installed in keys is a well known security risk.

   In the soon-to-be online engine that had
   previously been installed in operator-driven method, the soon-to-be removed card.

   The remainder of this document describes how operators can use operator generates the
   two methods to provision new private/
   public key-pair and existing routers.

   Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies sends it to the format for router, perhaps in a PKCS#8
   package [RFC5958].

   In the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies router-driven method, the
   algorithms used to generate router generates its own public/
   private key-pair, uses the signature.

2.  Terminology

   The private key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", to sign a PKCS#10
   certification request [I-D.ietf-sidr-bgpsec-pki-profiles], which
   includes the public key), and "OPTIONAL" are returns the certification request to
   the operator to be interpreted as described in RFC 2119 [RFC2119] only when they
   appear in all upper case.  They may also appear forwarded to the RPKI Certification Authority
   (CA).  The CA returns a PKCS#7, which includes the certified public
   key in lower or mixed
   case as English words, without normative meaning.

   Readers are assumed the form of a certificate, to be familiar with the BGPsec protocol [I-
   D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] operator for loading into
   the router; and the
   RPKI [RFC6480] as well as CA also publishes the certificate in the RPKI.

   The router-driven model mirrors the BGPsec-specific model used by traditional PKI (Public Key
   Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I-
   D.ietf-sidr-bgpsec-algs].

3.  Provisioning a New Router

   Depending on
   subscribers; the options supported private key never leaves trusted storage (e.g.,
   Hardware Security Module).  This is by design and supports classic
   PKI Certification Policies for (often human) subscribers which
   require the new router, private key only ever be controlled by the subscriber to
   ensure that no one can impersonate the subscriber.  For non-humans,
   this model does not always work.  For example, 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 used by the the
   soon-to-be offline router.  This motivated the operator-driven model.

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

   Useful References: [I-D.ietf-sidr-bgpsec-overview] gives an overview
   of the BGPsec protocol, [I-D.ietf-sidr-bgpsec-protocol] gives the
   gritty details, [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the
   format for the PKCS #10 request, and [I-D.ietf-sidr-bgpsec-algs]
   specifies the algorithms used to generate the signature.

2.  Management / Router Communication

   Operators are free to use either the router-driven or operator-driven methods.
   method as supported by the platform.  Regardless of the method
   chosen, operators first establish a secure communication channel (e.g., via SSH (Secure Shell))
   between the
   operator's management platform system and the router to allow the operator
   to securely use the Command Line Interface (CLI). router.  How this channel is
   established is router-specific and is not in beyond scope of this document.

   Though other configuration mechanisms might be used, e.g.  NetConf
   (see [RFC6470]), [RFC6470]); for simplicity, in the remainder of this document, the
   secure communication
   channel between the server management platform and the router is assumed to
   be an SSH-protected CLI.

   Encryption, integrity, authentication, and key exchange algorithms
   used by the secure communication channel SHOULD be of comparable
   strength to BGPsec keys, which currently is 128-bit, or stronger than
   BGPsec keys.  In other words for 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]; for integrity
   use something like hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM
   [RFC5647];  See Appendix A for authentication use something like ecdsa-sha2-nistp256
   [RFC5656], and; security considerations
   for key this channel.

3.  Exchanging Certificates

   The operator management station can exchange use something like ecdh-sha2-
   nistp256 [RFC5656].

   Note that some certificate requests and
   certificates with routers support and with the use of public key certificates RPKI CA infrastructure using
   the application/pkcs10 media type [RFC5967] and
   SSH. application/
   pkcs7-mime [RFC5751], respectively, and may use FTP or HTTP per
   [RFC2585], or the Enrollment over Secure Transport [RFC7030].

4.  Set-Up

   To start, the operator uses the communication channel to install the
   appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.
   This will later enable the router to validate the router certificate
   returned in the PKCS#7.

   The certificates operator also configures the Autonomous System (AS) number to be
   used for in the SSH session are different than generated router certificate.  This may be the certificates used for BGPsec. sole AS
   configured on the router, or an operator choice if the router is
   configured with multiple ASs.

   The certificates operator configures or extracts from the router the BGP RouterID
   to be used with SSH
   should also enable in the generated certificate.  In the case where the
   operator has chosen not to use unique per-router certificates, a level
   RouterID of security commensurate with BGPsec keys;
   x509v3-ecdsa-sha2-nistp256 [RFC6187] could 0 may be used for
   authentication.

3.1. used.

5.  PKCS#10 Generation

   The private key, and hence the PKCS#10 request may be generated by
   the router or by the operator.

5.1.  Router-Generated Keys

   In the router-driven router-generated method, once the SSH-protected CLI protected session is
   established between the operator and the router, initial Set-Up (Section 4) performed, the
   operator issues a command, command or commands, commands for the router to generate the
   public/private key pair, to generate the PKCS#10 request, and to sign
   the PKCS#10 with the private key.  Once generated, the PKCS#10, which includes
   the public key the router wants certified, PKCS#10 is transmitted to the RPKI
   CA for the CA
   returned to certify.  This can be via a number of means, two of
   which might be as follows:

     o Through the SSH-protected CLI session with the operator's RPKI
       management platform: The operator off-loads the PKCS#10 and
       uploads the request to over the CA. protected channel.

   If the CA is operated by an
       external entity, external network connectivity likely is
       required.

     o Between the router and the CA: The operator, through a command or
       commands, prompts the router was to send/transfer the PKCS#10 request
       to the communicate directly with a CA over the network.  Obviously for this to work, the
       router requires network connectivity with have the CA and if
   certify the CA is
       operated by an external entity external network connectivity may PKCS#10, there would be required.

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

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

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

   With network connectivity, communication with the router and CA can exchange CA.

   The operator adds the
   certificate request chosen AS number and the certificate using the application/pkcs10
   media type [RFC5967] and application/pkcs7-mime [RFC5751],
   respectively, with RouterID to send to
   the FTP [RFC2585], RPKI CA for the HTTP [RFC2585], or CA to certify.

5.2.  Operator-Generated Keys

   In the EST
   (Enrollment over Secure Transport) [RFC7030].

   The router SHOULD extract operator-generated method, the certificate from operator generates the PCKCS#7 public/
   private key pair on a management station and verify
   that installs the private key it holds corresponds to
   into the returned public key.
   The router SHOULD inform over the operator protected channel.  Beware that the certificate was
   received; by some mechanism which is out of scope of this document.
   The experience
   has shown that copy and paste from a management station to a router SHOULD inform the operator whether or not
   can be unreliable for long texts.

   Alternatively, the keys
   correspond, again by private key may be encapsulated in a mechanism which PKCS #8
   [RFC5958], the PKCS#8 is out of scope for this
   document. further encapsulated in Cryptographic
   Message Syntax (CMS) SignedData [RFC5652], and signed by the AS's End
   Entity (EE) certificate.

   The router SHOULD also verify that the returned certificate validates
   back to a trust anchor.  To perform this verification either signature of the CA's
   certificate needs encapsulated PKCS#8 to be installed on
   ensure the router returned private key did in fact come from the operator,
   but this requires that the operator also provision via the CLI or
   include in the
   CA's certificate needs to be returned along with SignedData the router's RPKI CA certificate in the PKCS#7. and relevant AS's
   EE certificate(s).  The router SHOULD 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's certificate because the
   certificate is not transmitted as part of BGPsec messages.

   Note that even if the

   The operator cannot extract then creates and signs the private key from PKCS#10 with the router, this signature still provides a linkage between a private
   key 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 adds the
   public/private key pair chosen AS number and installs the private key into the router
   over RouterID to be sent to the SSH-protected CLI session.  Note that cut/copy and paste
   operations RPKI CA
   for keys over a certain sizes are error-prone. the CA to certify.

6.  Installing Signed Keys

   The operator uses RPKI management tools to generate communicate with the keys,
   global RPKI system to have the appropriate CA validate the PKCS#10 certification
   request, sign the certificate, and key in the PKCS#10 and generated PKCS#7
   certification response,
   as well as publishing the certificate in the Global RPKI.  External
   network connectivity may be needed if the certificate is to be
   published in the Global RPKI.

   Along with

   After the PKCS#7, CA certifies the operator returns key, it does two things:

   1.  Publishes the private key. certificate in the Global RPKI.  The
   private key CA must have
       connectivity to the relevant publication point, which in turn
       must have external network connectivity as it is encapsulated part of the
       Global RPKI.

   2.  Returns the certificate to the operator's management station,
       packaged in a PKCS #8 [RFC5958], PKCS#7, using the PKCS#8 is
   further encapsulated in CMS (Cryptographic Message Syntax) SignedData
   [RFC5652], and signed corresponding method by which it
       received the certificate request.  It SHOULD include the
       certificate chain below the TA Certificate so that the router can
       validate the AS's EE (End Entity) certificate.

   The router certificate.

   In the operator-generated method, the operator SHOULD verify extract the signature of
   certificate from the encapsulated PKCS#8 to
   ensure PKCS#7, and verify that the returned private key did in fact come from it holds
   corresponds to the operator,
   but this requires that returned public key.

   In the operator-generated method, the operator also provision via has already installed
   the CLI or
   include private key in the SignedData the RPKI CA certificate and relevant AS's
   EE certificate(s). The router should inform the (see Section 5.2).

   The operator whether or
   not provisions the signature validates to a trust anchor; this notification
   mechanism is out of scope. PKCS#7 into the router over the secure
   channel.

   The router SHOULD extract the certificate from the PKCS#7 and verify
   that the private key corresponds to the returned public key.  The
   router SHOULD inform the operator whether it successfully received
   the certificate; this mechanism is out of scope.  The router should
   inform the operator certificate and whether or not the keys correspond; this the mechanism
   is out of scope.

   The router SHOULD also verify that the returned certificate validates
   back to a trust anchor, but to perform this
   verification either the CA's certificate needs to be installed on TA Certificate, i.e., the
   router via entire chain from the CLI or
   installed TA Certificate through subordinate CAs to the CA's BGPsec
   certificate validate.  To perform this verification the CA
   certificate chain 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 the
   direct CA.

4.

   Even if the operator cannot extract the private key from the 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].

7.  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

7.1.  Key Validity

   It is critical that a BGPsec speaking router ensures that can be a continuous BPGsec
   speaker it is ensuring that the router has
   signing with a valid certificate at all times.  To ensure this, this end, the
   operator needs to ensure the router always has a non-expired
   certificate.  That is  I.e. the key used when BGP-
   speaking to sign BGPsec announcements always
   has an associated certificate whose expiry time is after the current
   time.

   Ensuring this is not terribly difficult but requires that either:

     o

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

     o

   2.  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 remind them of the actual expiry time, and/or

     o

   3.  The RPKI CA warns the operaor operator of pending expiration, and/or

     o

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

   It is advisable that expiration warnings happen well in advance of
   the actual expiry time.

   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 helpful to notify
   a peer operator that one or more of their certificates are about to
   expire.

7.2.  Key Roll-Over

   Routers that support multiple private keys also greatly increase the
   chance that routers can continuously speak BGPsec because the new
   private key and certificate can be obtained and distributed prior to
   expiration of the operational key.  Obviously, the router needs to
   know when to start using the new key.  Once the new key is being
   used, having the already distributed certificate ensures continuous
   operation.

   Whether the certificate is rekeyed re-keyed (i.e., different key in the
   certificate with a new expiry time) or renewed (i.e., the same key in
   the certificate with a new expiry time) depends on the key's lifetime
   and operational use.  Arguably, rekeying re-keying the router's BGPsec
   certificate every time the certificate expires is more secure than
   renewal because it limits the private key's exposure.  However, if
   the key is not 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 ensure continuous operation,
   assuming the certificate is renewed and distributed prior to well in advance
   of the
   operational's certificate operational certificate's expiry time.

7.3.  Key Revocation

   Certain unfortunate circumstances exist when the operator will may occur causing a need to revoke the
   a 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 Certificate Revocation List) List (CRL)
   as well as rekeying re-keying 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 re-keying/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 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, soon-to-be-operational, 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 next generation 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

   Current router code generates

7.4.  Router Replacement

   Currently routers often generate private keys for uses such as SSH, but
   and the private keys may not be seen or off-loaded via from the SSH-protected
   CLI session or any other means. router.
   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,
   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, a
   protected session, e.g.  SSH, NetConf (see [RFC6470]), SNMP, etc.
   This lets the operator upload the old private key via the mechanism
   used for operator-generated keys, see Section 3.2.

6. 5.2.

8.  Security Considerations

   Operator-generated keys could be intercepted

   The router's manual will describe whether the router supports one,
   the other, or both of the key generation options discussed in transport and the
   recipient
   earlier sections of this draft as well as other important security-
   related information (e.g., how to SSH to the router).  After
   familiarizing one's self with the capabilities of the router,
   operators are encouraged to ensure that the router would have is patched with
   the latest software updates available from the manufacturer.

   This document defines no way protocols so in some sense introduces no new
   security considerations.  However, it relies on many others and the
   security considerations in the referenced documents should be
   consulted; notably, those document listed in Section 1 should be
   consulted first.  PKI-relying protocols, of knowing a substitution had which BGPsec is one, have
   many issues to consider so many in fact entire books have been
   made or
   written to address them; so listing all PKI-related security
   considerations is neither useful nor helpful; regardless, some boot-
   strapping-related issues are listed here that are worth repeating:

   Public-Private key pair generation:  Mistakes here are for all
      practical purposes catastrophic because PKIs rely on the pairing
      of a difficult to generate public-private key pair with a signer;
      all key pairs MUST be generated from a good source of non-
      deterministic random input [RFC4086].

   Private key protection at rest:  Mistakes here are for all practical
      purposes catastrophic because disclosure of the private key allows
      another entity to masquerade as (i.e., impersonate) the signer;
      all private keys MUST be protected when at rest in a secure
      fashion.  Obviously, how each router protects private keys is
      implementation specific.  Likewise, the local storage format for
      the private key had been disclosed by is just that, a monkey local matter.

   Private key protection in transit:  Mistakes here are for all
      practical purposes catastrophic because disclosure of the private
      key allows another entity to masquerade as (i.e., impersonate) the middle.
   Hence
      signer; transport security is therefore strongly RECOMMENDED.  As noted in
   Section 3, the  The
      level of security provided by the transport layer's security
      mechanism SHOULD be commensurate with the strength of the BGPsec key.
      key; there's no point in spending time and energy to generate an
      excellent public-private key pair and then transmit the private
      key in the clear or with a known-to-be-broken algorithm, as it
      just undermines trust that the private key has been kept private.
      Additionally, operators SHOULD ensure the transport security implementation
      mechanism is up to date and date, in order to addresses all known
      implementation bugs.

   All generated

   SSH key pairs MUST management is known, in some cases, to be generated from a good source of non-
   deterministic random input [RFC4086] and the private key MUST lax
   [I-D.ylonen-sshkeybcp]; employees that no longer need access to
   routers SHOULD be
   protected in a secure fashion.  Disclosure of removed the private key leads router to ensure only those authorized
   have access to masquerade [RFC4949].  The local storage format for the private
   key is a local matter. router.

   Though the CA's certificate is installed on the router and used to
   verify that the returned certificate is in fact signed by the CA, the
   revocation status of the CA's certificate is rarely checked as the
   router may not checked. have global connectivity or CRL-aware software.  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 may do so.  As employees no longer
   need access to the router, their keys SHOULD be removed from the
   router.

7.

9.  IANA Considerations

   This document has no IANA Considerations.

8.

10.  References

8.1.

10.1.  Normative References

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

   [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-04 (work in progress), October 2012.

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

   [RFC4086]  Eastlake 3rd,  Eastlake, 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.

   [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).

   [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).

8.2. S., "Asymmetric Key Packages", RFC 5958, August
              2010.

10.2.  Informative References

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

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

   [I-D.ylonen-sshkeybcp]
              Ylonen, T. and G. Kent, "Managing SSH Keys for Automated
              Access - Current Recommended Practice", draft-ylonen-
              sshkeybcp-01 (work in progress). progress), April 2013.

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              RFC 2585, May 1999.

   [RFC4253]  Ylonen, T.

   [RFC3766]  Orman, H. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 4253, January 2006.

   [RFC4949]  Shirey, 3766, April 2004.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., "Internet Security Glossary, Version 2", FYI
              36, and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 4949, August 2007. 5480, March 2009.

   [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.

   [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
              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,
              DOI 10.17487/RFC7030, October
              2013. 2013,
              <http://www.rfc-editor.org/info/rfc7030>.

Appendix A.  Management/Router Channel Security

   Encryption, integrity, authentication, and key exchange algorithms
   used by the secure communication channel SHOULD be of equal or
   greater strength than the BGPsec keys they protect, which for the
   algorithm specified in [I-D.ietf-sidr-bgpsec-algs] is 128-bit; see
   [RFC5480] and by reference [SP800-57] for information about this
   strength claim as well as [RFC3766] for "how to determine the length
   of an asymmetric key as a function of a symmetric key strength
   requirement."  In other words, for the encryption algorithm, do not
   use export grade crypto (40-56 bits of security), do not use Triple
   DES (112 bits of security).  Suggested minimum algorithms would be
   AES-128: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647] for
   encryption, hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM [RFC5647]
   for integrity, ecdsa-sha2-nistp256 [RFC5656] for authentication, and
   ecdh-sha2-nistp256 [RFC5656] for key exchange.

   Some routers support the use of public key certificates and SSH.  The
   certificates used for the 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.

Authors' Addresses

   Randy Bush
   IIJ / Dragon Research Labs
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Email: randy@psg.com

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

   Email: turners@ieca.com sean@sn3rd.com

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

   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