Re: [6tisch-security] [Anima] autonomic bootstrap: gap analysis

Hi Michael,

I had a draft on this for quite longtime, the link is:

http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping-00

you forgot to mention this one?

Behcet

On Mon, Jun 16, 2014 at 3:13 PM, Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
> I recognize that bootstrap is only one of the autonomic mechanisms that
> are relevant to this group.  I have much reading on the other aspects
> which I hope to get done.
>
> The 6tisch security design team has been working on a "zero-touch" mechanism
> that would permit constrained devices to join a Lowpower/Loss Network (LLN)
> in a secure way.   We have considered adapting EAP-TLS (as ZigbeeIP has
> done), or turning the WirelessHART (IEC62591) packet flow into something more
> IPv6-like.  While there are significant bits of design space to explore
> while trying to optimize packet count, size and total energy risk of the
> join protocol;  the idea that there should be a set of authorization tokens
> From the device vendor which would permit the network and new nodes to
> recognize each other has been central to all discussions.
>
> while draft-pritikin-bootstrapping-keyinfrastructures and
>       draft-behringer-autonomic-bootstrap-00
>
> have proposed valid high level concepts, I believe that specification of the
> authz token is critical for the IoT space.  A great concern that is that the
> LLNs created remain operational for decades at a time, and that the
> components can individually and also in aggregate be both (re-)sold,
> and/or the service provider operating the network be replaced.
>
> (There are real life examples where a part of a 100 square mile refinery
> is actually sold to a competitor; obviously it doesn't get moved.  On the
> other side, one has the very real risk that you bought your sensor network
> From a "Nortel")
>
> I was pointed at 802.1AR's device ID mechanism.  Really, 802.1AR is about an
> API between a (constrained) device and it's cryptographic hardware
> module/TPM.   It profiles a number of IETF PKIX specifications in a useful
> way, but there is little there in terms of actual protocol.  When it comes to
> what does an *DevID look like, in it's section 7.2.8, saying that the DN
> should contain a "serialNumber" attribute:
>
>    The formatting of this field shall contain a unique X.500
>    Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer
>    or any other suitable unique DN value that the issuer prefers.
>
> What I have observed is that there needs to be a way to clearly delegate from
> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to
> SERVICE-PROVIDER.    It would significantly reduce the number of certificates
> in (non-constrained device) databases for some levels of this hierarchy if
> the IDevID were aggregateable in some fashion.  RFC3779 came to mind, which
> deals with delegation of Autonomous Systems Numbers (ASN) and IP address
> ranges from RIRs to LIRs to ISPs and Enterprises.
>           RFC3779: X.509 Extensions for IP Addresses and AS Identifiers
>
> I created:
>     X509.v3 certificate extension for authorization of device ownership
>                  draft-richardson-6tisch-idevid-cert-00
>
> which cribbed together via nroff2xml and a search and replace.
>
> The Pritikin and Behringer documents seem to assume that the ultimate goal of
> the trusted enrollment process is to create a path in which "EST"= Enrollment
> over Secure Transport could operate that would permit a new locally
> significant certificate to be loaded into the new device.
> I agree with that goal.
>
> There is the question of how that trust circuit is created, and in discussion
> it seemed that it involve some kind of leap-of-faith TLS setup which would be
> authenticated by the "authz" tokens later on.  I disagree; I think that with
> appropriate evaluation of path constraints that the authentication can occur
> within the TLS protocol. (Even easier if done in IKEv2)
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>