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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 31 October 2014 17:49 UTC

From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <54529041.7060309@gmail.com>
References: <15427082.1414550821026.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <34F2BB84-CDD9-47C1-A4DE-08373F0785EC@iki.fi> <14853.1414676826@sandelman.ca> <54529041.7060309@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Fri, 31 Oct 2014 13:48:52 -0400
Message-ID: <24024.1414777732@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/anima/OVNLUUtuvVnax84TjkQ99duhGtw
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re: What elements of IETF ANIMA can be used for I2NSF?)
Precedence: list

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > Right (after scanning your examples). So let me ask a more specific
    > 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.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Re: [Anima] Homogeneous vs. heterogeneous trust d… Randy Presuhn
Re: [Anima] Homogeneous vs. heterogeneous trust d… Markus Stenberg
Re: [Anima] Homogeneous vs. heterogeneous trust d… Michael Richardson
Re: [Anima] Homogeneous vs. heterogeneous trust d… Brian E Carpenter
Re: [Anima] Homogeneous vs. heterogeneous trust d… Michael Richardson