Subject: [secdir] secdir review of draft-ietf-netconf-zerotouch-22

From: David Mandelberg <[email-masked]>
Date: Tue, 24 Jul 2018 19:20:14 -0400

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/

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Jul 2018 02:42:08 +0000

Hi David,

Thank you for your review!
Please find comments below.

Kent

> getting an entirely new owner certificate and revoking the old cert? Is 

No, as you say, it is not possible to revoke signed data, other than
to revoke the Owner Certificate associated with the private key that
signed it.

I wouldn't say that this was/is intentional, other than note that 
it seems consistent with assumptions made when the bootstrapping 
device obtains unsigned data from a trusted bootstrap server, in 
that the data is only protected by the bootstrap server's TLS 
certificate; the device can check that the certificate hasn't been
revoked, but that doesn't say anything about the current validity
of the data.

Do you think a Security Consideration would cover it?  Something
like:

   Zerotouch information, regardless of how obtained or how 
   trusted, does not have a validity assertion beyond the PKI
   used to authenticate it.  Zerotouch information neither
   expires nor can be revoked.  When provided by a trusted
   bootstrap server, the validity of the zerotouch information
   is implied by its availability.  However, when zerotouch 
   information is provided outside the purview of a bootstrap
   server (i.e., signed data on a removable storage device),
   its current validity is less certain.  Operators are advised
   to ensure only accurate zerotouch information is ever 
   published.  In case inaccurate zerotouch information is
   published, or otherwise deemed no longer valid, and it is
   deemed a security risk, the signing certificate SHOULD be 
   revoked and a new one created having a chain to trust 
   leading to the same 'pinned-domain-certificate' provided 
   in the Ownership Voucher for the device.  However, doing
   so, will necessarily affect the validity of any other
   previously published zerotouch information artifacts
   signed using the just-revoked certificate.  It the need
   to do this is fairly common, operators can define an
   Owner Certificate per device.

> is compromised, is there any way to securely provision a new device?

Regarding placing more trust in device manufacturers, and a 
potential Security Considerations statement, I'm trying to 
determine what statements you're looking for.  

But first, I think you mean "well-known bootstrap servers" more
so than "manufacturers".  AFAIK, the draft never says in normative
text that the well-known bootstrap servers are hosted by the 
manufacturer (though entirely possible and somewhat likely).

So maybe a couple Security Consideration statements related to:

1) the security issue that the well-known bootstrap server may have
   been compromised.  Though, it seems that this is a statement that
   any TLS-protected resource could make.

2) the privacy issue that the information provided to the well-known
   bootstrap service may be visible to others (e.g., admins of the 
   bootstrap server) if not encrypted.

Are these what you had in mind?  If not, can you please jot down a
few lines capturing what you hope to see?

Regarding "is there any way to disable zero touch, and configure a
device manually", I think that this is outside the scope of the 
document.  Some vendors may lock down a device such that it can
only activate thru the bootstrapping process, while other devices
simultaneously enable console access.

Regarding "is there any way to securely provision a new device"
when a well-known bootstrap server is known to be compromised.  My
first thought is, if it's known to be compromised, then it's also
likely patched.  But let's say the issue is more like an operator
not trusting a particular well-known bootstrap server for some
other reason, and would like to never allow devices to obtain 
bootstrapping data there...then the options are slim, an external
firewall policy blocking access to that bootstrap server may be
needed.

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

Yes, probabilistically/cryptographically unique keys per device.

> that is stale (nextUpdate < now)?

Yes, exactly, it meant to cover those cases, as well as the "stale"
case, though I admit the text doesn't exactly say it.  How about this?

  OLD
     if the revocation status is not attainable
  NEW
     if suitably-fresh revocation status is not attainable 

> well-known bootstrap servers could only provide untrusted redirects.

First, let's replace "manufacturer" with "well-known bootstrap server"
above.  But, to your main point, absolutely, any bootstrap-server could
return either redirect or onboarding information, and perhaps it is a
feature for some well-known bootstrap servers to do so.  And yes again,
the keys for an online service are potentially more easily compromised,
perhaps a Security Consideration for the use of HSMs similar to [1]
would help?  While I agree with your conclusion, it brings into question
what "trusted" means.  What about an OCSP server with its online key?
If the manufacturer no longer deems (through audits or whatever) that
a well-known bootstrap server is no longer trusted, it can revoke the
bootstrap server's certificate.  Just wondering, is this really a 
problem?  Can a Security Consideration be used to address this to 
your satisfaction?

[1] https://tools.ietf.org/html/draft-ietf-anima-voucher-07#section-7.2

> potentially a management headache.)

Yes, the initial-step in Section 5.6.  Yes, some operators may forget
(though they will learn).  The config is intended to either be applied
completely or not at all.  The second paragraph in section 5.6 says
"If the device encounters an error at any step, it MUST NOT proceed
to the next step."  Perhaps the 6th paragraph in that section could
could state that an "error" constitutes anything less than 100%?

> use a revoked cert against a device with no clock.

Okay, fair point, a live response sort of reflects "now", regardless 
what the device clock says.  That said, without an accurate clock, the
device wouldn't be able to validate the signing certificate and, if 
provided over an HTTPS transport, it wouldn't be able to validate the
server's end-entity certificate either.  In fact, certain device bad
clock values might actually block the TLS connection due to it being
outside the end-entity cert's validity period.  Ugh.  Currently the 
text says that device "implementations should assume [things]  are not 
revocable" - do you want to add a text like "but MAY check 'current'
revocation using on online CRL Distribution Point or 
OCSP server"?  

BTW, the end of this section says "Implementations SHOULD NOT rely on
NTP for time, as NTP is not a secure protocol." - any thoughts on this
statement?

Thanks again, David.

Kent

---

From: David Mandelberg <[email-masked]>
Date: Tue, 31 Jul 2018 14:14:02 -0400

> revoked, but that doesn't say anything about the current validity

I think the TLS case and the case of signed objects transmitted over 
insecure channels/mediums are different, because of TLS's replay protection.

>     server (i.e., signed data on a removable storage device),

I'd suggest adding a word to make that "a trusted bootstrap server". 
(Bootstrap servers can be untrusted, right?)

>     Owner Certificate per device.

Owner certs can be valid for years, right? My intuition (which might be 
wrong) is that it's hard enough to remember every old configuration used 
in the past few years, that operators won't really know if any of the 
old configurations should be "deemed a security risk". You probably have 
a better understanding of the operational environments this protocol 
will be used in though. If you don't think there's a significant 
operational security risk from this, then I'm happy with your text.

> manufacturer (though entirely possible and somewhat likely).

Correct, sorry for the assumption.

> few lines capturing what you hope to see?

Those are part of what I had in mind, but I'm looking for something at a 
higher level. It seems that the nature of this protocol is to shift some 
control of initial configuration away from the owner and towards the 
manufacturer (or whoever picks the list of well-known bootstrap servers) 
and/or the well-known bootstrap server operators. That's not a problem 
at all, it would just be nice to see some discussion of that shift in 
control. It would be even greater to see a discussion of how that shift 
in control matches up with a threat model.

Does that make sense? I'm not sure how much that's in scope for this 
particular document, it just seems like there's some major stuff going 
on with owners needing to trust others more in ways that they did not 
without zerotouch, so it would be good to see an explanation of the 
extent of that somewhere.

> simultaneously enable console access.

ACK. I think those have significant effects on security, but it's fine 
if it's out of scope.

> firewall policy blocking access to that bootstrap server may be

That type of remedy sounds out of scope, but to my initial point above, 
I think it might be worth saying something along the lines of "this 
system assumes that owners trust all pre-configured well-known bootstrap 
servers to configure their devices".

> Yes, probabilistically/cryptographically unique keys per device.

ACK, I have no concern here then.

>       if suitably-fresh revocation status is not attainable

Looks good.

> [1] https://tools.ietf.org/html/draft-ietf-anima-voucher-07#section-7.2

Since it's intentional that a well-known bootstrap server can return 
onboarding information, then I think this is just another part the high 
level discussion of the shift in control that I asked for above.

> could state that an "error" constitutes anything less than 100%?

Do you think it's worth adding a warning to operators somewhere to 
remind them to change the flag? Or maybe the "device SHOULD report a 
warning if the bootstrapping completes successfully but zerotouch 
bootstrapping is still enabled"?

I think it's already clear what an error in paragraph 6 is. What I found 
unclear was what to do with errors in paragraphs 6 or 7. Yes, don't go 
on to the next step, but what about: In paragraph 6, should the device 
rollback any partial config update if there's an error? In paragraph 7, 
should the device rollback all config from paragraph 6 if there's an error?

> revocation using on online CRL Distribution Point or

Good points. I'm not sure what the right answer is, so I'll defer to you 
on this.

> NTP for time, as NTP is not a secure protocol." - any thoughts on this

I know very little about the security of time synchronization, sorry.