Subject: [Netconf] zero touch update

From: Kent Watsen <[email-masked]>
Date: Sat, 15 Nov 2014 01:48:08 +0000

The ZeroTouch draft received a lot of valuable comments this week (thank you everyone).  One concern raised regards the feasibility for Vendors knowing which devices are owned by whom, especially in light of downstream channels and resellers.  The anima-bootstrapping-keyinfra resolves this by replacing proof of ownership with an audit log assertion, for post-incident forensics analysis.  This approach is easy to implement, but the security assurance it provides is fairly low (e.g., the damage could be done before the logs are reviewed).

Leveraging L2 before L3 is fine, as is leveraging L1 before L2, so long as the higher layers have equal or greater security assurances (no security downgrade attack).   That said, our use-case of needing to support gateway devices connecting to 3rd-party networks precludes the use of L2, as there is no other local device to connect to.

One idea is say that the proof-of-ownership is only required for gateway devices connecting to remotely administered networks, so as to lower the burden on Vendors mentioned above with there being far fewer of these kinds of devices.  Whittling the numbers down further, we could add optional support for NFC, so that proof-of-ownership is also not required for devices having the right hardware.

All this to say that the authors believe that this needs to be discussed more and thus we will not likely be pushing for a WGLC in December after all.

Thanks,
Kent

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Nov 2014 01:34:11 -0500

Kent, 
      in the days up to Toronto, before it was clear the amount of
      convergence that we might get, I wrote the following email.
      This is intended to be a more detailed expansion of the certificates 
      used in draft-pritikin-anima-bootstrapping-keyinfra-00.
      
      It could be that the MASA provides the certificates online, 
      at deployment time, but the goal was to provide a system which
      could be used entirely offline, and then let parts of it go online
      as desired. Easier to go this way than the other way.

draft-richardson-6tisch-idevid-cert-00 describes a RFC3779-like extension.

the email is:
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

this is what I imagine.  I will perhaps put this into an appendix.
Please remmeber that this comes from 6tisch, which anticipates deployment
into industrial settings (Oil refineries, chemical plants, etc.), and while
I've made up some semi-consumer oriented things here, we imagine something
involving industrial consortia.  I don't pretend that this is at all useful
for other scenarioes due to lack of a high-enough margin for the supply chain
to care about such things. 

(I guess the Coyote Plant should have been in New Mexico)

====

To make it easier to explain, and talk about, I'm going to give some names.
   Factory:       ACME
   National-VAR:  Cadabra
   Regional-Var:  Sesame
   Plant:         Coyote

So, the manager (Wiley) at the Coyote Plant, has just received 1000 new
(wireless) Road-Runner Detector, and plans to spread them along the highway.
The detectors are IDevID 210001 through 210999.  Each Detector has
an 802.1AR certificate pre-installed that looks like:
        Issuer: C=US, ST=New Jersey, L=Fairfield,
                O=ACME Rocket-Powered Products,
                OU=Sensor-Network-Division
        Validity
            Not Before: Feb 17 19:51:50 2010 GMT
            Not After : Dec 31 23:59:59 9999 GMT
        Subject: CN=roadrunner210001
        Data:
            Serial Number: 21:00:01
        Subject Public Key Info: ...

{this is the proof of identity certificate}

When ACME Factory's Sensor Netowrk Division ships 100 crates of sensors to
Cadabra, it issues a certificate:

        Issuer: C=US, ST=New Jersey, L=Fairfield,
                O=ACME Rocket-Powered Products,
                OU=Sensor-Network-Division
        Validity
            Not Before: Feb 17 19:51:50 2010 GMT
            Not After : Dec 31 23:59:59 9999 GMT
        Subject: C=US,ST=Washington,L=Seattle,O=Cadabra,OU=Logistics
                 RFC3779-Like-Extension: Range(210000, 219999)

When Cadabra ships cases 1-20 to Sesame, it issues a certificate:

        Issuer: C=US,ST=Washington,L=Seattle,O=Cadabra,OU=Logistics
        Validity
            Not Before: Feb 17 19:51:50 2010 GMT
            Not After : Dec 31 23:59:59 9999 GMT
        Subject: C=US, ST=Arkansus, L=Bentonville,
                O=Sesame Bix Box Retail,
                OU=Small Stuff Distribution
                RFC3779-Like-Extension: Range(210000, 211999)

When Coyote Inc buys those 10 boxes of 100 sensors, the bill of sale
includes:

        Issuer: C=US, ST=Arkansus, L=Bentonville,
                O=Sesame Bix Box Retail,
                OU=Small Stuff Distribution
        Validity
            Not Before: Feb 17 19:51:50 2010 GMT
            Not After : Dec 31 23:59:59 9999 GMT
        Subject: C=US, ST=Nevada, L=Tonopah,
                 O=Coyote Inc, OU=Supper
                 RFC3779-Like-Extension: Range(210000, 210099)
                 RFC3779-Like-Extension: Range(210200, 210299)
                 RFC3779-Like-Extension: Range(210400, 210499)
                 RFC3779-Like-Extension: Range(210600, 210699)
                 RFC3779-Like-Extension: Range(210800, 210899)
                 RFC3779-Like-Extension: Range(211000, 211099)
                 RFC3779-Like-Extension: Range(211200, 211299)
                 RFC3779-Like-Extension: Range(211600, 211699)
                 RFC3779-Like-Extension: Range(211800, 211899)
(cause, a shipper sent them every other box, the ranges are not contiguous)

The mote/sensor when it sees this certificate, can verity that it's DevID
is in the range, and therefore knows that it has found the right network.

Should Coyote find that they had too many, they can sell some of these
sensors to Sheepdog Sam Inc, by issuing a certificate:

        Issuer: C=US, ST=Nevada, L=Tonopah,
                 O=Coyote Inc, OU=Supper
        Validity
            Not Before: Feb 17 19:51:50 2010 GMT
            Not After : Dec 31 23:59:59 9999 GMT
        Subject: C=GB, ST=Scotland, L=Edinburgh,
                 O=SheepsRUs, OU=Sheepdog
                 RFC3779-Like-Extension: Range(210050, 210099)
                 RFC3779-Like-Extension: Range(211611, 211623)

of course, since Coyote actually still has a valid certificate, all parties
would be advised to use the Enrollment over Secure Transport or an API into
802.1AR, to put an operational certificate in place.    Getting back to
factory default might be impossible (WirelessHart does this, I think), or
at least, will wipe the private key associated with the new certificate from
the device.

BTW: the extension is likely about 20 bytes base, with 5 bytes per IDEVID.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Nov 2014 01:35:21 -0500

Kent Watsen <[email-masked]> wrote:
    > The ZeroTouch draft received a lot of valuable comments this week
    > (thank you everyone).  One concern raised regards the feasibility for
    > Vendors knowing which devices are owned by whom, especially in light of
    > downstream channels and resellers.  The anima-bootstrapping-keyinfra

I should have been clear that it was the mention of channels and resellers
that made me send the previous email with the RoadRunner/Coyote inspired
example.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [