Subject: [Anima-bootstrap] notes from 2015-09-16 design team call, and details for 2016-09-23 call

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2015 21:59:37 -0400

2015-09-16 meeting notes
present: mcr, max, Michael Behringer, Kent Watsen, Robert Craigie

some homework: http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf
  (discussion for another time)

schedule for future meetings
  1. 2015-09-23
  1. 2015-09-30
  1. 2015-10-07
  1. 2015-10-14
  1. 2015-10-21
  1. 2015-11-01 is IETF94 week, should plan a lunch.

Call in details for tomorrow:
     https://cisco.webex.com/ciscosales/j.php?MTID=ma5a7178d02a2edcb0c6d7b43e5315f08
     Meeting number: 200 557 721
     Meeting password: boot
     10am EDT
     dialin at: 18664329903

We created an agenda
  1. ACP bootstrap, combined vs separate: whether IKEv2/ACP initiates bootstrap, or if discovery causes bootstrap.
  2. what other sections of the documents can we move forward on
	1. is it always going to EAP-TLS over SOMETHING to get to EST, or are
          other EAP methods useable?
        2. what about non-EAP methods?  how do they get to EST?
	   * connects to saag story in 3.1.
	3. IETF94 - coral some of the saag conversation?
	   * Kent will speak about server keychain model at saag (from
             netconf: draft-ietf-netconf-server-model-07 )

Exec Summary: we spent most of the time talking about we can/want to do
     EAP-in-IKEv2 to do bootstrap, and this fundamentally went back to
     questions about whether or not bootstrap is per-interface or
     per-machine, and if there are use cases where we can create an ACP
     with only the IDevID identities.

     A strong desire was expressed to be able to something with no PKI,
     and public key pinning (in particular, given that we have an ACP to
     existing machines, and updating configurations to include new pins is
     not a big hurdle anymore).

     The conclusion was that once bootstrapped, machines never do it again,
     and further that it was acceptable that a machine could not be moved to
     a new location (where it would need to bootstrap again) in a zero-touch
     fashion: it would have to be reset in some sophisticated way.

on 2015-09-23 we will continue with question 2 above.

Some raw notes from the ACP bootstrap discussion

* should devices bootstrap the device, or the interface? (e.g. is the domain
	* identity paired to a device or an interface?)
* Do we want to use the IDevID only for bootstrap, or also for general networking?
* IDevID is *always* there? 802.1ar mentions that IDevID can be disabled, but
	* not deleted? Normally in a write-once memory.

* Max: Concern about changing iDev to LDev and then bootstrapping based on LDev.
   * Device should do (successfully) bootstrap only once; once bootstrap'ed,
   * it should never perform that operation again unless factory reset.

* Consensus: IDevID is RECOMMENDED only used for bootstrap, and not for ACP formation.
	* action item: Max to update doc with this assertion (e.g. as a "SHOULD")
	* update 'security considerations' to explain that this is so the
	  [compromised] vendor can't compromise the customer network [explain
	  the threat]

	* Kent points out that deploying an LDevID requires creation of a
          PKI; continuing to use the IDevID may be better. (e.g. argues for
          "should" in combination with with  some form of "pinning" if you do
          not, or leveraging TPM type hardware as discussed. but declare that
          all out of scope for now)

	* we agree with the value of IDevID via pinning or manual key
	  distribution or [whatever] but all agree it is not a necessary
	  method in the bootstrapping document

        * Consensus: !!ACP formation trusts the LDevID only!!
          !!ACP formation MUST include authorization checks against either
          (pinned?) IDevID or LDevID!!

Max restates in TCG words:
    the LDevID would be signed by the TPM module's EK certificate's private
    key, so the chain would be either:
         platform-vendor->IDevID->LDevID
    or would be
         TPM-vendor->TPMEKKEY->LDevID.

But, consensus is that rather than creating a locally signed LDevID, we would
permit use of IDevID (with security considerations).

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-