Re: [Netconf] [Anima] zero touch update
Michael Richardson <mcr+ietf@sandelman.ca> Sun, 16 November 2014 06:34 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423851A89A5; Sat, 15 Nov 2014 22:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.305
X-Spam-Level: ****
X-Spam-Status: No, score=4.305 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no
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 tM9_rGoOWyig; Sat, 15 Nov 2014 22:34:13 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3EC1A898A; Sat, 15 Nov 2014 22:34:12 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4732920012; Sun, 16 Nov 2014 01:36:31 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 71388637F5; Sun, 16 Nov 2014 01:34:11 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 55D0C637EA; Sun, 16 Nov 2014 01:34:11 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kent Watsen <kwatsen@juniper.net>
In-Reply-To: <D08BD4A5.8908A%kwatsen@juniper.net>
References: <D08BD4A5.8908A%kwatsen@juniper.net>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 16 Nov 2014 01:34:11 -0500
Message-ID: <4260.1416119651@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/t-rKAxcG5VlZOVusXWEqXAtggyQ
X-Mailman-Approved-At: Sat, 15 Nov 2014 23:24:30 -0800
Cc: Russ Mundy <mundy@tislabs.com>, Wes Hardaker <wes.hardaker@parsons.com>, Sean Turner <turners@ieca.com>, "netconf@ietf.org" <netconf@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Netconf] [Anima] zero touch update
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Nov 2014 06:34:15 -0000
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 <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Netconf] zero touch update Kent Watsen
- Re: [Netconf] [Anima] zero touch update Michael Richardson
- Re: [Netconf] [Anima] zero touch update Michael Richardson