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

[David Mandelberg <[e-mail]>]

On 08/14/2018 09:59 PM, Kent Watsen wrote:
> 
> 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.

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


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

Looks good!


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

Thanks!


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

Sounds good.


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