Subject: [Netconf] Security Directorate early review of zerotouch draft

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

As previously mentioned, the Security Directorate submitted a review:
https://mailarchive.ietf.org/arch/msg/secdir/RNtvpWPTgB9KqRaOmYzLGEYsrHs

One of the issues regards the validity period for zerotouch information.
Currently, there's no "not-before" or "not-after" values.  The issue
is that a signed bootstrapping data may be repurposed (i.e., a replay
attack).

One "fix" is to just document it as a Security Consideration and move
on.  But I notice that the voucher draft (RFC8366) has this:

     yang-data voucher-artifact:
         +---- voucher
            +---- created-on             yang:date-and-time
            +---- expires-on?            yang:date-and-time
            ...

And thus maybe we should do the following? (the '+' lines):

     yang-data zerotouch-information:
       +-- (information-type)
          +--:(redirect-information)
          |  +-- redirect-information
+         |     +-- not-before?                  yang:date-and-time
+         |     +-- not-after?                   yang:date-and-time
          |     +-- bootstrap-server* [address]
          |        +-- address                   inet:host
          |        +-- port?                     inet:port-number
          |        +-- trust-anchor?             cms
          +--:(onboarding-information)
             +-- onboarding-information
+               +-- not-before?                  yang:date-and-time
+               +-- not-after?                   yang:date-and-time
                +-- boot-image
                |  +-- os-name?                  string
                |  +-- os-version?               string
                |  +-- download-uri*             inet:uri
                |  +-- image-verification* [hash-algorithm]
                |     +-- hash-algorithm         identityref
                |     +-- hash-value             yang:hex-string
                +-- configuration-handling?      enumeration
                +-- pre-configuration-script?    script
                +-- configuration?               binary
                +-- post-configuration-script?   script

For signed zerotouch information, this enables the lifetime of the
artifact to be bounded, without depending on the expiration of the
owner certificate.

I don't see a downside to doing this (other than the effort to make
it happen).  I've also proposed this solution in the thread with the
SecDir, so we'll also get his response as to if it resolves his issue.

Any thoughts from the WG?  If not, then I'll plan to make this change
in -23 as well.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Aug 2018 07:57:36 +0200

> +               +-- not-after?                   yang:date-and-time

For the sake of understanding: Since the proposed new leafs are all
optional, if they are not set, there is no (lower/upper) restriction?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Aug 2018 09:21:09 +0000

> For the sake of understanding: Since the proposed new leafs are all optional, if they are not set, there is no (lower/upper) restriction?

<kent> correct.  The names of these leafs match the names of fields in X.509 certs, and have similar semantics, except they’re mandatory in X.509 while optional here. 

The text would also say that the device must discard any such leafs, if found in unsigned data obtained from an untrusted server (i.e., unsigned redirect info), same as how the device is already guided to discard any set “trust-anchor” value in that case. 

/kw

---

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

Dear WG,

I forgot to respond to the following question from the SecDir:

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

Focusing on the 2nd question first, my first thought is that it seems reasonable, but my second thought is, if the device is able to perform this test, then it could also disable the flag itself (e.g., at the time it sends the "bootstrap-complete" progress report) and, if that's true, then the primary reason for why we have the "Zero Touch Device Data Model" in Appendix A goes away.  

Should devices self-disable the bootstrapping service?

The primary downside I see is that, if devices were to disable the service themselves, then it is still likely that that will be accomplished via configuration, which will thus be reflected as another "commit" in the device logs.  It's a minor thing, IMO, but maybe others feel otherwise?

Thanks,
Kent // author