Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt

From: [email-masked]
Date: Thu, 12 Sep 2013 16:08:12 -0700

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-02.txt
	Pages           : 9
	Date            : 2013-09-12

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Sep 2013 19:10:45 -0400

Better late than never?

I believe this version addresses Wes' comments (if he can remember them :)

spt

On 9/12/13 7:08 PM, [email-masked] wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 16 Sep 2013 14:20:44 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
>
> Better late than never?
>
[WEG] I had to go find the email, but yes, this addresses my comments, with one exception - we'd talked about sneakernet key transfers (copy to USB or CF and move the card, copy back to restore) in the hardware swap case. I don't know if you want to explicitly mention that in section 5 or not. I'd sort of prefer that to hoping that router vendors understand that etc. = sneakernet. :-)

Did another review, found a few more mostly minor things:

Section 3.1 "...can be directly transferred to the RPKI CA over the Ethernet port..." I'd be less specific here and say something like "over the network" since "the Ethernet port" is both ambiguous and overly specific. Also you probably need to say something like "assuming that the router has direct connectivity to the CA at this point in the provisioning process" -- for that matter, it might be useful for both 3.1 and 3.2 if you were explicit about what the router needs to be able to talk to both inside and outside of the provider network at this stage of the provisioning process to make sure that none of these validation and key exchange steps fail on account of not being able to talk to the right server. In other words, which of these validations are local and which require communicating with an external TA, CA, etc.?

The draft currently skips from section 3 to section 5. I might suggest that section 4 should cover key rolls (if, for example, the private key is compromised somehow, or if you simply wish to do this periodically), since you've covered provisioning a new router, and then go to scenarios where you want to swap hardware and keep the same keys. I don't think there's a lot that is different between initial provisioning and doing a key roll, but if there is anything different, it's worth highlighting, especially if there are gotchas around making sure that you don't accidentally break validation when you swap router keys (overlapping expiry, etc), and if there isn't, it's worth mentioning that the process is the same.

A few grammar nits as well, but I expect the RFC editor can handle those. :-)

> >     Filename        : draft-ietf-sidr-rtr-keying-02.txt

[WEG] Nice job in making this more accessible for those of us less familiar with PKI wrangling, this is a really helpful draft.

Wes

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.

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 Sep 2013 17:25:30 -0400

> [WEG] I had to go find the email, but yes, this addresses my comments, with one exception - we'd talked about sneakernet key transfers (copy to USB or CF and move the card, copy back to restore) in…

Luckily we all have email archives ;)  How about:

OLD:

Note that cut/copy and paste operations for keys over a certain sizes is 
error-prone.

NEW:

Note that cut/copy and paste operations over a SSH-proected CLI session 
for keys over a certain sizes is error-prone; a less error process is to 
use a USB or CF device to copy the key to and then insert the device in 
to the router.

> Section 3.1 "...can be directly transferred to the RPKI CA over the Ethernet port..." I'd be less specific here and say something like "over the network" since "the Ethernet port" is both ambiguous…

Replacing Ethernet with network no problem.

And, you're right the draft needs to say something about network 
connectivity with the entity that requests the certificate and the CA.

I made the following changes:

s3.1:

OLD:

The PKCS#10 request, which includes the public key the router wants 
certified, can be directly transferred to the RPKI CA over the network 
if the router supports protocols such as FTP and HTTP [RFC2585] using 
the application/pkcs10 media type [RFC5967] or EST (Enrollment over 
Secure Transport) [I-D.ietf-pkix-est].

NEW:

The PKCS#10 request, which includes the public key the router wants 
certified, can be directly transferred to the RPKI CA over the network 
if the router supports protocols such as FTP and HTTP [RFC2585] using 
the application/pkcs10 media type [RFC5967] or EST (Enrollment over 
Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that the 
router has direct connectivity to the CA.

OLD:

The operator off-loads the PKCS#10 and uploads the request to their RPKI 
software management tools.

NEW:

The operator off-loads the PKCS#10 and uploads the request to their RPKI 
software management tools; external network connectivity is not required 
if the operator acts as CA.

BTW - you'd still need external connectivity if the operator acts as the 
CA to publish the certificate in the RPKI.  I put some words in to that 
affect.

> The draft currently skips from section 3 to section 5. I might suggest that section 4 should cover key rolls (if, for example, the private key is compromised somehow, or if you simply wish to do th…

I'll have to give some thought to what other requirements there are for 
key rollovers.

I'll go ahead and publish a new version with a blank section 4 to make 
sure we knock out the other issues.

Thanks again for the review!

spt

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Sep 2013 14:17:53 -1000

> for keys over a certain sizes is error-prone; a less error process is to 
                                                            ^-prone
> use a USB or CF device to copy the key to and then insert the device in 

way too detailed.  you noted that pure text copy/paste is error prone.
that's enough.  do you really want to get into the 42 other ways of
doing it?  how about copy/paste of a checksummed package containing the
credential?  or xmodem?  and don't forget paper tape!  :)

> router has direct connectivity to the CA.

what's "direct?"  are you trying to say in the same pop?  on the same
lan segment?  or do you merely mean e2e over the intertubes?

> if the operator acts as CA.

external to what?  s/external/global/?

randy

---

From: "George, Wes" <[email-masked]>
Date: Wed, 18 Sep 2013 09:36:05 -0400

> credential?  or xmodem?  and don't forget paper tape!  :)

[WEG] Agree with Randy. Was more thinking about this in terms of the hardware swap scenario (section 5), rather than initial key provisioning. You say that vendors SHOULD allow the key to be offloaded and then provide examples of offload methods, but sneakernet isn't one of them. I don't think we have to tell implementers to support importing a key from a filesystem (in whatever form) but being explicit about the ability to EXPORT it to a filesystem is a different matter.

Thanks
Wes