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

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Balazs Lengyel [mailto:[e-mail]]
> Sent: 17 June 2014 10:18
> To: Michael Behringer (mbehring); Brian E Carpenter; [e-mail]
> Cc: 6tisch-security
> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap
> analysis]
> 
> When speaking about bootstraping, does this have much in common with
> the
> http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01
> draft?
> regards balazs

In a nutshell: 
draft-kwatsen-netconf-zerotouch-01 expects the config server URIs to be pre-provisioned. (If I understand it correctly, from section 4.1 - didn't read the whole doc, so correct me if I'm wrong). 
draft-pritikin-bootstrapping-keyinfrastructures does not require any pre-provisioning. The new device "learns" to which network it belongs, and will find the servers through discovery. 

Michael

> On 2014-06-17 08:59, Michael Behringer (mbehring) wrote:
> >> -----Original Message-----
> >> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
> >> Carpenter
> >> Sent: 17 June 2014 01:01
> >> To: [e-mail]
> >> Cc: 6tisch-security
> >> Subject: [Anima] Scope question [was: autonomic bootstrap: gap
> >> analysis]
> >>
> >> Michael's message is very interesting. For present purposes, i.e.
> >> getting ready for the UCAN BOF, do we need to add some points to the
> >> relevant use case draft
> >> (http://tools.ietf.org/html/draft-behringer-autonomic-
> >> bootstrap)?
> >>
> >> More generally - I think the AN protagonists have been thinking of
> >> the scope of AN being carrier, enterprise, and home networks.
> >> Should we add IoT to the scope? I think it's an important question,
> >> because it would put new meanings on "simple" and "available
> >> resources". It seems obvious that IoT networks need to be completely
> >> autonomic, but is it the
> >> *same* autonomic?
> > Brian, we have always positioned AN also in the IoT context, and I agree
> with Sheng, AN can be used everywhere. Especially when it comes to
> devices that will be deployed and managed in the thousands or even
> millions, autonomic concepts are a requirement, not a nice to have.
> >
> > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a
> high-level solution in 6tisch. It explains how you CAN bootstrap a network,
> zero-touch AND secure, and fits perfectly to the 6tisch requirements. The
> corresponding use case is described in draft-behringer-autonomic-
> bootstrap.
> >
> > To me, the bootstrap problem is one of the real solid examples of
> autonomic behaviour, because to bootstrap a device into a network I MUST
> have some functionality on the devices, ie, distribution is absolutely
> mandatory here.
> >
> > So this is one of the criteria for the use cases: Is distribution a
> requirement? Because if it is, then this points very clearly to an autonomic
> solution.
> >
> > Michael
> >
> >
> >> Regards
> >>     Brian
> >>
> >> On 17/06/2014 08:13, Michael Richardson 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 <[e-mail]>, Sandelman Software
> >> Works
> >>> -= IPv6 IoT consulting =-
> >>>
> >> _______________________________________________
> >> Anima mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> 
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Tel: [phone]
> Mobile: [phone]              email: [e-mail]