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

[Kent Watsen <[e-mail]>]

Hi David,

Trimming down to just the remaining items...


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

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?



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




>>> 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.
>
> Much better, thanks!

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




Kent