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

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Aug 2018 00:23:26 +0000

Hi David,

Sorry for the delay.  I've been busy with work and travel.

I'm keeping the entire history for posterity, but please
trim down to remaining points if you like.

Thanks,
Kent

>>> 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?
>> 
>> 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.
>
> I think the TLS case and the case of signed objects transmitted
> over insecure channels/mediums are different, because of TLS's 
> replay protection.
>
>
>> 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),
>
> I'd suggest adding a word to make that "a trusted bootstrap server". 
> (Bootstrap servers can be untrusted, right?)
>
>>     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.
>
> 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.

Yes, owner certs could be valid for years, though, in practice, I 
optimistically imagine that they'd be refreshed annually.

I was writing the Security Considerations for this when it seemed
that the better thing to do here is to instead add "not-before" and
"not-after" leafs to the zerotouch information artifact.  The draft
would then explain that devices MUST ensure the current time is in
between.

Would such an addition resolve this issue for you?

>>> 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?
>> 
>> 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).
>
> Correct, sorry for the assumption.
>
>> 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?
>
> 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.

Is this what you had in mind?

   9.9.  Increased Reliance on Manufacturers

   The zero touch bootstrapping protocol presented in this document
   shifts some control of initial configuration away from the rightful
   owner of the device and towards the manufacturer and its delegates.

   The manufacturer maintains the list of well-known bootstrap servers
   its devices will trust.  By design, if no bootstrapping data is found
   via other methods first, the device will try to reach out to the
   well-known bootstrap servers.  There is no mechanism to prevent this
   from occurring other than by using an external firewall to block such
   connections.  Concerns related to trusted bootstrap servers are
   discussed in Section 9.10.

   Similarly, the manufacturer maintains the list of voucher signing
   authorities its devices will trust.  The voucher signing authorities
   issue the vouchers that enable a device to trust an owner's domain
   certificate.  It is vital that manufacturers ensure the integrity of
   these voucher signing authorities, so as to avoid incorrect
   assignments.
 
   Operators should be aware that this system assumes that they trust
   all the pre-configured bootstrap servers and voucher signing 
   authorities designated by the manufacturers.

   9.10.  Concerns with Trusted Bootstrap Servers

   Trusted bootstrap servers, whether well-known or discovered, have the
   potential cause problems, such as the following.

   o  A trusted bootstrap server that has been compromised may be
      modified to return unsigned data of any sort.  For instance, a
      bootstrap server that is only supposed to return redirect
      information might be modified to return onboarding information.
      Similarly, a bootstrap server that is only supposed to return
      signed data, may be modified to return unsigned data.  In both
      cases, the device will accept the response, unaware that it wasn't
      suppose to be any different.  It is RECOMMENDED that maintainers
      of trusted bootstrap servers ensure that their systems are not
      easily compromised and, it case of compromise, have mechanisms in
      place to detect and remediate the compromise as expediently as
      possible.

   o  A trusted bootstrap server hosting either unsigned or signed but
      not encrypted data may disclose information to unwanted parties
      (e.g., an administrator of the bootstrap server).  This is a
      privacy issue only, but could reveal information that might be
      used in a subsequent attack.  Disclosure of redirect information
      has limited exposure (it is just a list of bootstrap servers),
      whereas disclosure of onboarding information could be highly
      revealing (e.g., network topology, firewall policies, etc.).  It
      is RECOMMENDED that operators encrypt the bootstrapping data when
      its contents are considered sensitive.

>> 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.
>
> ACK. I think those have significant effects on security, but it's fine 
> if it's out of scope.
>
>
>> 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.
>
> 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".

Done, factored into the text above.

>>> 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.
>
> ACK, I have no concern here then.
>
>
>>> 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)?
>> 
>> 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 unattainable
>>    NEW
>>       if suitably-fresh revocation status is unattainable
>
>Looks good.
>
>
>>> 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.
>> 
>> 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
>
> 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.

I believe that this is addressed in text above (s9.10), good?

>>> 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.)
>> 
>> 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%?
>
> 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?

This very same issue was raised to me separately and my response has been
to essentially rewrite section 5.6 to be crystal clear on how errors are
handled, especially with regard to state retained.  Please see attached
for a preview of -23.

>>> 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.
>> 
>> 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"?
>
> Good points. I'm not sure what the right answer is, so I'll defer
> to you on this.

I think the current text is good.  Anymore and we risk messing something
up.

>> 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?
>
> I know very little about the security of time synchronization, sorry.

Okay.

/kw

---

From: David Mandelberg <[email-masked]>
Date: Sun, 12 Aug 2018 16:09:53 -0400

> Sorry for the delay.  I've been busy with work and travel.

No worries.

> Would such an addition resolve this issue for you?

Yes, that would work. It probably makes sense to say something in the 
security considerations about keeping those validity intervals short.

If you prefer to leave the data formats and implementations unchanged, 
you could also consider using per-CMS EE certificates, like the RPKI 
does: https://tools.ietf.org/html/rfc6480#section-2.3. (I haven't 
thought about how compatible that method is with zerotouch, I'm just 
mentioning it as an alternative in case it happens to be easier for you.)

> Is this what you had in mind?

Yes, thank you!

Looks good.

> handled, especially with regard to state retained.  Please see attached

Much better, thanks!

-- 
https://david.mandelberg.org/

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 Aug 2018 01:59:10 +0000

Hi David,

Trimming down to just the remaining items...

> Yes, that would work. It probably makes sense to say something in
> the security considerations about keeping those validity intervals
> short.
>

Ah, this is an interesting idea.  Actually, I'd say that there is a
near 1-1 correspondence between EE certificates and what this draft
is calling the owner cert.  Section 3.2 says about owner certs:

   The owner certificate CMS structure MUST contain the owner
   certificate itself, as well as all intermediate certificates leading
   to the 'pinned-domain-cert' certificate specified in the ownership
   voucher.  The owner certificate artifact MAY optionally include the
   'pinned-domain-cert' as well.

While we conceptually think of the owner certificate as a singleton,
there is nothing in the draft that prevents a unique owner certificate
per device, which would allow for per-device validity and revocation to
be supported.

This being the case, I think that the following Security Consideration
section should be added:

   9.11.  Validity Period for Zero Touch Information

   Zero touch information does not specify a validity period.  For
   instance, neither redirect information nor onboarding information
   enable "not-before" or "not-after" values to be specified, and
   neither artifact alone can be revoked.

   For unsigned data provided by an untrusted source of bootstrapping
   data, it is not meaningful to discuss its validity period when the
   information itself has no authenticity and may have come from
   anywhere.

   For unsigned data provided by a trusted source of bootstrapping data,
   the availability of the data is the only measure of it being current.
   Since the untrusted data comes from a trusted source, its current
   availability is meaningful.

   For signed data, whether provided by an untrusted or trusted source
   of bootstrapping data, the validity is constrained by the validity of
   the both the ownership voucher and owner certificate used to
   authenticate it.

   The ownership voucher's validity is primarily constrained by the
   ownership voucher's "created-on" and "expires-on" nodes.  While
   [RFC8366] recommends short-lived vouchers (see Section 6.1), the
   "expires-on" node may be set to any point in the future, or omitted
   altogether to indicate that the voucher never expires.  The ownership
   voucher's validity is secondarily constrained by the manufacturer's
   PKI used to sign the voucher; whilst an ownership voucher cannot be
   revoked directly, the PKI used to sign it may be.

   The owner certificate's validity is primarily constrained by the
   X.509's validity field, the "notBefore" and "notAfter" values, as
   specified by the certificate authority that signed it.  The owner
   certificate's validity is secondarily constrained by the validity of
   the PKI used to sign the voucher.  Owner certificates may be revoked
   directly.

   For owners that wish to have maximum flexibility in their ability to
   specify and constrain the validity of signed data, it is RECOMMENDED
   that a unique owner certificate is created for each signed artifact.
   Not only does this enable a validity period to be specified, for each
   artifact, but it also enables to the validity of each artifact to be
   revoke.

What do you think?

>> bootstrapping is still enabled"?

I forgot to respond to this comment of your before.  To address this
comment, I added the following:

   If the onboarding information was obtained from a trusted bootstrap
   server, and the result of the bootstrapping process did not disable
   the "flag to enable zerotouch bootstrapping" described in
   Section 5.1, the device SHOULD send an "bootstrap-warning" progress
   report.

>> handled, especially with regard to state retained.  Please see attached

FIW, this text is going thru a WG churn, but the essence of what I attached
before is being retained.

Kent

---

From: David Mandelberg <[email-masked]>
Date: Fri, 17 Aug 2018 20:19:18 -0400

>     availability is meaningful.

(nit) The only trusted sources of bootstrapping data are TLS servers, 
right? I think this paragraph would be a bit stronger if you explicitly 
mentioned that TLS's integrity guarantee and replay protection are what 
you're relying on here.

>     artifact, but it also enables to the validity of each artifact to be

Looks good!

>     Section 5.1, the device SHOULD send an "bootstrap-warning" progress

Thanks!

> before is being retained.

Sounds good.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Aug 2018 14:41:09 +0000

Hi David,

Resolving the remaining nit.

> mentioned that TLS's integrity guarantee and replay protection are what 

Now the paragraph says:

   For unsigned data provided by a trusted source of bootstrapping data
   (i.e., a bootstrap server), the availability of the data is the only
   measure of it being current.  Since the untrusted data comes from a
   trusted source, its current availability is meaningful and, since
   bootstrap servers use TLS, the contents of the exchange cannot be
   modified or replayed.

Okay?

Thanks for all the great suggestions!

Kent

---

From: David Mandelberg <[email-masked]>
Date: Sat, 25 Aug 2018 18:22:15 -0400

Hi,

Sorry for the late reply, I've been busy with the new job I just started at.

Looks good.