Subject: [Anima] some small summary of bootstrap conversation

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2015 12:56:41 -0400

The bootstrap design team is still bootstrapping, but Max, Toerless and I
have had three 1hr phone conferences (May 29 meeting cancelled). They have
been Friday at 1700UTC, but are now Thursday at 1400UTC, and will occur
June 11 as well.  A doodle poll to confirm a regular time will go out next
week once the list of parties has been identified.
I think that the AD still has to approve things.

We started with a discussion of the charter for the DT, and how it relates to
the charter for the WG, and the result is at:
    https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap

the places where it says "OWN" means, it's in scope for this DT, where it
says REQUIRE, means that we are assuming it as input, and where it says
PROVIDE, means that they are outputs.

We continued with a recap discussion and partial walkthrough of
    draft-pritikin-anima-bootstrapping-keyinfra-01

We have some ideas about terminology that we think might be useful
along the lines of ducking/imprinting (cf: Konrad Lorenz and
http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also thought
of fraternities and pledges.  If you didn't grow up with
http://en.wikipedia.org/wiki/Animal_House, or
http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide some
explanation.  The idea that during the bootstrap process, there is a period
when the network (the ACP aka fraternity) and the new node (the peldge) check
each other out for fitness.  Wikipedia says this about fraternities:
   Requirements may be imposed on those wishing to pledge either by the
   school or the organization itself, often including a minimum grade point
   average, wearing a pledge pin, learning about the history and structure of
   the organization, and performing public service. When a school places an age
   or tenure requirement on joining, this is called "deferred recruitment", as
   joining is deferred for a semester or year. The pledgeship period also serves
   as a probationary period in which both the organization and the pledge decide
   if they are compatible and will have a fulfilling experience.

In today's telecon, we discussed some of the 6tisch specific requirements on
bootstrap, specifically:
  1) the "pledges" (or joining nodes) are constrained in CPU, code space, and
     energy (if battery powered, etc)
  2) more importantly, the network is very constrained, 250Kbit/s max, 127
     byte fraglets, and 6tisch likely would be configured to further
     restricts the bandwidth in the network available to joining nodes.
     Calculations suggest that just transmitting a DH pair and associated
     parts between adjacent nodes could take between 2 and 40s.
  3) most protocols will require an authorization protocol that will need to
     travel through the LLN mesh up to a non-constrained node. The
     convergence of many such setup processes may well overwhelm the parts of
     the network closer to the root of the tree.  Congestion is an issue,
     and retransmissions cost energy.

I explained some the ideas/conclusions from
  draft-richardson-6tisch-security-architecture-02
and draft-richardson-6tisch--security-6top-04, which were:
  a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") plans
     for 6tisch node/PCE communication, maximizing code reuse.

  b) initiating the secure bootstrap process from the non-constrained side,
     and having the constrained nodes remain silent after an initial "hello"
     packet, allowed the network manager to protect, conserve and prioritize
     the join bandwidth.

  c) it turns out there is an additional benefit in making the constrained
     node the TLS "Server" -- side. Specifically, it means that the selection
     of crypto parameters is done by the more constrained device, and the
     Server sends it's certificate payload first.  The non-constrained node
     (or "JCE" == Join Coordination Entity) will receive that certificate,
     and can consult whatever network (or human) resources is needs to
     before responding with a Client Certificate that will satisfy the
     constrained node.  It can also know via Trusted CA extension what
     certificate chain (if any) it needs to provide.

It is observed that point (c) is not essential; that a similiar thing can be
accomplished with less grace using SNI (RFC6066) and some other extensions.

Note that while 6tisch is/plans-to specify that 6top is the protocol that
runs over the resulting CoAP/DTLS channel, and that secure join to 6tisch
consists of provisioning certain identities and parameters through that
channel,  the resulting channel could be used for anything.

We also noted that in the context of two routers plugged in together on
a lonesome grassy knoll would need to form a secure connection; that one
needs to be the initiator ("client") and the other the responder ("server")
is obvious, but whether both systems need to always support both roles is
open for discussion.  Perhaps in the constrained case, it is acceptable that
constrained devices can always be responders, and in the non-constrained
case, they assume both roles.

I also note, recalling I was told that one implementation of the ACP consists
of IKEv2 initiated channels over IPv6-link-local addresses, that the
essential properties the bootstrap design team intends to provide work just
fine for IKEv2 as they do for DTLS.

I don't know if the ANIMA signaling protocol should occur before such a
channel is established, or inside of this (provisional) channel, or whether
it should instead run inside IKEv2 (maybe inside EAP).

I note that 6tisch has a few potential, "I am here" messages, with RPL
DAOs and Efficient-ND (E)AROs being the two ones.  GDNP or HNCP or just
IKE-port-500 messages are in my opinion also possibilities.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jun 2015 14:32:11 +1200

Michael,

Thanks much for the summary. Let me grab at some low hanging targets...
On 05/06/2015 04:56, Michael Richardson wrote:
...

>> 1. Define the scope of "zero touch bootstrapping". 

This is critical. Anima signaling deals with the needs of Autonomic Service Agents,
not with the devices that they manage in a use-case specific way. So if the scope
of your effort is wider than just the devices capable of containing ASAs, the
constraints may change considerably.

...
> The idea that during the bootstrap process, there is a period
> each other out for fitness.  

We also need to support the case where there is no ACP, just some sort of CA,
so that we can use vanilla TLS (or maybe DTLS).

...
> it should instead run inside IKEv2 (maybe inside EAP).

The current assumption is that discovery of the nearest trust relay has to
take place in the clear (and that draft-pritikin may not be the only
method available, going forward). That would mean one cleartext multicast
and one cleartext unicast response via GDNP. If that response was forged,
the bootstrap process needs to fail.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jun 2015 09:22:36 -0400

> This is critical. Anima signaling deals with the needs of Autonomic
    > Service Agents, not with the devices that they manage in a use-case
    > specific way. So if the scope of your effort is wider than just the
    > devices capable of containing ASAs, the constraints may change
    > considerably.

Can you give me an example that you think should be out of scope?

    > ...
    >> The idea that during the bootstrap process, there is a period when the
    >> network (the ACP aka fraternity) and the new node (the pledge) check

    > We also need to support the case where there is no ACP, just some sort
    > of CA, so that we can use vanilla TLS (or maybe DTLS).

I think that "CA" doesn't stand for Certificate Authority in this context,
but I don't know what it stands for here.  Can you give me an example?

    > ...
    >> I don't know if the ANIMA signaling protocol should occur before such
    >> a channel is established, or inside of this (provisional) channel, or
    >> whether it should instead run inside IKEv2 (maybe inside EAP).

    > The current assumption is that discovery of the nearest trust relay has
    > to take place in the clear (and that draft-pritikin may not be the only
    > method available, going forward). That would mean one cleartext
    > multicast and one cleartext unicast response via GDNP. If that response
    > was forged, the bootstrap process needs to fail.

I'd like to split things up such that we really have:
  1) discovery of peers via variety of protocols X,Y,Z
  2) trial establishment of security protocol
  3) ASA communication and potential establishment of ACP

I see that GDNP can be used for #1 and #3. Other protocols could also
be used for (1).  I'd like to think of the GDNP that is used for #1 as
being of a slightly different flavour than the one for #3.  I think that
doing so will let us more easily make progress as it will be clear that
just because we define an attribute for #3, doesn't mean it's valid for #1.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jun 2015 08:41:19 +1200

> Can you give me an example that you think should be out of scope?

Well, I'm not sure I have an opinion about that yet. I mean, sticking to the
building services scenario, I definitely want all the lighting controls to
be trustworthy and authorized. So in that view, the scope is "everything".
But I don't expect each light switch to run GDNP. If you set your scope to
"everything" then that excludes GDNP as a *required* part of the bootstrap,
I think. But that appears to be consistent with your model at the bottom
of this message.

> but I don't know what it stands for here.  Can you give me an example?

In fact I mean Certificate Authority, specifically for example the
Domain CA in draft-pritikin.

> just because we define an attribute for #3, doesn't mean it's valid for #1.

We agree on that. Basically 1) should be a strict subset of GDNP.
The GDNP engine would need to know that it was running insecurely and
therefore limit the allowed features.

    Brian