Subject: [Netconf] draft-ietf-netconf-zerotouch-01

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 07 Dec 2014 20:18:24 +0100

I have not been active previously in this working group and so I might
lack some context. Nevertheless, I have read through
<draft-ietf-netconf-zerotouch-01> and have a few questions.

I would like to focus my comments on the first figure in the document:

                                  fetches Configlet and
                    +----------+  boot-image, if needed
       +------------|  Device  |---------------------+
       |            +----------+                     |
       |                 ^                           |
       |                 |                           V
       | call home       | manufactures         +----------+
       |                 | with necessary       |  Config  |
       |                 | default state        |  Server  |<----+
       |                 | for ZeroTouch        +----------+     |
       |                 |                                       |
       |                 |                                       |
       |            +----------+  delegates trust                |
       |            |  Vendor  |-------------------+             |
       |            +----------+                   |             |
       |               ^    ^                      |             |
       |               |    |                      V             |
       |               |    |                 +----------+       |
       |       imports |    | validate owner  |  Config  |       |
       |         trust |    +-----------------|  Signer  |       |
       |        anchor |                      +----------+       |
       |               |                           ^             |
       |               |                           |             |
       |            +---------+  requests signing  |             |
       +----------->|   NMS   |--------------------+             |
                    +---------+                                  |
                        |                                        |
                        +----------------------------------------+
                          signed Configlet and boot-image file

1) I would like to point out that the figure uses the same style for
drawing protocol endpoints and real-world entities. Maybe that was done
on purpose; maybe not.

2) The description in the document is not clear when it comes to the
information that is pre-configured on the device.

Here are two statements from the draft:

         The device
         is preconfigured with a secure device identity, Configuration
         Servers URIs, and certificates for both Configuration Signers
         and Configuration Servers it trusts by default.

         Vendors manufacture the devices with secure device identities
         and preconfigured Configuration URIs, and Configuration Signer
         certificates.

Is a device now preconfigured with the certificates of the config signer
and the configuration server?

Figure 1 puts them in some dependency to each other so it is not clear
which certificate is actually needed. Maybe we are really talking about
trust anchors?

3) When I read "secure device identity" I wasn't quite sure what that
would actually mean till I read this sentence later in the document.

"  Devices supporting ZeroTouch MUST have a manufacturer-provisioned
   secure device identifier, as defined in [Std-802.1AR-2009].
"

Another way to put it is that the device is configured by the
manufacturer with a certificate and the corresponding private key. The
certificate has the structure defined in [Std-802.1AR-2009].

A related question concerning figure 1 would then be whether the
"vendor" is the same as the manufacturer or not.

Then you write:

"
   The IDevID includes both an X.509 certificate,
   encoding a globally unique per-device identifier, and a chain of
   X.509 certificates leading to the manufacturer's well-known trust
   anchor.
"

Is this CA hierarchy needed to support the functionality for "delegating
trust to the "config signer" as shown in Figure 1?

This sentence sounds to me like the device has
* the CA cert of the manufacturer (which is the trust anchor),
* the certificate issued to the device from some intermediate CA, and
* a certificate chain that allows path validation of the device
certificate to the manufacturer CA.

4) Internet-based Configuration Servers = NMS?

In Figure 1 you use the term "NMS" and later in the text you talk about
the Internet-based Configuration Servers or Configuration Servers. Are
these all the same entities or different entities?

Ciao
Hannes

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Dec 2014 03:01:31 +0000

Hi Hannes!

Thank you for showing interest in this draft, it's great to get your
security perspective on it.

>       +------------|  Device  |---------------------+

True, "Vendor" is not an endpoint and, while an NMS is an endpoint in
network management scenarios, the relationships drawn are more offline
activities.  You're the first to point this out, and I'm guessing you
think it odd.  Could you suggest how to improve it?   Would replacing the
'+' in the corners with something like 'o', along with a key help much?

>         and preconfigured Configuration URIs, and Configuration Signer

Good catch, these statements are almost consistent, but the 2nd paragraph
fails to mention the trust anchor certificate for the Configuration
Server.  Also, as you mention below, both would be improved if
"certificate" were expanded to "trust anchor certificate"

>which certificate is actually needed. Maybe we are really talking about

Yes, these are intended to be trust anchor certificates.   The list of
Configuration Signer trust anchor certs may contain just one entry, the
Vendor's trust anchor used to sign the Configuration Signer CSRs, but we
made it a list in case there is ever a need to have another trust-anchor.
The list of Configuration Server trust anchor certs is similar to the set
of CA certs found in browsers.

>   secure device identifier, as defined in [Std-802.1AR-2009].

Thanks, I'll move the reference up so it's defined at first use.
Actually, there is suggestion to have a Terminology section at the top,
which would've helped here as well.

>certificate has the structure defined in [Std-802.1AR-2009].

Correct.

>"vendor" is the same as the manufacturer or not.

Yes, we're using these terms interchangeably.  I think we should settle on
one, probably "Vendor".  And again, a Terminology section would help.

>trust to the "config signer" as shown in Figure 1?

No, this certificate chain is needed for when the device calls home to the
NMS.  During either the SSH or TLS transport handshake, the device will
provide these certificates to the NMS so that it can verify the device's
identity.

>certificate to the manufacturer CA.

Almost.  Strictly speaking, the device would not need the manufacturer's
trust anchor, as the NMS is expected to have previously gotten it for
themselves (the "imports trust anchor") relation in the diagram above.
This follows the common practice of sending the chain up to but not
including the trust anchor.

>these all the same entities or different entities?

Different entities, albeit it's conceivable that an NMS may incorporate
the Configuration Server role as well.  Another possible bundling would be
for the Configuration Signer to incorporate the Configuration Server role.
 Taking it another step, the Vendor might itself take on both the
Configuration Signer and Configuration Server roles, but I digress.

Great comments, we'll incorporate them in the next update!

Cheers,
Kent

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 09:40:50 +0100

Hi Kent,

thanks for the quick response.

Let me try to describe a minimalistic approach that does not cover the
case of learning something via DHCP and that does not delegate signing
authority to someone else.

A device is configured with a certificate (such as [Std-802.1AR-2009]),
the trust anchor of the manufacturer and the URL of a Configuration
Server. These are provided by the manufacturer of the device. You don't
even need to sign it since it is already on the device anyway.

This information is then enough to let this device connect to the
configuration server, use TLS to authenticate that server, and to get
whatever information it needs from there.

Then, it can use some other protocols to connect to a network management
server etc.

Is this a correct description (without the more sophisticated
functionality)?

Ciao
Hannes

---

From: Kent Watsen <[email-masked]>
Date: Fri, 19 Dec 2014 00:51:22 +0000

>A device is configured with a certificate (such as [Std-802.1AR-2009]),

Yes, all proposals have this in common

>the trust anchor of the manufacturer

What is this trust anchor used for?

> and the URL of a Configuration

This part sounds exactly like the current proposal, where the device is
able to securely connect to a list of URLs, configured at the time the
device was manufactured.  One difference that I don't see in your proposal
is a need to ensure that the device only downloads information unique to
it.   The current draft strives to ensure that only the true owner(s) of a
device can configure this information.  This is considered critical for
the security of the solution.  The question is if manufacturers can create
a lookup service, something to test if a unique identifier (e.g., serial
number) belongs to a given owner (e.g., username + password or key).  Very
difficult for many sales channels, but not difficult if customers wanting
the service must go thru a vendor-approaved sales point.

I still like the idea, from last summer, of letting physical presence
eliminate the need for a device to assert the security of the information.
 Where physical presence could be because the installer plugged a USB
flash drive into the device, near-field communication, or a link-local
address.  I know it introduces an attack vector, but it seems to me that
if a person is already able to get that level of physical presence, then
there are bigger problems to worry about.

Thanks,
Kent