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: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Saturday, February 23, 2013 10:41 AM
To: [email protected]
Cc: [email protected]
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
[email protected]
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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
