Subject: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi

From: Warren Kumari <[email-masked]>
Date: Thu, 14 Feb 2019 09:48:29 -0500

Hi all,

So, I'd like to discuss this document:
https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 (I've had it
kicking around since 2016, but haven't had time to push it).

It is a very simple addition to the "normal" netboot process which many
devices do, which allows "secure" installing of devices in places like
exchange points, where you don't necessarily have full physical security.
It is optimized for simplicity / ease of implementation in specific use
cases, instead of being the all-singing-all-dancing-wizz-bang solution to
everything. I'm using the Cisco autoboot-type functionality as an example,
because it is the one which many people are familiar with[0], but it
applies to basically all network device bootstrapping.

At the 50'000ft level:
It would be nice to be able to install devices in POPs, etc without having
to:
a: ship a person to configure the device
b: leave an "open" Ethernet port where anyone with a laptop can plugin, get
an IP and download device configs
c: mail a USB drive with a proto-config or
d: ship devices pre-configured from the vendor.

This document provides a simple modification to the netboot / autoboot
process which many vendors implement -- when a device is manufactured, and
the serial number is programmed, it also gets a key-pair placed on it (this
already happen for many manufacturers, some in TPM, some not). The vendor
will now also publish the *public* part on a keyserver, indexed by serial
number.

When I buy a device and get it drop-shipped to the POP, the vendor (VAR,
reseller) says "Thanks, here is the invoice, and the Serial Number is
SN17345". While the device is in transit, I go fetch
https://vendor.example.com/keys/SN17345.pem. I then encrypt the new
device's config file with the key in that cert.

When the device actually arrives at the POP, smart-hands unpacks it, racks
and stacks it, and plugs it into the circuit which I've installed already
had installed. The device does it's regular netboot - this is usually
something like "get IP via DHCP, use DHCP option 66, 67, 150 to find the
config server, download and install the named config". What this document
add is: "If the config file is completely unparsable, use your private key
to try decrypt it. If it is now readable, install and continue". Once the
device boots and connects to the network you can delete the device keys,
regenerate them, $whatever (personally I'd likely leave them so I can reuse
this function in the future, but your choice).

This is specifically designed to solve the common problem of: I'd like to
be able to use netboot to install in a POP / IXP / PE location, where I can
install a circuit, and provide DHCP, but where I don't want random
smart-hands / customer to be able to plugin to the circuit and download my
config files with my TACACS secret, SSH keys, $whatever (inquisitive
customers can plugin, and can download files, but they will be encrypted
and of no use to them).

Common questions / answers:
1: Yes, this doesn't provide perfect security - a malicious customer /
installer could install malicious firmware on the router before plugging it
in, and / or could extract the private keys from the router flash, etc --
but this is basically always true once you ship a device to a location
where you don't have physical control.

2: Yes, this isn't full "Internet" auto-install - you have to have a
circuit on your network already installed - but you are likely to already
have this, otherwise why are you installing the router? :-) It isn't
intended to replace full autonomous networking, etc - 'tis designed to be
dead simple and easy.

3: Yes, many vendors already sell a wizbang solution / appliance to do
$magic - but this requires many more things to manage, is often expensive,
and requires complex integration.

4: Yes, you *could* instead have a "base config" which the device loads,
and then you SSH in, somehow ensure that it is the "right" device and put
the rest of your config on... and you (probably) should - this provides an
additional layer of protection for the base config.

5: Yes, this doesn't solve world hunger. Never said it does.

Thoughts, comments? (please keep in mind the use-cases when commenting -
again, it isn't intending to replace the next sexy thing, just be a simple
addition to existing, deployed and used functionality).
W

[0]: Mentioning this so people don't see TFTP and assume that is the only
option.

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Feb 2019 18:59:59 +0000

Hi Warren,

Have you looked at https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch? <https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch?>

Currently in RFC Editor queue.

Kent

> On Feb 14, 2019, at 9:48 AM, Warren Kumari <[email-masked]> wrote:
> 
> Hi all,
> 
> So, I'd like to discuss this document: https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 <https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03> (I've had it kicking around since 2016, but haven't had time to push it).
> 
> It is a very simple addition to the "normal" netboot process which many devices do, which allows "secure" installing of devices in places like exchange points, where you don't necessarily have full physical security. It is optimized for simplicity / ease of implementation in specific use cases, instead of being the all-singing-all-dancing-wizz-bang solution to everything. I'm using the Cisco autoboot-type functionality as an example, because it is the one which many people are familiar with[0], but it applies to basically all network device bootstrapping. 
> 
> 
> At the 50'000ft level:
> It would be nice to be able to install devices in POPs, etc without having to:
> b: leave an "open" Ethernet port where anyone with a laptop can plugin, get an IP and download device configs
> This document provides a simple modification to the netboot / autoboot process which many vendors implement -- when a device is manufactured, and the serial number is programmed, it also gets a key-pair placed on it (this already happen for many manufacturers, some in TPM, some not). The vendor will now also publish the *public* part on a keyserver, indexed by serial number.
> 
> When I buy a device and get it drop-shipped to the POP, the vendor (VAR, reseller) says "Thanks, here is the invoice, and the Serial Number is SN17345". While the device is in transit, I go fetch https://vendor.example.com/keys/SN17345.pem <https://vendor.example.com/keys/SN17345.pem>. I then encrypt the new device's config file with the key in that cert.
> 
> When the device actually arrives at the POP, smart-hands unpacks it, racks and stacks it, and plugs it into the circuit which I've installed already had installed. The device does it's regular netboot - this is usually something like "get IP via DHCP, use DHCP option 66, 67, 150 to find the config server, download and install the named config". What this document add is: "If the config file is completely unparsable, use your private key to try decrypt it. If it is now readable, install and continue". Once the device boots and connects to the network you can delete the device keys, regenerate them, $whatever (personally I'd likely leave them so I can reuse this function in the future, but your choice).
> 
> 
> 
> This is specifically designed to solve the common problem of: I'd like to be able to use netboot to install in a POP / IXP / PE location, where I can install a circuit, and provide DHCP, but where I don't want random smart-hands / customer to be able to plugin to the circuit and download my config files with my TACACS secret, SSH keys, $whatever (inquisitive customers can plugin, and can download files, but they will be encrypted and of no use to them).
> 
> 1: Yes, this doesn't provide perfect security - a malicious customer / installer could install malicious firmware on the router before plugging it in, and / or could extract the private keys from the router flash, etc -- but this is basically always true once you ship a device to a location where you don't have physical control. 
> 
> 2: Yes, this isn't full "Internet" auto-install - you have to have a circuit on your network already installed - but you are likely to already have this, otherwise why are you installing the router? :-) It isn't intended to replace full autonomous networking, etc - 'tis designed to be dead simple and easy. 
> 
> 3: Yes, many vendors already sell a wizbang solution / appliance to do $magic - but this requires many more things to manage, is often expensive, and requires complex integration.
> 
> 4: Yes, you *could* instead have a "base config" which the device loads, and then you SSH in, somehow ensure that it is the "right" device and put the rest of your config on... and you (probably) should - this provides an additional layer of protection for the base config. 
> 
> Thoughts, comments? (please keep in mind the use-cases when commenting - again, it isn't intending to replace the next sexy thing, just be a simple addition to existing, deployed and used functionality).
> W 
> 
> [0]: Mentioning this so people don't see TFTP and assume that is the only option.
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Feb 2019 12:08:35 -0500

Warren Kumari <[email-masked]> wrote:
    > https://tools.ietf.org/html/draft-wkumari-opsawg-sdi-03 (I've had it kicking
    > around since 2016, but haven't had time to push it).

Sure sounds like ANIMA ACP and BRSKI to me.

    > will now also publish the *public* part on a keyserver, indexed by serial

Yes, it's called an IDevID from 802.1AR.

    > https://vendor.example.com/keys/SN17345.pem. I then encrypt the new device's
    > config file with the key in that cert.

We call that a voucher, RFC8366.
We don't include the entire config file in BRSKI, but in netmod zero-touch,
it basically does:

    > and stacks it, and plugs it into the circuit which I've installed already had
    > installed. The device does it's regular netboot - this is usually something
    > like "get IP via DHCP, use DHCP option 66, 67, 150 to find the config server,
    > download and install the named config". What this document add is: "If the
    > config file is completely unparsable, use your private key to try decrypt it.
    > If it is now readable, install and continue". Once the device boots and

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 15 Feb 2019 17:54:57 +0000

We proposed a similar approach (and called it, surprisingly, "zero-touch provisioning") back in 2004-2005. ;-)

I don't recall if Intel patented it, but in any case it would've likely expired by whenever this is going to be deployed.

I think the approach has merits (though I might be biased in its favor, having conceived something like that back when :).
— 
Regards,
Uri

On 2/15/19, 12:47 PM, "OPSAWG on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote: