Skip to main content

Router Keying for BGPsec

Note: This ballot was opened for revision 03 and is now closed.

Warren Kumari
Roman Danyliw
No Objection
Comment (2019-05-06 for -05) Sent
Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes.  A few additional items:

(1) Typos:
** Section 5.2.1.  s/operators's/operators'/
** Appendix B.  s/pubic/public/

(2) Section 10
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.   

It seems odd to say there is a large body of knowledge of relevant issues that won’t be discussed/cited/referenced here.

(2) Appendix B.  The n00b Guide to BGPsec Key Management

It seems derogatory to refer to a section as being for “n00bs”.  I would recommend alternative language.
Eric Rescorla Former IESG member
Discuss [Treat as non-blocking comment] (2019-01-23 for -03) Sent
Rich version of this review at:

S 2.
>      Operators are free to use either the router-driven or operator-driven
>      method as supported by the platform.  Regardless of the method
>      chosen, operators first establish a protected channel between the
>      management system and the router.  How this protected channel is
>      established is router-specific and is beyond scope of this document.

This seems rather under-specified. Given that we know that people are
not careful about this, I think you need to specify some sort of
minimum requirements for this channel. That need not be a particular
protocol, but it needs to specify the security properties it provides.
I see you have some SHOULD-level language later, but I think you need
MUST level, and as noted below, I think the guidance is wrong.

S 5.2.
>      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 linkage between a private key and a
>      router.  That is, the operator can verify the proof of possession
>      (POP), as required by [RFC6484].

It's not clear to me what is being claimed in terms of PoP here. As I
understand it, the certificate is a binding between the AS number/BGP
identifier pair and the public key, but if neither of those is in the
PKCS#10 request, then they're not signed over by the private key, and
so PoP isn't really operative. The relevant question is whether if I
obtain the PKCS#10 request I can obtain a certificate for an identity
other than the intended one.

S 5.2.1.
>      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
>      operator's 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.

I don't understand what security this is intended to provide. As I
understand it, the way this works is that the operator signs the
PKCS#8 package and then sends it to the router, which verifies the
signature. This verification is performed based on a key configured by
the operator, right? But in that case, if someone obtains operator
access to the router, they can just configure their own key, thus
bypassing the signature check.
Secondarily, I don't understand how this works if the RPKI CA
certificate is included in the SignedData, because then how do I
validate it against a trust anchor. Finally, how does the router know
which of the large number of EEs signed by the RPKI CA it should
accept signed PKCS#8 messages from.

S 6.
>      private key it holds corresponds to the returned public key.  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 generating a signature on any data and then
>      verifying the signature using the returned certificate.

It is not clear to me that this is correct. You seem to be assuming
that it given a key pair (K_priv, K_pub), it is not possible to
generate a new key K_pub' that will validate signatures made with
K_priv. This isn't ordinarily an assumption we make of digital
signature systems.

S 8.
>          the CA prior to operator initiating the router's CSR.  CAs use
>          authentication material to determine whether the router is
>          eligible to receive a certificate. Authentication material at a
>          minimum includes the router's AS number and BGP Identifier as
>          well as the router's key material, but can also include
>          additional information. Authentication material can be

Surely it also includes some information that allows the router to
prove it is entitled to a key with that AS and BGP identifier, but I'm
not seeing this here.

S 12.1.
>      CSR you sent; the certificate will include the subject name, serial
>      number, public key, and other fields as well as being 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 private key by verifying the
>      signature on the CSR sent to the CA; this is just a check to make

This is not the right check. The CSR contains the public key. If you
want to check, make sure it is identical to the one in the cert.
Alexey Melnikov Former IESG member
Yes (2019-01-22 for -03) Not sent
No strong opinion on document status.
Deborah Brungard Former IESG member
Yes (2019-01-23 for -03) Not sent
I agree with the status as BCP. It is describing current practices.

On some other comments:

I like having both approaches in the same document vs. two different BCPs. I don't see the
need to say "which is better" (Alvaro's comment). The document is quite clear on the different uses.
It is dependent on much more than what is described here. And as section 8 says, it is becoming blurred.

I think Appendix A is fine as separate from the main document. As section 2 says it is outside the

I liked Appendix B - Thanks! It's not so scary - especially with good automation tools.
Ignas Bagdonas Former IESG member
Yes (2019-01-24 for -03) Not sent
A nit: s/NetConf/NETCONF
Adam Roach Former IESG member
No Objection
No Objection (2019-01-22 for -03) Sent
Thanks to the authors for a well-written and clear document. I have one
substantive comment, and a minor editorial nit.



>  - Using FTP or HTTP per [RFC2585], and

It's not clear from a casual examination whether use of unencrypted and
non-integrity-protected channels for these operations are safe. I would expect
to see a discussion of this in this section and/or section 10. The closest I
could find is the SHOULD-strength (!) recommendation for transport-level
security for private key transport.

Without a more thorough analysis, I suspect we should more strongly deprecate
the use of unencrypted/non-integrity-protected transports. This document is,
after all, supposed to be calling out best practice; and, in 2019, that really
does entail transport security except under the most exceptional circumstances.



>  Though other configuration mechanisms might be used, e.g.  NetConf
>  (see [RFC6470]), the protected the protected channel between the

Nit: duplicate "...the protected..."
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2019-03-05 for -04) Sent
Thank you for addressing my DISCUSS and COMMENT.
Alvaro Retana Former IESG member
No Objection
No Objection (2019-01-23 for -03) Sent
(1) I don't really have a strong objection for this document being a BCP.  However, while documenting two different methods, there is no clear indication of "what is believed to be the best" [rfc2026], or even better, which method should be used in what situations.  I understand that operators have different preferences/needs and that prescribing one method as the default in not the right thing to do.  

I would really like to see some text (maybe a "Deployment Considerations" section) that talks about when one or the other might be preferred/considered.

(2) §4: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286]

(3) §4: "In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the BGP Identifier as always being non-zero.  rfc8209 says that "if the same certificate is issued to more than one router (and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer."  It seems to me that it doesn't matter which ID is just can't be 0.  The simple fix is to just remove the sentence.

(4) §8: "Enabling the router-to-CA connectivity MAY require connections to external networks (i.e., through firewalls, NATs, etc.)."  That "MAY" is out of place because this sentence is just stating a fact.

(5) §8: "Note that the checks performed by the router in Section 7...SHOULD be performed."  Besides confirming the checks from §7, I'm not sure what this sentence really contributes...but I do think that the "SHOULD" is out of place because the Normative language is already in §7.  

(6) Nits
s/used by the the/used by the
s/corresponds to the private used/corresponds to the private key used
Ben Campbell Former IESG member
No Objection
No Objection (2019-01-22 for -03) Sent
- General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct status?  (I agree with BCP, by the way.)

- I share Benjamin's concern about the idea of moving private keys between routers as a "need" vs "something people do".

§5.2.1: "The router should inform the operator
whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope."

Should that be normative?

§9.3: The second paragraph is a single convoluted sentence. Can it be broken into simpler sentences?


- "This document defines no protocols. So, in some sense, it introduces
no new security considerations."

I think practices can absolutely come with security considerations. For example, the practice of moving private keys between routers.

- "Private key protection in transit": Is there no expectations that transmitted private keys would have object-level encryption?

§A: I'm curious why this is not part of the main-body security considerations?
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-01-21 for -03) Sent
I know the intended status has been beaten to near death already, but I
could see this as Informational as well as BCP.

Section 1

                                      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

As the secdir review notes, there is no need to copy private keys to hot-swap routers
(unless there is something special about the "hot-swap" case that nullifies
the arguments he made?).

It rather seems that we should avoid framing this behavior as justified by
a need for hot-swapping, but rather as something that people do to work
around processes that do not admit the more secure workflow, as an
operational reality.

Section 2

   (see [RFC6470]), the protected the protected channel between the

nit: duplicate "the protected"

Section 5

   The PKCS#10 request SHOULD be saved to enable verifying that the
   returned public key in the certificate corresponds to the private
   used to generate the signature on the CSR.

I mostly assume this is done by the party that generates the CSR, though
perhaps one could read it as being done on the router always.  (I guess
later on we do recommend both the operator and router to do this
verification.) This could be reworded, though, either to remove the 2119
language ("Retaining the CSR allows for verifying that [...]" or to apply
to the actual verification as opposed to just the saving.

Section 5.1

   NOTE: If a router were 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.

nit: I think that the thing we care about here is the CA's ability to show
that the request is authorized.  The operator is assumed to have an
account/relationship with the CA and a channel via which to authorize
cert-signing requests.  In particular, "no way" is a rather strong
statement, and would seem to deny the possibility of a three-party workflow
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.
(It would also preclude the operator from delegating their authorization at
the CA to the router, as described in Section 8.)

Section 5.2 ("Operator-Generated Keys")

   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 operator can verify the proof of possession
   (POP), as required by [RFC6484].

This paragraph seems a bit of a non-sequitur -- if the operator just
generated the key, it sure isn't going to need to extract the private key
from the router to sign something using it!

Section 6

   In the operator-generated method, the operator SHOULD extract the
   certificate from the PKCS#7 certs-only message, and verify that the
   private key it holds corresponds to the returned public key.  If the

nit: "private key it holds" is the one the operator holds, not the PKCS#7
certs-only message.  It's probably worth disambiguating, here.

Section 7

   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.

Why are we talking about PKCS#8 (asymmetric key transport) signatures here
at all?  This is the section about installing certificates!  I guess I am
not terribly familiar with the RPKI, but in the Web PKI at least it's quite
uncommon for the CA to be generating the private keys, so mentioning these
together is a non sequitur to me.

Section 8

   More PKI-capable routers can take advantage of this increased
   functionality and lighten the operator's burden.  Typically, these

nit: most readers will not bind "this" to the right thing and will instead
be left confused.

Why do we not mention the need to get the manufacturer-installed key
material (or information thereof) to the operator?

   When a router is so configured, the communication with the CA SHOULD
   be automatically re-established by the router at future times to
   renew or rekey the certificate automatically when necessary (See
   Section 9). This further reduces the tasks required of the operator.

Mentioning renewing certificates is natural, as they have a stated end time
to prepare for.  Re-keying certificates is something of a different matter,
and it would be nice to provide (a link to) some guidance on what
timescales at which to rekey, if we're mentioning rekeying here.
(draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I
did not see much concrete on this point.)

Section 9.4

   Currently routers often generate private keys for uses such as SSH,
   and the private keys may not be seen or off-loaded 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
   which accesses the router must be updated with the new keys.  Also,

This seems to be talking about key management for keys other than
BGPsec-signing keys.  Isn't that out of scope for this document?

   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

Making this a SHOULD is perhaps an overstatement, since AFAICT this
functionality is not useful for the stated purpose unless the operator has
access to private keys directly (whether by virtue of the operator having
generated the keys or an extraction interface on the current routers).
This is an inherent tradeoff, as stated, between the delay in
update/distribution of public keys in the RPKI vs. reducing the risk of
unauthorized key access.  I'm not making this a Discuss point because it's
not exactly my tradeoff to make, but I do want to be sure that this is
actually the tradeoff that SIDROPS wants to present to the community.

   protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP.  This
   lets the operator escrow the old private key via the mechanism used
   for operator-generated keys, see Section 5.2, such that it can be re-
   inserted into a replacement router. The router MAY allow the private
   key to be to be off-loaded via the protected channel, but this SHOULD
   be paired with functionality that sets the key into a permanent non-
   exportable state to ensure that it is not off-loaded at a future time
   by unauthorized operations.

This last sentence is a somewhat different topic and could probably stand
alone as its own paragraph.  This would also provde the opportunity to
clarify that this offload interface is intended for use in conjunction with
key generation, and the permanent non-exportable state to be applied

Appendix A

I agree with Mirja about the duplication of content and thus non-need for
normative language.
Martin Vigoureux Former IESG member
No Objection
No Objection (2019-01-24 for -03) Sent

thank you for this Document.
I only have a couple of questions:

   In the operator-generated method, the operator SHOULD extract the
   certificate from the PKCS#7 certs-only message, and verify that the
   private key it holds corresponds to the returned public key.

   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. 

I believe SHOULD applies to extract and to verify, correct?
But I wonder why isn't that a MUST, or asked differently, what could happen wrong if that verification was not done?

Thank you
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-01-21 for -03) Sent
I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in the security considerations section. If not, it might be worth moving Appendix A to the main body of the document.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -03) Not sent

Suresh Krishnan Former IESG member
No Objection
No Objection (for -03) Not sent

Terry Manderson Former IESG member
No Objection
No Objection (2019-01-23 for -03) Sent
[Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought]

Thank you for a concise document, and especially thank you for the very informal appendix ("B") to explain BGPsec/PKI key management to people who are more concerned with making sure packets go from "here" to "there" and not be crypto key management experts.

I have no strong concerns about document status, but BCP feels about right to me given the art of dealing with key material on routing kit is likely to evolve as experience dictates - that said, I won't be out of shape if the sponsoring AD and the rest of the IESG feels otherwise - however I see that BCP looks like the consensus at this stage.

I'm torn about the absence of a clear recommendation to choose between a router-method operator-method. On one hand it seems a deficiency to leave it as "free to choose" without providing a set of considerations that may help direct the operators naive choice, and yet on the other hand the experience gained thus far appears limited and this BCP is yet to find its way, and may well be updated in future.