Subject: Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re: What elements of IETF ANIMA can be used for I2NSF?)

From: Randy Presuhn <[email-masked]>
Date: Tue, 28 Oct 2014 19:47:00 -0700 (GMT-07:00)

Hi -

>From: Michael Richardson <[email-masked]>
>Sent: Oct 28, 2014 7:53 AM
>To: "[email-masked]" <[email-masked]>
>Subject: Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re: What elements of IETF ANIMA can be used for I2NSF?)
...
>I claim that there is doesn't matter where the initial imprinting occurs;

Perhaps I'm being overly literal, but aren't there situations
where physical location might actually matter, as in setting
DVD region codes?

Randy

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Oct 2014 10:52:54 +0200

> where physical location might actually matter, as in setting

I agree with mcr. 

But first, being even more literal. The factories ship DVD players imprinted with appropriate region codes, and the imprinting for my blu-ray player says Europe, despite it being manufactured somewhere on the Korean peninsula. 

Of course, if this was security thing _I_ cared about, as opposed to a mechanism for protecting someone else, I would rather have local control of imprinting and not trust the manufacturer provided keys (at least, if my security requirements were high enough). Of course, could I trust the manufacturer’s hardware not to have backdoors and such is another topic for conversation. But extreme paranoia leads to inability of using anything not done from scratch yourself, is prohibitively expensive, and most likely fails anyway. So reasonable threat models and deciding which threats to actually are worth trying to mitigate is key here :)

At any rate, it is possible that either your IT organization, or even your manufacturer or reseller or whoever could slip in appropriate material on device much before it is actually deployed anywhere. 

Cheers,

-Markus

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Oct 2014 09:47:06 -0400

>>> I claim that there is doesn't matter where the initial imprinting occurs;

    randy> Perhaps I'm being overly literal, but aren't there situations
    randy> where physical location might actually matter, as in setting
    randy> DVD region codes?

    markus> I agree with mcr.

I think that Markus went into some DVD specific thing without answering the
aim of the question.

I don't think that the physical location ought to matter at all; what I think
matters is that the some organizations need autonomic mechanisms, but do not
wish to do this "in the field", while other organizations have the opposite
requirement.

Let me give two examples.  The first is made up (i.e. I have no specific
knowledge of it), while the second is one that I experience regularly.

1) a military and/or aid organization (think Medecin sans Frontier) receives
   a stack of equipment to their warehouse in New Jersey.  Let's they are
   setting up for a "MASH"-like installation.  They uncrate all the equipment,
   and plan to put 3x "typewriters", 1x microphone, 10x
   top-of-the-poll-loud-speaker, 2x mess-hall cash registers, 10x ventilators,
   2x cardiac machines.. (just imaging what a 2015-edition of "MASH 4077" might have).
   into each shipping container.
   In each case, they will power up the machines, in the warehouse, and some
   validation system will run once the machines are seen, and it will imprint
   the machines with the MSF identity.  The machines go *BACK* into their
   shipping boxes, and are distributed (mostly randomly) into shipping
   containers, one container per installation.
   {okay, today, we might rack mount it into the container and leave them
   in the container, but let's ignore that bit of modern lego work}

   The equipment might sit in the container for months to *decades* before
   it is actually deployed.  If there are any online processes that need to
   occur for the imprinting to occr, they occur in New Jersey where there is
   reliable power and Internet, not in Sierra Leone.

   If the equipment is stolen or redirected, etc. it likely won't trust any
   of the "hostile" networking equipment, and it won't be autonomic with it.
   This is good and intended.

2) a vendor (V) of security appliances buys 1U systems (Z) from vendor X.  Vendor X
   operates worldwide, and can provide fullfilment worldwide from local
   inventory to customer (C).

   Due to time, cost and excise issues, it is impractical to ship units
   from vendor X to V's office for installation and configuration.  In some
   cases mutually exclusive frequency assignments for things like wireless
   might even make it illegal to operate Z in V's country, and illegal for
   equipment in V's country to operate in C's country!
   (in the ways of 2mb/s 802.11 [no-letter] this was true)

   So the equipment is shipped by X to C, and C physically installs it in a
   new office.  Equipment Z has core routing functions. It would be ideal if
   equipment Z could recognize the network connections that it has, say who
   it is on them.  The autonomic process would then imprint the system.
   If system Z is being sold as a service, it might be that it gets imprinted
   to V.  It might get imprinted to C.  Or it might be initially imprinted to
   V, installed, and then ownership transfered to C.
   The final location here might matter; it matters that it's been installed
   at the San Jose office rather than in the New York office.

   [Today, I, as vendor V, must instruct customer C, on connecting up the
   IPMI/ILO/iDrac, and opening a port 443, and if it's actually core routing
   equipment, we are probably screwed anyway]

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 08:23:45 +1300

> wish to do this "in the field", while other organizations have the opposite

Right (after scanning your examples). So let me ask a more specific
question: look at draft-pritikin-bootstrapping-keyinfrastructures and
draft-ietf-netconf-zerotouch and opine whether either or both of
them is doing what we need. Or to put it another way, what do we need
to define in a generic way for all deployments, and what has to be
defined for specific scenarios?

   Brian

> ------------------------------------------------------------------------
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Oct 2014 13:48:52 -0400

> question: look at draft-pritikin-bootstrapping-keyinfrastructures and

read it awhile ago... examples come *FROM* reading it :-)

    > draft-ietf-netconf-zerotouch and opine whether either or both of them
    > is doing what we need. Or to put it another way, what do we need to
    > define in a generic way for all deployments, and what has to be defined
    > for specific scenarios?

I had read both before; bootstrapping-keyinfrastructures is too abstract to
judge the details....  I read zerotouch before it became a netconf draft, and
aside from being the only thing that I think is an issue with zerotouch
is that I think this MUST should be a MAY:

   "Devices supporting ZeroTouch MUST be pre-provisioned with one or more
    URIs for Internet-based Configuration Servers. "

The problem with https: URIs is that can not be used if one wants a
completely offline mechanism.  The secure URLs are to be tried first... in
order to make the offline parts work, one would need to block access to the
secure URLs, and then, I guess, impersonate the insecure ones.  This seems
wrong to me. So while the DHCP option can provide additional locations, it
seems rather pointless to force the local information to be processed last,
when it might be as secure as anything else.

It is certainly the case that netconf-zerotouch is not going to work for the
6tisch LLN situation;  but that's not a surprise to anyone I hope, nor does
it make it wrong for larger systems.

I think ZeroTouch already has enough security:

   In order to verify the signature on retrieved configurations, devices
   supporting ZeroTouch MUST also possess the trust anchor for the
   Configuration Signer that signed the configuration.