Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt

[Sean Turner <[e-mail]>]

Wes,

Comments inline.

spt

On 2/27/13 5:39 PM, George, Wes wrote:
> I gave this a review since I am one of the folks who raised my hand as willing to be the resident PKI n00b to make sure that things like this are clear to "router guys" who are dealing with PKI for the first time outside of maybe generating the SSH keys for tty access to a router.

Thanks for following through.

> The second paragraph of the intro, starting with the sentence "The router-driven model is most..." is difficult to parse (grammatically). I recommend re-wording to eliminate "often times for human subscribers" from the middle of the phrase and generally streamline the point being made here.

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.

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.

> Editorial nit: multiple instances of %s/drive/driven

I must have had Bullitt on the TV in the background when I was revising 
this draft.

> 3. instead of serial/craft, I'd just say console.
> Or more generally, you could refer to in-band management vs out of band, as that covers a wider set of scenarios than specifically referring to an Ethernet port and a serial port. Yes, that doesn't exactly cover the hair-split when people use a management Ethernet port connected to a separate management network for "in band" (non-console) management of the device, but maybe that's clear enough, I don't know.

I can go with in-band vs out-of-band management.

> I also don't think proprietary is the right word. Console access via a terminal server is pretty universal, and unless there's some sort of a tool pushing out the initial config snippets over console to bootstrap the box so that it can talk to it inband and finish the provisioning, "operator going typey-typey on a terminal" is definitely not proprietary either.

roger that console it is.

> Another thought - console access via remote terminal server isn't actually secure in every case. In a typical setup you have:
> User host -> (ssh) bastion/jump box -> (telnet) local terminal server -> RS232/USB connection to console
> Unless the path between the jump box and the local terminal server is such that it is nearly impossible to sniff the traffic (private network, direct connection, etc) using this to provision sensitive config might be ill-advised. Might be worth explicitly stating that for this reason, use of the console to provision the SIDR keys is NOT recommended.

This sounds like a good security consideration.

> It's not clear to me whether the method being described in this first part of section 3 is actually important. Do you actually have to do something different in the way that you bring a router online (get it basic connectivity to the network) in this process in order to preserve proper security and trust for the keys, or is this just illustrating a typical process to provision a router from bare metal such that you have secure access to it to further manipulate the configuration? Is certificate-based authentication (instead of password auth) a MUST, or a SHOULD, or does it matter? If this is just illustrating a standard example, you can probably just say something like "this assumes that standard (BCP?) procedures have been followed to initially configure the router for secure remote access, via either inband or out of band means" and then just specify that it's necessary to have the secure connection between the router and operator before the router keying for SIDR is done
  (because

....). Some of this is down in the security considerations today, and I 
think it's important to actually discuss it here instead since it's 
basically a critical part of the provisioning process. 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.

> 3.1 - wouldn't it be sFTP/SCP or HTTPS or some similar?

I think you're referring to this:

  The response can be returned using
  the application/pkcs7-mime media type [RFC5751] if the router
  supports protocols such as FTP and HTTP.

And the answer might be maybe.  In the router-generated case, what's 
being returned in the public key certificate, which is well going to be 
made public so it's not necessary to secure it.  Then, again if there's 
a protected channel open continuing to use it is okay.  Not sure how to 
explain that but I can give it a shot.

> Direct/indirect makes sense, but the process for indirect transfer is a little light on details - what steps must be taken to ensure that the keys are not compromised in this transfer, either from the router or to the RPKI CA? Even a reference to section 5 might be enough to cover this.

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.

> 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].

> 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.

> 5. when you talk about offload methods, you should probably specify the required/recommended security precautions associated with handling the key so that it isn't intercepted across the transfer method used (e.g. use SNMPv3 with encryption, use sFTP/SCP, CLI with SSH, etc, as well as any considerations around chain of possession and level of trust as the keys are stored and transferred between old and new box. There are a lot of risk factors if a tech is transferring it to his (possibly compromised) laptop when compared with transferring to parts of the infrastructure (a config repository server, for example) that are properly hardened.
> Also need to discuss sneakernet transfer, where I dump the key to a local storage device so that the tech can plug it into the new RP/RE and upload it that way. This is sometimes important if the box is having issues and as a result has limited connectivity to offload the keys. Any considerations to ensure proper security in a transfer like that?

All good points and that means I need to get out a new version ;)

> Thanks,
>
> Wes George
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Saturday, February 23, 2013 10:41 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Secure Inter-Domain Routing Working
>> Group of the IETF.
>>
>>        Title           : Router Keying for BGPsec
>>        Author(s)       : Sean Turner
>>                            Keyur Patel
>>                            Randy Bush
>>        Filename        : draft-ietf-sidr-rtr-keying-01.txt
>>        Pages           : 9
>>        Date            : 2013-02-23
>>
>> Abstract:
>>     BGPsec-speaking routers must be provisioned with private keys and the
>>     corresponding public key must be published in the global RPKI
>>     (Resource Public Key Infrastructure).  This document describes two
>>     ways of provisioning public/private keys, router-driven and operator-
>>     driven.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-01
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>
> 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.
>