> -----Original Message----- > From: Sean Turner [mailto:turn...@ieca.com] > > > Comments inline. [WEG] me too > > > We're trying to head off the typical knee-jerk reaction about non-client > generated keys where somebody says oh no can't do that because that's > what their BPKI does. But, I get your point. How about: > > The difference between the two methods is where the keys are generated: > on the router in the router-driven method and elsewhere in the operator- > driven model. Different equipment necessitates the two methods. Some > equipment doesn't allow the private key to be off-loaded while other > equipment does. Off-loading private keys supports hot-swappable routers > that need to have the same private key needs installed in the soon-to-be > online router that was installed in the soon-to-be offline router. [WEG] yes this is much clearer > > Do you think we need to say anything like: > > NOTE: Unlike humans, routers can be easily cloned; hence, operators > generating the private keys make sense. > [WEG] I'm not sure I follow the logic on this one, so I don't have a good answer for you - is it meant to be a justification of using the operator-generated model, or a recommendation to do so, or something else?
> > > > The key (pun very > much intended) thing here is to highlight things that are different from > normal provisioning and explain why they're important. > > I was shooting for something more narrative, but yeah I could see that > it would make sense to say here's what's different. Now, any idea where > this BCP is? :) I'm not sure there is one. [WEG] There isn't a BCP in the IETF sense of the word. I was thinking more generally in terms of the fact that most folks who can provision a router from bare metal know how to do this, IOW, it's common practice. If we really need a reference, modulus the specific commands being typed, any "how to enable SSH access to your RouterBrand (tm) router using the fantastic and intuitive IJunSRScreenOS CLI" documentation would probably be sufficient to serve as a baseline for something like: "this document assumes that the reader is capable of provisioning a router for SSH access per the manufacturer's instructions. The following additional steps are necessary/recommended to prepare for keying the router for SIDR because of foo" where foo would be any security recommendations like requiring certificate-based authentication, etc. Basically, limit your discussion to things that are either critical enough that you don't want to simply assume they'll be present in the vendor documentati on, or different from the norm because that's what's necessary for your process to be secure. > > > Ah for this section, the only key transferred is public and it's in the > PKCS#10, which is the only thing that gets transferred. But, you asking > this question makes me think I should make it clearer about what's being > transfer and why anybody'd care. [WEG] Yes, your brief explanation above makes this much clearer, so adding it will be helpful > > > Also, I don't follow your last sentence "...linkage between private > key and a router..." - why is that important? > > The idea is that you want to be able to know the router's got the > private key associated with the public key. Another way to say this is > POP - and I agree this could be made clearer. Something like: > > Note that even if the operator can not get the private key off the > router this still provides a linkage between a private key and a > router. That is the server can do a proof of possession (POP), > as required by [RFC6484]. [WEG] Makes more sense, but "this" is ambiguous in the above sentence, even when read with the preceding text. Replacing "this" with its antecedent will help. > > > 3.2 "installed over the ssh session..." - are we talking simple copy > and paste of a huge string of text representing the key, or is it > actually SCP/SFTP of a file that is then read into the router's config > via additional commands? > > If you're talking copy/paste, it's probably worth warning that for > keys over a certain size, this method is error-prone. I've seen a lot of > mangled config because someone exceeded a paste buffer when trying to > copy/paste a config, especially over a 9600 bps console at the other end > of 90ms of latency. > > An excellent point, but I'm sure hope it's commands and not ctrl-c/v. [WEG] well... I (and probably lots of other people) learned from the school of hard knocks on this one, so I'd say it's a point worth making explicitly. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
