<pre>Internet Engineering Task Force (IETF)                           R. Bush
Request for Comments: 8635                              IIJ Lab &amp; Arrcus
Category: Standards Track                                      S. Turner
ISSN: 2070-1721                                                    sn3rd
                                                                K. Patel
                                                            Arrcus, Inc.
                                                             August 2019


                        <span class="h1">Router Keying for BGPsec</span>

Abstract

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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc8635">https://www.rfc-editor.org/info/rfc8635</a>.

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.



<span class="grey">Bush, et al.                 Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Requirements Language . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Management/Router Communication . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-4">4</a>.  Exchange Certificates . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-5">5</a>.  Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
   <a href="#section-6">6</a>.  Generate PKCS#10  . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-6.1">6.1</a>.  Router-Driven Keys  . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-6.2">6.2</a>.  Operator-Driven Keys  . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
       <a href="#section-6.2.1">6.2.1</a>.  Using PKCS#8 to Transfer Private Keys . . . . . . . .   <a href="#page-6">6</a>
   <a href="#section-7">7</a>.  Send PKCS#10 and Receive PKCS#7 . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-8">8</a>.  Install Certificate . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-9">9</a>.  Advanced Deployment Scenarios . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#section-10">10</a>. Key Management  . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
     <a href="#section-10.1">10.1</a>.  Key Validity . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-10.2">10.2</a>.  Key Rollover . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
     <a href="#section-10.3">10.3</a>.  Key Revocation . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-10.4">10.4</a>.  Router Replacement . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
   <a href="#section-11">11</a>. Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-12">12</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
   <a href="#section-13">13</a>. References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-13.1">13.1</a>.  Normative References . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-13.2">13.2</a>.  Informative References . . . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
   <a href="#appendix-A">Appendix A</a>.  Management/Router Channel Security . . . . . . . . .  <a href="#page-17">17</a>
   <a href="#appendix-B">Appendix B</a>.  An Introduction to BGPsec Key Management . . . . . .  <a href="#page-18">18</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-21">21</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   BGPsec-speaking routers are provisioned with private keys, which
   allow them to digitally sign BGPsec announcements.  To verify the
   signature, the public key, in the form of a certificate [<a href="./rfc8209" title="&quot;A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests&quot;">RFC8209</a>], is
   published in the Resource Public Key Infrastructure (RPKI).  This
   document describes provisioning of BGPsec-speaking routers with the
   appropriate public-private key pairs.  There are two methods: router-
   driven and operator-driven.

   These two methods differ in where the keys are generated: on the
   router in the router-driven method, and elsewhere in the operator-
   driven method.

   The two methods also differ in who generates the private/public key
   pair: the operator generates the pair and sends it to the router in
   the operator-driven method, and the router generates its own pair in
   the router-driven method.





<span class="grey">Bush, et al.                 Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   The router-driven method mirrors the model used by traditional PKI
   subscribers; the private key never leaves trusted storage (e.g.,
   Hardware Security Module (HSM)).  This is by design and supports
   classic PKI Certification Policies for (often human) subscribers that
   require the private key only ever be controlled by the subscriber to
   ensure that no one can impersonate the subscriber.  For non-humans,
   this method does not always work.  The operator-driven method is
   motivated by the extreme importance placed on ensuring the continued
   operation of the network.  In some deployments, the same private key
   needs to be installed in the soon-to-be online router that was used
   by the soon-to-be offline router, since this "hot-swapping" behavior
   can result in minimal downtime, especially compared with the normal
   RPKI procedures to propagate a new key, which can take a day or
   longer to converge.

   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 soon-to-be offline router.  This
   motivated the operator-driven method.

   Sections <a href="#section-3">3</a> through <a href="#section-8">8</a> describe the various steps involved for an
   operator to use the two methods to provision new and existing
   routers.  The methods described involve the operator configuring the
   two endpoints (i.e., the management station and the router) and
   acting as the intermediary.  <a href="#section-9">Section 9</a> describes another method that
   requires more-capable routers.

   Useful References: [<a href="./rfc8205" title="&quot;BGPsec Protocol Specification&quot;">RFC8205</a>] describes the details of BGPsec,
   [<a href="./rfc8209" title="&quot;A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests&quot;">RFC8209</a>] specifies the format for the PKCS#10 certification request,
   and [<a href="./rfc8608" title="&quot;BGPsec Algorithms, Key Formats, and Signature Formats&quot;">RFC8608</a>] specifies the algorithms used to generate the PKCS#10
   signature.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Requirements Language</span>

   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
   <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] [<a href="./rfc8174" title="&quot;Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words&quot;">RFC8174</a>] when, and only when, they appear in all
   capitals, as shown here.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Management/Router Communication</span>

   Operators are free to use either the router-driven or the operator-
   driven method as supported by the platform.  Prudent security
   practice recommends router-generated keying, if the delay in
   replacing a router (or router engine) is acceptable to the operator.
   Regardless of the method chosen, operators first establish a
   protected channel between the management system and the router; this



<span class="grey">Bush, et al.                 Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   protected channel prevents eavesdropping, tampering, and message
   forgery.  It also provides mutual authentication.  How this protected
   channel is established is router-specific and is beyond scope of this
   document.  Though other configuration mechanisms might be used, e.g.,
   the Network Configuration Protocol (NETCONF) (see [<a href="./rfc6470" title="&quot;Network Configuration Protocol (NETCONF) Base Notifications&quot;">RFC6470</a>]), the
   protected channel used between the management platform and the router
   is assumed to be an SSH-protected CLI.  See <a href="#appendix-A">Appendix A</a> for security
   considerations for this protected channel.

   The previous paragraph assumes the management-system-to-router
   communications are over a network.  When the management system has a
   direct physical connection to the router, e.g., via the craft port,
   there is no assumption that there is a protected channel between the
   two.

   To be clear, for both of these methods, an initial leap of faith is
   required because the router has no keying material that it can use to
   protect communications with anyone or anything.  Because of this
   initial leap of faith, a direct physical connection is safer than a
   network connection because there is less chance of a monkey in the
   middle.  Once keying material is established on the router, the
   communications channel must prevent eavesdropping, tampering, and
   message forgery.  This initial leap of faith will no longer be
   required once routers are delivered to operators with operator-
   trusted keying material.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Exchange Certificates</span>

   A number of options exist for the operator's management station to
   exchange PKI-related information with routers and with the RPKI
   including:

   o  Using application/pkcs10 media type [<a href="./rfc5967" title="&quot;The application/pkcs10 Media Type&quot;">RFC5967</a>] to extract
      certificate requests and application/pkcs7-mime [<a href="./rfc8551" title="&quot;Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification&quot;">RFC8551</a>] to
      return the issued certificate,

   o  Using FTP or HTTP per [<a href="./rfc2585" title="&quot;Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP&quot;">RFC2585</a>], and

   o  Using the Enrollment over Secure Transport (EST) protocol per
      [<a href="./rfc7030" title="&quot;Enrollment over Secure Transport&quot;">RFC7030</a>].

   Despite the fact that certificates are integrity-protected and do not
   necessarily need additional protection, transports that also provide
   integrity protection are RECOMMENDED.







<span class="grey">Bush, et al.                 Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Setup</span>

   To start, the operator uses the protected channel to install the
   appropriate RPKI Trust Anchor's Certificate (TA Certificate) in the
   router.  This will later enable the router to validate the router
   certificate returned in the PKCS#7 certs-only message [<a href="./rfc8551" title="&quot;Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification&quot;">RFC8551</a>].

   The operator configures the Autonomous System (AS) number to be used
   in the generated router certificate.  This may be the sole AS
   configured on the router or an operator choice if the router is
   configured with multiple ASes.  A router with multiple ASes can
   generate multiple router certificates by following the process
   described in this document for each desired certificate.  This
   configured AS number is also used during verification of keys, if
   generated by the operator (see <a href="#section-6.2">Section 6.2</a>), as well as during
   certificate verification steps (see Sections <a href="#section-7">7</a>, <a href="#section-8">8</a>, and <a href="#section-9">9</a>).

   The operator configures or extracts from the router the BGP
   Identifier [<a href="./rfc6286" title="&quot;Autonomous-System-Wide Unique BGP Identifier for BGP-4&quot;">RFC6286</a>] to be used in the generated router certificate.
   In the case where the operator has chosen not to use unique per-
   router certificates, a BGP Identifier of 0 MAY be used.

   The operator configures the router's access control mechanism to
   ensure that only authorized users are able to later access the
   router's configuration.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Generate PKCS#10</span>

   The private key, and hence the PKCS#10 certification request, which
   is sometimes referred to as a Certificate Signing Request (CSR), may
   be generated by the router or by the operator.

   Retaining the CSR allows for verifying that the returned public key
   in the certificate corresponds to the private key used to generate
   the signature on the CSR.

   NOTE: The PKCS#10 certification request does not include the AS
   number or the BGP Identifier for the router certificate.  Therefore,
   the operator transmits the AS it has chosen on the router as well as
   the BGP Identifier when it sends the CSR to the CA.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Router-Driven Keys</span>

   In the router-driven method, once the protected channel is
   established and the initial setup (<a href="#section-5">Section 5</a>) performed, the operator
   issues a command or commands for the router to generate the public-
   private key pair, to generate the PKCS#10 certification request, and




<span class="grey">Bush, et al.                 Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   to sign the PKCS#10 certification request with the private key.  Once
   the router has generated the PKCS#10 certification request, it
   returns it to the operator over the protected channel.

   The operator includes the chosen AS number and the BGP Identifier
   when it sends the CSR to the CA.

   Even if the operator cannot extract the private key from the router,
   this signature still provides a link between a private key and a
   router.  That is, the operator can verify the proof of possession
   (POP), as required by [<a href="./rfc6484" title="&quot;Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)&quot;">RFC6484</a>].

   NOTE: The CA needs to know that the router-driven CSR is authorized.
   The easiest way to accomplish this is for the operator to mediate the
   communication with the CA.  Other workflows are possible, e.g., where
   the router sends the CSR to the CA but the operator logs in to the CA
   independently and is presented with a list of pending requests to
   approve.  See <a href="#section-9">Section 9</a> for an additional workflow.

   If a router was to communicate directly with a CA to have the CA
   certify the PKCS#10 certification request, there would be no way for
   the CA to authenticate the router.  As the operator knows the
   authenticity of the router, the operator mediates the communication
   with the CA.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Operator-Driven Keys</span>

   In the operator-driven method, the operator generates the public-
   private key pair on a management station and installs the private key
   into the router over the protected channel.  Beware that experience
   has shown that copy-and-paste from a management station to a router
   can be unreliable for long texts.

   The operator then creates and signs the PKCS#10 certification request
   with the private key; the operator includes the chosen AS number and
   the BGP Identifier when it sends the CSR to the CA.

<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  Using PKCS#8 to Transfer Private Keys</span>

   A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
   [<a href="./rfc5958" title="&quot;Asymmetric Key Packages&quot;">RFC5958</a>] and SHOULD be further encapsulated in Cryptographic Message
   Syntax (CMS) SignedData [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] and signed with the operator's End
   Entity (EE) private key.

   The router SHOULD verify the signature of the encapsulated PKCS#8 to
   ensure the 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 SignedData the RPKI CA certificate and relevant



<span class="grey">Bush, et al.                 Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   operators' EE certificate(s).  The router SHOULD inform the operator
   whether or not the signature validates to a trust anchor; this
   notification mechanism is out of scope.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Send PKCS#10 and Receive PKCS#7</span>

   The operator uses RPKI management tools to communicate with the
   Global RPKI system to have the appropriate CA validate the PKCS#10
   certification request, sign the key in the PKCS#10 (i.e., certify
   it), generate a PKCS#7 certs-only message, and publish the
   certificate in the Global RPKI.  External network connectivity may be
   needed if the certificate is to be published in the Global RPKI.

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

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

   2.  Returns the certificate to the operator's management station,
       packaged in a PKCS#7 certs-only message, using the 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 router certificate.

   In the operator-driven method, the operator SHOULD extract the
   certificate from the PKCS#7 certs-only message and verify that the
   public key the operator holds corresponds to the returned public key
   in the PKCS#7 certs-only message.  If the operator saved the PKCS#10,
   it can check this correspondence by comparing the public key in the
   CSR to the public key in the returned certificate.  If the operator
   has not saved the PKCS#10, it can check this correspondence by
   regenerating the public key from the private key and then verifying
   that the regenerated public key matches the public key returned in
   the certificate.

   In the operator-driven method, the operator has already installed the
   private key in the router (see <a href="#section-6.2">Section 6.2</a>).

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Install Certificate</span>

   The operator provisions the PKCS#7 certs-only message into the router
   over the protected channel.

   The router SHOULD extract the certificate from the PKCS#7 certs-only
   message and verify that the public key corresponds to the stored
   private key.  If the router stored the PKCS#10, it can check this



<span class="grey">Bush, et al.                 Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   correspondence by comparing the public key in the CSR to the public
   key in the returned certificate.  If the router did not store the
   PKCS#10, it can check this correspondence by generating a signature
   on any data and then verifying the signature using the returned
   certificate.  The router SHOULD inform the operator whether it
   successfully received the certificate and whether or not the keys
   correspond; the mechanism is out of scope.

   The router SHOULD also verify that the returned certificate validates
   back to the installed TA Certificate, i.e., the entire chain from the
   installed TA Certificate through subordinate CAs to the 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 certs-only message.  The router SHOULD
   inform the operator whether or not the signature validates to a trust
   anchor; this notification mechanism is out of scope.

   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.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Advanced Deployment Scenarios</span>

   More PKI-capable routers can take advantage of increased
   functionality and lighten the operator's burden.  Typically, these
   routers include either preinstalled manufacturer-driven certificates
   (e.g., IEEE 802.1 AR [<a href="#ref-IEEE802-1AR">IEEE802-1AR</a>]) or preinstalled manufacturer-
   driven Pre-Shared Keys (PSKs) as well as PKI-enrollment functionality
   and transport protocol, e.g., CMC's "Secure Transport" [<a href="./rfc7030" title="&quot;Enrollment over Secure Transport&quot;">RFC7030</a>] or
   the original CMC transport protocols [<a href="./rfc5273" title="&quot;Certificate Management over CMS (CMC): Transport Protocols&quot;">RFC5273</a>].  When the operator
   first establishes a protected channel between the management system
   and the router, this preinstalled key material is used to
   authenticate the router.

   The operator's burden shifts here to include:

   1.  Securely communicating the router's authentication material to
       the CA prior to the operator initiating the router's CSR.  CAs
       use authentication material to determine whether the router is
       eligible to receive a certificate.  At a minimum, authentication
       material includes the router's AS number and BGP Identifier as
       well as the router's key material, but it can also include
       additional information.  Authentication material can be
       communicated to the CA (i.e., CSRs signed by this key material
       are issued certificates with this AS and BGP Identifier) or to
       the router (i.e., the operator uses the vendor-supplied
       management interface to include the AS number and BGP Identifier



<span class="grey">Bush, et al.                 Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


       in the router-driven CSR).  The CA stores this authentication
       material in an account entry for the router so that it can later
       be compared against the CSR prior to the CA issuing a certificate
       to the router.

   2.  Enabling the router to communicate with the CA.  While the
       router-to-CA communications are operator-initiated, the
       operator's management interface need not be involved in the
       communications path.  Enabling the router-to-CA connectivity may
       require connections to external networks (i.e., through
       firewalls, NATs, etc.).

   3.  Ensuring the cryptographic chain of custody from the
       manufacturer.  For the preinstalled key material, the operator
       needs guarantees that either no one has accessed the private key
       or an authenticated log of those who have accessed it MUST be
       provided to the operator.

   Once configured, the operator can begin the process of enrolling the
   router.  Because the router is communicating directly with the CA,
   there is no need for the operator to retrieve the PKCS#10
   certification request from the router as in <a href="#section-6">Section 6</a> or return the
   PKCS#7 certs-only message to the router as in <a href="#section-7">Section 7</a>.  Note that
   the checks performed by the router in <a href="#section-8">Section 8</a> (namely, extracting
   the certificate from the PKCS#7 certs-only message, verifying that
   the public key corresponds to the private key, and verifying that the
   returned certificate validated back to an installed trust anchor)
   SHOULD be performed.  Likewise, the router SHOULD notify the operator
   if any of these fail, but this notification mechanism is out of
   scope.

   When a router is so configured, the communication with the CA SHOULD
   be automatically re-established by the router at future times to
   renew the certificate automatically when necessary (see <a href="#section-10">Section 10</a>).
   This further reduces the tasks required of the operator.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Key Management</span>

   Key management not only includes key generation, key provisioning,
   certificate issuance, and certificate distribution, it also includes
   assurance of key validity, key rollover, and key preservation during
   router replacement.  All of these responsibilities persist for as
   long as the operator wishes to operate the BGPsec-speaking router.








<span class="grey">Bush, et al.                 Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Key Validity</span>

   It is critical that a BGPsec-speaking router is signing with a valid
   private key at all times.  To this end, the operator needs to ensure
   the router always has an unexpired certificate.  That is, the key
   used 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:

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

   2.  The operator notes the expiry time of the certificate and uses a
       calendaring program to remind them of the expiry time, and/or

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

   4.  The operator uses 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, additional operators in the same organization should be
   notified as the expiry time approaches, thereby ensuring that the
   forgetfulness of one operator does not affect the entire
   organization.

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

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Key Rollover</span>

   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.

   More information on how to proceed with a key rollover is described
   in [<a href="./rfc8634" title="&quot;BGPsec Router Certificate Rollover&quot;">RFC8634</a>].





<span class="grey">Bush, et al.                 Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>.  Key Revocation</span>

   In certain circumstances, a router's BGPsec certificate may need to
   be revoked.  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 Certificate Revocation List (CRL) as well as re-
   keying the router's certificate.

   The process of revoking an active router key consists of requesting
   the revocation from the CA, the CA actually revoking the router's
   certificate, the re-keying/renewing of the router's certificate
   (possibly) distributing a new key and certificate to the router, and
   distributing the status.  During the time this process takes, the
   operator must decide how they wish to maintain continuity of
   operation (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 disable BGPsec is likely preferred to bringing the
   router offline.

   Routers that support more than one private key, where one is
   operational and other(s) are 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 next generation soon-to-be-
   operational key.  Hopefully, all this can be done without needing to
   take the router offline or reboot it.  For routers that support only
   one operational key, the operators should create or install the new
   private key and then request revocation of the certificate
   corresponding to the compromised private key.

<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>.  Router Replacement</span>

   At the time of writing, routers often generate private keys for uses
   such as Secure Shell (SSH), and the private keys may not be seen or
   exported from the 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 that 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 inserted via a
   protected channel, e.g., SSH, NETCONF (see [<a href="./rfc6470" title="&quot;Network Configuration Protocol (NETCONF) Base Notifications&quot;">RFC6470</a>]), and SNMP.



<span class="grey">Bush, et al.                 Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   This lets the operator escrow the old private key via the mechanism
   used for operator-driven keys (see <a href="#section-6.2">Section 6.2</a>), such that it can be
   reinserted into a replacement router.  The router MAY allow the
   private key to be exported via the protected channel after key
   generation, but this SHOULD be paired with functionality that sets
   the newly generated key into a permanent non-exportable state to
   ensure that it is not exported at a future time by unauthorized
   operations.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Security Considerations</span>

   The router's manual will describe which of the key-generation options
   discussed in the earlier sections of this document a router supports
   or if it supports both of them.  The manual will also describe other
   important security-related information (e.g., how to SSH to the
   router).  After becoming familiar with the capabilities of the
   router, an operator is encouraged to ensure that the router is
   patched with the latest software updates available from the
   manufacturer.

   This document defines no protocols.  So, in some sense, it introduces
   no new security considerations.  However, it relies on many other
   protocols, and the security considerations in the referenced
   documents should be consulted; notably, the documents listed in
   <a href="#section-1">Section 1</a> should be consulted first.  PKI-relying protocols, of which
   BGPsec is one, have many issues to consider -- so many, in fact,
   entire books have been written to address them -- so listing all PKI-
   related security considerations is neither useful nor helpful.
   Regardless, some bootstrapping-related issues that are worth
   repeating are listed here:

   o  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 [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>].

   o  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 is just that: a local matter.

   o  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



<span class="grey">Bush, et al.                 Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


      signer; therefore, transport security is strongly RECOMMENDED.
      The level of security provided by the transport layer's security
      mechanism SHOULD be at least as good as the strength of the BGPsec
      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
      mechanism is up to date, in order to address all known
      implementation bugs.

   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 have global connectivity or CRL-aware software.  The
   operator MUST ensure that the installed CA certificate is valid.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  IANA Considerations</span>

   This document has no IANA actions.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  References</span>

<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>.  Normative References</span>

   [<a id="ref-IEEE802-1AR">IEEE802-1AR</a>]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks - Secure Device Identity", IEEE Std 802.1AR,
              &lt;<a href="https://standards.ieee.org/standard/802_1AR-2018.html">https://standards.ieee.org/standard/802_1AR-2018.html</a>&gt;.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC4086">RFC4086</a>]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>,
              DOI 10.17487/RFC4086, June 2005,
              &lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;.

   [<a id="ref-RFC4253">RFC4253</a>]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", <a href="./rfc4253">RFC 4253</a>, DOI 10.17487/RFC4253,
              January 2006, &lt;<a href="https://www.rfc-editor.org/info/rfc4253">https://www.rfc-editor.org/info/rfc4253</a>&gt;.

   [<a id="ref-RFC5652">RFC5652</a>]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              <a href="./rfc5652">RFC 5652</a>, DOI 10.17487/RFC5652, September 2009,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5652">https://www.rfc-editor.org/info/rfc5652</a>&gt;.




<span class="grey">Bush, et al.                 Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   [<a id="ref-RFC5958">RFC5958</a>]  Turner, S., "Asymmetric Key Packages", <a href="./rfc5958">RFC 5958</a>,
              DOI 10.17487/RFC5958, August 2010,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5958">https://www.rfc-editor.org/info/rfc5958</a>&gt;.

   [<a id="ref-RFC6286">RFC6286</a>]  Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
              Identifier for BGP-4", <a href="./rfc6286">RFC 6286</a>, DOI 10.17487/RFC6286,
              June 2011, &lt;<a href="https://www.rfc-editor.org/info/rfc6286">https://www.rfc-editor.org/info/rfc6286</a>&gt;.

   [<a id="ref-RFC8174">RFC8174</a>]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
              <a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
              May 2017, &lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;.

   [<a id="ref-RFC8608">RFC8608</a>]  Turner, S. and O. Borchert, "BGPsec Algorithms, Key
              Formats, and Signature Formats", <a href="./rfc8608">RFC 8608</a>,
              DOI 10.17487/RFC8608, June 2019,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8608">https://www.rfc-editor.org/info/rfc8608</a>&gt;.

   [<a id="ref-RFC8209">RFC8209</a>]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPsec Router Certificates, Certificate Revocation Lists,
              and Certification Requests", <a href="./rfc8209">RFC 8209</a>,
              DOI 10.17487/RFC8209, September 2017,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8209">https://www.rfc-editor.org/info/rfc8209</a>&gt;.

   [<a id="ref-RFC8551">RFC8551</a>]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", <a href="./rfc8551">RFC 8551</a>, DOI 10.17487/RFC8551,
              April 2019, &lt;<a href="https://www.rfc-editor.org/info/rfc8551">https://www.rfc-editor.org/info/rfc8551</a>&gt;.

   [<a id="ref-RFC8634">RFC8634</a>]  Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
              Certificate Rollover", <a href="https://www.rfc-editor.org/bcp/bcp224">BCP 224</a>, <a href="./rfc8634">RFC 8634</a>,
              DOI 10.17487/RFC8634, August 2019,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8634">https://www.rfc-editor.org/info/rfc8634</a>&gt;.

<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>.  Informative References</span>

   [<a id="ref-RFC2585">RFC2585</a>]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP",
              <a href="./rfc2585">RFC 2585</a>, DOI 10.17487/RFC2585, May 1999,
              &lt;<a href="https://www.rfc-editor.org/info/rfc2585">https://www.rfc-editor.org/info/rfc2585</a>&gt;.

   [<a id="ref-RFC3766">RFC3766</a>]  Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", <a href="https://www.rfc-editor.org/bcp/bcp86">BCP 86</a>,
              <a href="./rfc3766">RFC 3766</a>, DOI 10.17487/RFC3766, April 2004,
              &lt;<a href="https://www.rfc-editor.org/info/rfc3766">https://www.rfc-editor.org/info/rfc3766</a>&gt;.







<span class="grey">Bush, et al.                 Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   [<a id="ref-RFC5273">RFC5273</a>]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", <a href="./rfc5273">RFC 5273</a>,
              DOI 10.17487/RFC5273, June 2008,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5273">https://www.rfc-editor.org/info/rfc5273</a>&gt;.

   [<a id="ref-RFC5480">RFC5480</a>]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", <a href="./rfc5480">RFC 5480</a>, DOI 10.17487/RFC5480, March 2009,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5480">https://www.rfc-editor.org/info/rfc5480</a>&gt;.

   [<a id="ref-RFC5647">RFC5647</a>]  Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
              Secure Shell Transport Layer Protocol", <a href="./rfc5647">RFC 5647</a>,
              DOI 10.17487/RFC5647, August 2009,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5647">https://www.rfc-editor.org/info/rfc5647</a>&gt;.

   [<a id="ref-RFC5656">RFC5656</a>]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              <a href="./rfc5656">RFC 5656</a>, DOI 10.17487/RFC5656, December 2009,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5656">https://www.rfc-editor.org/info/rfc5656</a>&gt;.

   [<a id="ref-RFC5967">RFC5967</a>]  Turner, S., "The application/pkcs10 Media Type", <a href="./rfc5967">RFC 5967</a>,
              DOI 10.17487/RFC5967, August 2010,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5967">https://www.rfc-editor.org/info/rfc5967</a>&gt;.

   [<a id="ref-RFC6187">RFC6187</a>]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
              Shell Authentication", <a href="./rfc6187">RFC 6187</a>, DOI 10.17487/RFC6187,
              March 2011, &lt;<a href="https://www.rfc-editor.org/info/rfc6187">https://www.rfc-editor.org/info/rfc6187</a>&gt;.

   [<a id="ref-RFC6470">RFC6470</a>]  Bierman, A., "Network Configuration Protocol (NETCONF)
              Base Notifications", <a href="./rfc6470">RFC 6470</a>, DOI 10.17487/RFC6470,
              February 2012, &lt;<a href="https://www.rfc-editor.org/info/rfc6470">https://www.rfc-editor.org/info/rfc6470</a>&gt;.

   [<a id="ref-RFC6484">RFC6484</a>]  Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
              Policy (CP) for the Resource Public Key Infrastructure
              (RPKI)", <a href="https://www.rfc-editor.org/bcp/bcp173">BCP 173</a>, <a href="./rfc6484">RFC 6484</a>, DOI 10.17487/RFC6484, February
              2012, &lt;<a href="https://www.rfc-editor.org/info/rfc6484">https://www.rfc-editor.org/info/rfc6484</a>&gt;.

   [<a id="ref-RFC6668">RFC6668</a>]  Bider, D. and M. Baushke, "SHA-2 Data Integrity
              Verification for the Secure Shell (SSH) Transport Layer
              Protocol", <a href="./rfc6668">RFC 6668</a>, DOI 10.17487/RFC6668, July 2012,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6668">https://www.rfc-editor.org/info/rfc6668</a>&gt;.

   [<a id="ref-RFC7030">RFC7030</a>]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", <a href="./rfc7030">RFC 7030</a>,
              DOI 10.17487/RFC7030, October 2013,
              &lt;<a href="https://www.rfc-editor.org/info/rfc7030">https://www.rfc-editor.org/info/rfc7030</a>&gt;.





<span class="grey">Bush, et al.                 Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   [<a id="ref-RFC8205">RFC8205</a>]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", <a href="./rfc8205">RFC 8205</a>, DOI 10.17487/RFC8205, September
              2017, &lt;<a href="https://www.rfc-editor.org/info/rfc8205">https://www.rfc-editor.org/info/rfc8205</a>&gt;.

   [<a id="ref-SP800-57">SP800-57</a>]
              National Institute of Standards and Technology (NIST),
              "Recommendation for Key Management - Part 1: General",
              NIST Special Publication 800-57 Revision 4,
              DOI 10.6028/NIST.SP.800-57pt1r4, January 2016,
              &lt;<a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/</a>
              <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf">NIST.SP.800-57pt1r4.pdf</a>&gt;.








































<span class="grey">Bush, et al.                 Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Management/Router Channel Security</span>

   Encryption, integrity, authentication, and key-exchange algorithms
   used by the protected channel should be of equal or greater strength
   than the BGPsec keys they protect, which for the algorithm specified
   in [<a href="./rfc8608" title="&quot;BGPsec Algorithms, Key Formats, and Signature Formats&quot;">RFC8608</a>] is 128 bits; see [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>] and [<a href="#ref-SP800-57">SP800-57</a>] for
   information about this strength claim as well as [<a href="./rfc3766" title="&quot;Determining Strengths For Public Keys Used For Exchanging Symmetric Keys&quot;">RFC3766</a>] 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), and do not use Triple-DES (112 bits of security).
   Suggested minimum algorithms would be AES-128, specifically the
   following:

   o  aes128-cbc [<a href="./rfc4253" title="&quot;The Secure Shell (SSH) Transport Layer Protocol&quot;">RFC4253</a>] and AEAD_AES_128_GCM [<a href="./rfc5647" title="&quot;AES Galois Counter Mode for the Secure Shell Transport Layer Protocol&quot;">RFC5647</a>] for
      encryption,

   o  hmac-sha2-256 [<a href="./rfc6668" title="&quot;SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol&quot;">RFC6668</a>] or AESAD_AES_128_GCM [<a href="./rfc5647" title="&quot;AES Galois Counter Mode for the Secure Shell Transport Layer Protocol&quot;">RFC5647</a>] for
      integrity,

   o  ecdsa-sha2-nistp256 [<a href="./rfc5656" title="&quot;Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer&quot;">RFC5656</a>] for authentication, and

   o  ecdh-sha2-nistp256 [<a href="./rfc5656" title="&quot;Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer&quot;">RFC5656</a>] 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 at least as good as the security
   offered by the BGPsec keys; x509v3-ecdsa-sha2-nistp256 [<a href="./rfc6187" title="&quot;X.509v3 Certificates for Secure Shell Authentication&quot;">RFC6187</a>]
   could be used for authentication.

   The protected channel must provide confidentiality, authentication,
   and integrity and replay protection.


















<span class="grey">Bush, et al.                 Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  An Introduction to BGPsec Key Management</span>

   This appendix is informative.  It attempts to explain some of the PKI
   jargon.

   BGPsec speakers send signed BGPsec updates that are verified by other
   BGPsec speakers.  In PKI parlance, the senders are referred to as
   "signers", and the receivers are referred to as "relying parties".
   The signers with which we are concerned here are routers signing
   BGPsec updates.  Signers use private keys to sign, and relying
   parties use the corresponding public keys, in the form of X.509
   public key certificates, to verify signatures.  The third party
   involved is the entity that issues the X.509 public key certificate,
   the Certification Authority (CA).  Key management is all about making
   these key pairs and the certificates, as well as ensuring that the
   relying parties trust that the certified public keys in fact
   correspond to the signers' private keys.

   The specifics of key management greatly depend on the routers as well
   as management interfaces provided by the routers' vendor.  Because of
   these differences, it is hard to write a definitive "how to", but
   this guide is intended to arm operators with enough information to
   ask the right questions.  The other aspect that makes this guide
   informative is that the steps for the do-it-yourself (DIY) approach
   involve arcane commands while the GUI-based vendor-assisted
   management console approach will likely hide all of those commands
   behind some button clicks.  Regardless, the operator will end up with
   a BGPsec-enabled router.  Initially, we focus on the DIY approach and
   then follow up with some information about the GUI-based approach.

   The first step in the DIY approach is to generate a private key.
   However, in fact, what you do is create a key pair: one part (the
   private key) is kept very private, and the other part (the public
   key) is given out to verify whatever is signed.  The two methods for
   how to create the key pair are the subject of this document, but it
   boils down to either doing it on-router (router-driven) or off-router
   (operator-driven).

   If you are generating keys on the router (router-driven), then you
   will need to access the router.  Again, how you access the router is
   router-specific, but generally the DIY approach involves using the
   CLI and accessing the router either directly via the router's craft
   port or over the network on an administrative interface.  If
   accessing the router over the network, be sure to do it securely
   (i.e., use SSHv2).  Once logged into the router, issue a command or a
   series of commands that will generate the key pair for the algorithms
   referenced in the main body of this document; consult your router's
   documentation for the specific commands.  The key-generation process



<span class="grey">Bush, et al.                 Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   will yield one or more files containing the private key and the
   public key; the file format varies depending on, among other things,
   the arcane command the operator issued; however, the files are
   generally DER- or PEM-encoded.

   The second step is to generate the certification request, which is
   often referred to as a Certificate Signing Request (CSR) or PKCS#10
   certification request, and to send it to the CA to be signed.  To
   generate the CSR, the operator issues some more arcane commands while
   logged into the router; using the private key just generated to sign
   the certification request with the algorithms referenced in the main
   body of this document; the CSR is signed to prove to the CA that the
   router has possession of the private key (i.e., the signature is the
   proof-of-possession).  The output of the command is the CSR file; the
   file format varies depending on the arcane command you issued, but
   generally the files are DER- or PEM-encoded.

   The third step is to retrieve the signed CSR from the router and send
   it to the CA.  But before sending it, you need to also send the CA
   the subject name (i.e., "ROUTER-" followed by the AS number) and
   serial number (i.e., the 32-bit BGP Identifier) for the router.  The
   CA needs this information to issue the certificate.  How you get the
   CSR to the CA is beyond the scope of this document.  While you are
   still connected to the router, install the trust anchor for the root
   of the PKI.  At this point, you no longer need access to the router
   for BGPsec-related initiation purposes.

   The fourth step is for the CA to issue the certificate based on the
   CSR you sent.  The certificate will include the subject name, serial
   number, public key, and other fields; it will also be signed by the
   CA.  After the CA issues the certificate, the CA returns the
   certificate and posts the certificate to the RPKI repository.  Check
   that the certificate corresponds to the public key contained in the
   certificate by verifying the signature on the CSR sent to the CA;
   this is just a check to make sure that the CA issued a certificate
   that includes a public key that is the pair of the private key (i.e.,
   the math will work when verifying a signature generated by the
   private key with the returned certificate).

   If generating the keys off-router (operator-driven), then the same
   steps are used as with on-router key generation (possibly with the
   same arcane commands as those used in the on-router approach).
   However, no access to the router is needed, and the first three steps
   are done on an administrative workstation:

   Step 1:  Generate key pair.
   Step 2:  Create CSR and sign CSR with private key.
   Step 3:  Send CSR file with the subject name and serial number to CA.



<span class="grey">Bush, et al.                 Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


   After the CA has returned the certificate and you have checked the
   certificate, you need to put the private key and trust anchor in the
   router.  Assuming the DIY approach, you will be using the CLI and
   accessing the router either directly via the router's craft port or
   over the network on an admin interface; if accessing the router over
   the network, make doubly sure it is done securely (i.e., use SSHv2)
   because the private key is being moved over the network.  At this
   point, access to the router is no longer needed for BGPsec-related
   initiation purposes.

   NOTE: Regardless of the approach taken, the first three steps could
   trivially be collapsed by a vendor-provided script to yield the
   private key and the signed CSR.

   Given a GUI-based vendor-assisted management console, all of these
   steps will likely be hidden behind pointing and clicking the way
   through BGPsec-enabling the router.

   The scenarios described above require the operator to access each
   router, which does not scale well to large networks.  An alternative
   would be to create an image, perform the necessary steps to get the
   private key and trust anchor on the image, and then install the image
   via a management protocol.

   One final word of advice: certificates include a notAfter field that
   unsurprisingly indicates when relying parties should no longer trust
   the certificate.  To avoid having routers with expired certificates,
   follow the recommendations in the Certification Policy (CP) [<a href="./rfc6484" title="&quot;Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)&quot;">RFC6484</a>]
   and make sure to renew the certificate at least one week prior to the
   notAfter date.  Set a calendar reminder in order not to forget!





















<span class="grey">Bush, et al.                 Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8635">RFC 8635</a>                Router Keying for BGPsec             August 2019</span>


Authors' Addresses

   Randy Bush
   IIJ &amp; Arrcus
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   United States of America

   Email: randy@psg.com


   Sean Turner
   sn3rd

   Email: sean@sn3rd.com


   Keyur Patel
   Arrcus, Inc.

   Email: keyur@arrcus.com






























Bush, et al.                 Standards Track                   [Page 21]
</pre>