Re: [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: anima@ietfa.amsl.com
Delivered-To: anima@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/anima/xikl_ieWOtcUF4GtM3ezumgrres
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: [Anima] zero touch update
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-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 =-