[Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 21 January 2019 17:27 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27234124D68; Mon, 21 Jan 2019 09:27:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com>
Date: Mon, 21 Jan 2019 09:27:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8gW1UGzDj_RRHsqmcGJBodVdeTY>
Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 17:27:53 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-rtr-keying-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [Sidrops] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Sean Turner
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Randy Bush
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Benjamin Kaduk
- Re: [Sidrops] Benjamin Kaduk's No Objection on dr… Sean Turner