Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-06
Discuss
Yes
Warren Kumari
No Objection
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 03 and is now closed.
Warren Kumari
Yes
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
Discuss
[Treat as non-blocking comment]
(2019-01-23 for -03)
Sent
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D13996 DETAIL 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
Yes
(2019-01-22 for -03)
Not sent
No strong opinion on document status.
Deborah Brungard Former IESG member
Yes
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 scope. I liked Appendix B - Thanks! It's not so scary - especially with good automation tools.
Ignas Bagdonas Former IESG member
Yes
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. --------------------------------------------------------------------------- §3: > - 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. --------------------------------------------------------------------------- §2: > 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 used...it 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? §10: - "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 method 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 thereafter. 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
Hello, 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.