Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-03.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Jul 2016 15:47:21 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> b.  MUST: Performs DNS-based Service Discovery [RFC6763] over
    >> Multicast DNS [RFC6762] searching for the service
    >> "_bootstrapks._tcp.local.".

    > I missed the bit where we got consensus to only specify DNSSD for
    > discovery. My understanding was that since all ANs will contain the ANI
    > components, GRASP discovery was an equally valid option.

This topic has come up repeatedly, and we have discussed it a lot.
Maybe we need to do a full WG Consensus call about this?

===

We really like GRASP, and we want to use to find pieces of the bootstrap system.

a) We believe that bootstrap will be used by many devices which do not have
   a full AN stack.
   And it could be that a line card that will have a full AN stack, doesn't
   even have a full AN stack when it boots up the first time.  It might not
   even know that it will have a full AN stack until such time as it receives
   its first firmware update after/during NETCONF-style bootstrap.

b) We believe that having a MTI that is already present in constrained
   devices that might never do a full AN is a win.

c) From a long history of security standpoint, we believe that restricting
   GRASP to work within the secured ACP (only) will have significant attack
   surface advantages.   While one could run a second GRASP instance that is
   disconnected from the first on the proxy node, it would have to get a
   number of configuration parameters via the secured GRASP side.

   The history of computing is replete with examples of priviledge escalation
   attacks from situations that were not originally envisioned.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                  (Camping this week!)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Jul 2016 18:35:05 +1200

Hi Michael,

> Maybe we need to do a full WG Consensus call about this?

Well, let's see if we can work it out ...
>    its first firmware update after/during NETCONF-style bootstrap.

Yes. So some careful phrasing about the default behaviour as well as the
MTI is needed, in any case.

>    devices that might never do a full AN is a win.

Certainly. I am not objecting to an MTI but the text I quoted excludes
alternatives to the MTI.

>    number of configuration parameters via the secured GRASP side.

We're only talking about discovery here. So I really don't understand that
argument. GRASP discovery returns a transport locator (address, protocol, port).
By definition GRASP is running insecurely pre-bootstrap - it isn't a question
of an instance, it's actually a mode of operation. Once you've got the
transport locator you can do whatever you need to with it. GRASP will refuse
to perform any "real" operations (negotiation or synchronization) unless
it's secured.

I just don't see any security difference between mDNS or DNSSD for
"_bootstrapks._tcp.local." and grasp.discover() for an objective called,
for example, "_bootstrapks._tcp.local."

>    attacks from situations that were not originally envisioned.

Indeed. Exactly why GRASP says:

   The ACP, or in its absence the local PKI, sets the boundary within
   which nodes are trusted as GRASP peers.  A GRASP implementation MUST
   refuse to execute any GRASP functions except discovery if there is
   neither an operational ACP nor an operational TLS environment.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jul 2016 21:39:44 +1200

On 01/07/2016 18:43, Brian E Carpenter wrote:
> Hi,
> discovery. My understanding was that since all ANs will contain
> the ANI components, GRASP discovery was an equally valid option.
> 
> DNSSD is a fine option for non-ANs that don't contain the ANI
> components.

So after some thought, I believe that we have to change this to better
fit the ANI as a whole by changing it to something like this:

    b1. MUST: Performs DNS-based Service Discovery [RFC6763] over
        Multicast DNS [RFC6762] searching for the service
        "_bootstrapks._tcp.local.".

    b2. MUST: If the node in question supports GRASP signaling
        [I-D.ietf-anima-grasp], also perform GRASP Discovery searching
        for the Objective "_bootstrapks._tcp.local." using a loop
        count of 1 to ensure link-local scope.

That allows non-Anima devices to use DNSSD if that's their bag,
and allows Anima deployments to omit DNSSD support if they want.
The device will use the result of whichever discovery replies first.
We can use the same name with no problem.

I would argue that since all ACP nodes will support GRASP anyway,
ACP-creation should use GRASP discovery, so that DNSSD support doesn't
become mandatory in the ANI. I don't really see what we win by
inserting DNSSD unnecessarily. If it's needed for non-ANI reasons,
that's fine of course, but the ACP doesn't need it.

Regards,

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 19 Jul 2016 00:30:48 -0700

Brian:

It sounds from your latter text as if you really wouldn't like to see b1. ;-)

Just to refine my position as contributor:

AFAIK, The MUST for mDNS was IMHO from the authors from the following
assumptions:

  1. Devices already will do mDNS
  2. There is nothing wrong with mDNS, anima principle, reuse existing
     protocols unless proven otherwise
  3. Separate code basis from GRASP used securely == highest separation of
     signaling between secure / insecure.

IMHO:

  1. Most network devices i deal with do not do mDNS.
     i do not know enough IoT devices to have opinions about those, but
     i wonder how important those are re. existing anima charter.

  2. a) My main fear remains undesired proxying of mDNS messages by
     some equipment, thereby creating undesired ACP connections. mDNS
     proxying has become quite popular.

     b) IMHO mDNS has a lot of baggage because it's built on a 25 year
     old DNS arch amended with a Service Discovery extension. So
     it's really a lot of complexity under the hood. Unless a solution
     needs to use the DNS namespace i am not sure why it would be
     a preference.

     c) I can't imagine that all the IoT spaces will convege on just
     one discovery protocol as heir preference, so i think it's an
     illusion to think we can hit "one preferred" by all model.
     Eg: DPWS (derived from WS-Discovery) is also used/preferred
     in certain IoT spaces AFAIk.

  3. I have never seen point 3. as a system design principle. My background
     is in routing, and BGP and IGPs for examples are used extensively
     in the same devices running in different instances for different
     isolated domains (eg: l3vpn). Reuse of the same protocols as
     much as possible, because their security properties are understood
     and isolation between different instances is an accepted model of
     reuse and mutual isolation (shared code, no shared data).

So, to me the best principles to adopt in bootstrap are:

  -> Bootstrap Proxies should support all the discovery protocols that
     their clients desire.
  -> Clients that are ANIMA devices themselves have GRASP, thats
     sufficient, and its a protocol we can fully control. If we discover
     problems we can easier fix them as problems with a protocol that
     has a lot of other pre-existing uses and our requirements could
     conflict with those.
  -> If any set of non-ANIMA client devices desiring bootstrap prefer
     mDNS, the proxy of course should also support mDNS.

Comments welcome.

Cheers
   Toerless

On Mon, Jul 18, 2016 at 09:39:44PM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 05:56:55 -0400

> i wonder how important those are re. existing anima charter.

I am not mostly *not* thinking about tiny constrained motes here.

I'm thinking about various appliance-like things: the home NAS, the iDRAC/ILO
service processor, etc.

*THESE* devices might not run GRASP.
They *might* want to join the ACP.
They *do* want to do secure bootstrap.
They already have mDNS.

Or to put it another way: I'm thinking about the light controller, not the
lightblubs.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2016 22:10:29 +1200

> Or to put it another way: I'm thinking about the light controller, not the

1) the concept of a 'lightblub' is very appealing.

2) on balance, I think I agree with Michael slightly more than
with Toerless. Even though this use case is strictly outside the
Anima charter, I think we'd look very silly if the autonomic security
bootstrap could cope with routers and application devices such as
autonomic energy management boxes, but not with lighting controllers.

   Brian

---

From: peter van der Stok <[email-masked]>
Date: Tue, 19 Jul 2016 12:18:26 +0200

> autonomic energy management boxes, but not with lighting controllers.

Abstracting from the device naming, I agree with Brian and Michael.
There is no guarantee though how blubs can evolve in the future.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 06:19:15 -0400

> proxying has become quite popular.

I don't see the problem.
a) proxy mDNS all you like, the proxy reply is supposed to be a
   link-local address, and if the mDNS was proxied, then the connection
   failed.

b) assuming that a non-link-local address was returned, and the
   implementation was given a routable source address, (very possible
   on an active LAN with DHCP/SLAAC available), and it connects to
   the proxy.  There is then an enrollment. Or there isn't.

b) assuming that the enrollment worked, then whatever the ACP
   discovery mechanism is (is it GRASP? I don't know) would run
   on the link if the new system wanted to join the ACP.

   We never suggested that this discovery would be mDNS.

    > illusion to think we can hit "one preferred" by all model.

Multiple vendors are doing this.
We made multicast work in great part so that mDNS would work.

    > reuse and mutual isolation (shared code, no shared data).

Most priviledge elevation exploits for Windows and Linux leverage that a
feature was added to the code base to support function X, which, when
combined with operation Y, does something unintended.

For an example from the routing space, I point to why we can't use source
routing in most places.  It has no security risks at all until you start
assuming that things behind a firewall are trusted and things outside are
not.

This is the kind of thing that we are thinking about.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 00:21:20 -0700

Inline

> 1) the concept of a 'lightblub' is very appealing.

I think those are the nodes in the lighning network i proposed yesterday after roll *sigh* ;-)

> autonomic energy management boxes, but not with lighting controllers.

Well, if those nodes *DO* want to join the ACP, they *MUST* already
have GRASP, so we're back to undecideable FUD like "is a separate
protocol more secure than a separate instance".

What we need from a proxy to a client is so simple, it's almost not a protocol:
Periodic link-local multicasted announcement of a data structure on the proxy:
[Name, [(method, locator)], receipt and parsing on client side.

If i take an existing mDNS library, i am sure i will have no easy way
to prohibit the client code from multicasting an mDNS query but
instead only listen to those announcement. So i have to hack into the
mDNS library. Which i may not be able to do because it's most likely OS/library
code that i don't even have in source.

If the device has upfront neither mDNS nore GRASP and does not want to
join the ACP but just bootstrap, it comes down to whats easier to code
into parsing the data structure. Pretty sure a CBOR library would win.
Don't think there's even a library just to parse DNS packets, and
inheriting a whole mDNS library in source and hacking it up to just
receive these packets doesn't sound like a good spend of time.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 00:36:13 -0700

>    link-local address, and if the mDNS was proxied, then the connection

Unless multiple devices have the same link-local addresses. Like
the cheap arduino's that do not come with unique MAC addresses
and where then programmed lazily (happened to me).

>    the proxy.  There is then an enrollment. Or there isn't.

And we could explicitly ask implementations to ignore non-LL addresses
because they are an attack vector (one level of security when you do not
choose to use audit-token/ownership-voucher is to carefully plug new
devices only into sane network sockets, so you definitely do not
want to have those sockets infested by mDNS proxied proxy announcements).

>    We never suggested that this discovery would be mDNS.

Yes, that would be GRASP.

> We made multicast work in great part so that mDNS would work.

Link-local or L3 ASM with non-standard larger than LL mDNS ?

> assuming that things behind a firewall are trusted and things outside are

I can't translate that into something i think would apply to our case, but
if one is worrried that the eg: code-space of full blown GRASP inside
the ACP could be be impacted by the insecure mode GRASP, then i think
it's most easy to write the 10 lines of code to just implement the
periodic insecure mode GRASP announce messages as a one-off. And the
overhead to do this would IMHO compare well with risks of any
other code basis.

> This is the kind of thing that we are thinking about.

Sure. Lots of subtle points. To me they just add up to a negative
on mDNS in this circumstance.

Cheers
   Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 20:11:00 +1200

Rushing to the bottom line:

On 21/07/2016 19:36, Toerless Eckert wrote:

...
> on mDNS in this circumstance.

Obviously, if the bootstrap and ACP teams come to this conclusion,
this GRASP co-author will not fight it :-).

But we will have to justify it to the rest of the IETF.

   Brian