Subject: Re: [Anima-bootstrap] authz in the form a cert chain.. from SIDR work

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 13 Oct 2016 11:26:13 +0000

Because this came up in discussion during the meeting today I’m responding to this older message originally from Michael Richardson:
https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

My concern about this approach parallels my concern about the current netconf approach, only more so. If I understand this correctly it requires each level of the sales channel to have sufficient digitization to build the bill-of-sale chain and issue that to each reseller — right up the final owner.

Original message quoted here: 
> In my original 802.1AR enabled device claim idea, I imagine a certificate
> chain rooted in the Factory CA that would already be present in the mote.
> 
> 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 Plan, has just received 1000 new
> (wireless) Road-Runner Detector, and plans to spread them along the highway.

Poorly Wiley is the customer. He’s running a “Plant”. beep beep!

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

So the first level of sales chain integration is the issuance of a certificate for the first VAR. 

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

And each member of the sales channel repeats this process as it resales the device?
Right down to the “Sesame Bix Box Retail” having a PKI and issuing the final bill of sale:

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

So basically along with each device we have a “virtual” copy of the device (a digital bill of sale) that travels (virtually) along the sales channel and to the final customer. The final customer then pairs this virtual bill-of-sale chain to the device to prove it has ownership? 

And then you use this to kick off your normal enrollment by the customer. So there has to be some binding between the final bill of sale and the CA the device is enrolling in?

- max

> 
> 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: Carsten Bormann <[email-masked]>
Date: Thu, 13 Oct 2016 13:49:09 +0200

> Right down to the “Sesame Bix Box Retail” having a PKI and issuing the final bill of sale:

Actually, for some organizations investing in designing security
solutions that's the point:
Security solutions can be designed to favor certain business
arrangements and make others artificially hard.

(In this, case, of course the manufacturer would build a platform to
enable Sesame to run this process.  Manufacturer is happy: more control
over the channel.  This also probably easily justifies the entire
expense of running the platform.  And then later, that platform can be
turned into a "profit center", because security ensures lock-in.)

Grüße, Carsten