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

"Max Pritikin (pritikin)" <pritikin@cisco.com> Thu, 13 October 2016 11:26 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3D612973F for <anima-bootstrap@ietfa.amsl.com>; Thu, 13 Oct 2016 04:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.517
X-Spam-Level:
X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR4xuKjubvcM for <anima-bootstrap@ietfa.amsl.com>; Thu, 13 Oct 2016 04:26:15 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCFF12973C for <anima-bootstrap@ietf.org>; Thu, 13 Oct 2016 04:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8126; q=dns/txt; s=iport; t=1476357975; x=1477567575; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SHS5Fbe1nntk6WdKk8x1ofmSOu52SxOctEktHQEE7mA=; b=WObcM5pA7+P1FdshSwrfwCPmZCe8W/XzQQZnXKSygNpOoYkFu/gsK4K+ F+/7moEpRrRxrMVCp2GDKzcc3wpCf0LGV3pGnc8lWqnxBnJkTKHDVffwP 2ludoJaeprXZJClSb/6lSxRqv4r+VfS8xni2EgfZIZ0U72uJkNQdJBh8k Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQAnbv9X/5ldJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR1XfAeNLZcEkiWCD4IKKYJCgzYCGoFmOBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RhAQEEASMRSg0BCBcDAiYCBDAVCAoEARKISAgOtiCNAgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGQWBB4czCIJQgU6DEIJtLIIvBZoCAYYmiVaPdZB3AR42UIJyH4F?= =?us-ascii?q?TcodkgQABAQE?=
X-IronPort-AV: E=Sophos;i="5.31,339,1473120000"; d="scan'208";a="159304622"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Oct 2016 11:26:14 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u9DBQELT012860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Oct 2016 11:26:14 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 13 Oct 2016 06:26:13 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Thu, 13 Oct 2016 06:26:13 -0500
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: authz in the form a cert chain.. from SIDR work
Thread-Index: AQHSJUSbQHgJ65sWwEi06mUUCMbO8w==
Date: Thu, 13 Oct 2016 11:26:13 +0000
Message-ID: <BFB13000-E62E-4A5F-9003-F8227F914974@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.167.92]
Content-Type: text/plain; charset="utf-8"
Content-ID: <86D9E3AB80F4334BB4307AD3D1188CAD@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/gA7rzzix_Pl1Ks9EYuwDG6hke78>
Subject: Re: [Anima-bootstrap] authz in the form a cert chain.. from SIDR work
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 11:26:17 -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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-