Last Call Review of draft-ietf-netconf-zerotouch-22
review-ietf-netconf-zerotouch-22-secdir-lc-mandelberg-2018-08-02-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Almost ready.

Is there any protection against old signed Zero Touch Information? I see 
that Ownership Vouchers and Owner Certificates both have mechanisms for 
expiration (and for certs, revocation), but I don't see anything 
comparable for redirect or onboarding information. If an owner creates a 
valid redirect or onboarding object and discovers a bug in it, is there 
any way for the owner to make that object no-longer-valid without 
getting an entirely new owner certificate and revoking the old cert? Is 
that intentional?

It seems like this protocol places more trust in device manufacturers 
than was previously required, but I don't see any discussion of that in 
the security considerations. If necessary, is there any way to disable 
zero touch, and configure a device manually? E.g., if the supply chain 
is presumed-secure, but the manufacturer's well-known bootstrap server 
is compromised, is there any way to securely provision a new device?

Section 3.4 mentions a device identify certificate. I assume the public 
keys in those certificates are unique per-device? If not, I want to 
think a bit more about possible attacks where the attacker correlates 
encrypted artifacts without being able to decrypt them.

Section 5.4 says what to do "if the revocation status is not 
attainable". What does that mean precisely? E.g., I assume failure to 
download a CRL, absence of a CRL in the CMS data, and failure to contact 
an OCSP server all count. But what if the device acquires a valid CRL 
that is stale (nextUpdate < now)?

If I'm understanding correctly, the intent of well-known bootstrap 
servers is that the manufacturer can redirect devices to customer 
bootstrap servers that have the actual onboarding information. But I 
also don't see any reason that a (potentially compromised) trusted 
manufacturer's bootstrap server couldn't provide the onboarding 
information directly. It's probably easier to secure the (potentially 
offline) private keys used to sign ownership vouchers than it is to 
secure the (presumably highly available, online) well-known bootstrap 
servers. So it seems like the system as a whole could be more secure if 
well-known bootstrap servers could only provide untrusted redirects.

I don't understand the error cases around the "flag to enable zerotouch 
bootstrapping" in section 5.1. How exactly is that flag set to false? Is 
it by the initial configuration step in section 5.6? If that's where the 
flag is set to false, won't some owners forget to include that in their 
config? Also, how atomic is the application of initial configuration? Is 
there any possible case in which some of the initial configuration can 
be applied without touching the flag, so that the device appears to be 
correctly configured, but will try to bootstrap again on the next 
reboot? Conversely, can the flag be set to false without the device 
being fully configured? (I don't think that's a security issue, just 
potentially a management headache.)

Section 9.4 says to assume owner certificates "are not revokable" if 
there's no accurate clock. Is there no value in checking for a CRL or 
OCSP response, even without the ability to determine if it's recent? It 
seems to me that checking with an active server (CRL Distribution Point 
or OCSP server, as opposed to a stapled CRL or OCSP response) would make 
it significantly harder (not infeasible, just harder) for an attacker to 
use a revoked cert against a device with no clock.

-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/