Subject: [secdir] Secdir review of draft-ietf-anima-reference-model-06

From: Radia Perlman <[email-masked]>
Date: Tue, 21 Aug 2018 21:29:34 -0700

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This document is an overview document (intended as informational)
introducing a large collection of I-Ds (intended as Proposed) describing
autonomic networking. Aimed at the Internet of Things with devices with
very little in the way of user interface other than over the network, the
design goal is to be maximally auto-configuring. Security is bootstrapped
using private keys and certificates installed by the manufacturer, where to
first goal is to join new devices to some sort of domain.

The most suspicious thing from a security standpoint is that it appears all
of the devices in a domain implicitly trust one another. This means that
bringing in the proverbial light bulb into your house could compromise your
whole house if the light bulb had a Trojan horse installed or some sort of
bug that allowed it to be compromised. There is some mention of addressing
this issue in the future, but unless I’m misunderstanding the approach this
seems like a very dangerous thing to deploy even initially. It makes much
more sense for each installed device to first become manageable by a single
other device in the domain. That first management device could cautiously
expand trust further.

The dangers are well summarized in Section 9 (Security Considerations).
Section 9.2 includes this text:

The above threats are in principle comparable to other solutions: In

the presence of design, implementation or operational errors,

security is no longer guaranteed. However, the distributed nature of

AN, specifically the Autonomic Control Plane, increases the threat

surface significantly. For example, a compromised device may have

full IP reachability to all other devices inside the ACP, and can use

all AN methods and protocols.

For the next phase of the ANIMA work it is therefore recommended to

introduce a sub-domain security model, to reduce the attack surface

and not expose a full domain to a potential intruder. Furthermore,

additional security mechanisms on the ASA level should be considered

for high-risk autonomic functions.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2018 16:47:21 +1200

Hi Radia,

Thanks for the review.

> This means that
> bug that allowed it to be compromised.

Indeed. But please note that ANIMA is scoped for professionally managed
networks where there is indeed a form of admission control for new
nodes. If that isn't made clear enough, then it should be. Secure
enrolment is the main topic of two of the other drafts (BRSKI and ACP,
a.k.a. draft-ietf-anima-bootstrapping-keyinfra and draft-ietf-anima-
autonomic-control-plane.) In that context, where for example unknown
BYOD devices simply could not join the autonomic network, because they
are unknown to the registrar, we think we are covered.

So in fact networks like homenets or *unmanaged* IOT edge networks
are not in scope. How malicious nodes can be kept out of those
networks is indeed an enormous challenge.

Regards
   Brian Carpenter

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 22 Aug 2018 09:16:07 +0200

Thanks for the review, Radia

Some perspective on the design choices made by ANIMA re to this group
security (and i'll reference this in the sec review of ACP spec that i am
now trying to get back to after an NMI i am trying to finish):

a) As Brian mentioned and as the ACP spec (draft-ietf-anima-autonomic-control-plane)
   in section 1.1 explains in more detail than the reference model, the prime
   target for ANI are professional managed networks, and IoT is only addressed
   opportunistically right now. Meaning: there are likely things missing for IoT,
   such as scale-down aspects. Other WGs are already working on those (like 6tisch).

b) The model of "group-security" of the ANI (either you're in, or you're out),
   is not the sufficient solves-all for security, but it is the necessary base
   level of security. For once to meet the original design goal of our current
   charter:

   The autonomic network architecture as passed from IRTF/NMRG in rfc7575 to ANIMA
   is meant to enable fully distributed peer-to-peer self-organization and operations
   of intelligent network devices/services without an assumption of any centralized
   backend that is orchestrating the network.

c) Consider just the security methods we have today in distributed protocols.
   Every protocol has its own variant of peer-to-peer security: every IGP, BGP,
   multicast protocols and so on. reinvention of the wheel over and over. And even
   though a lot of security exists for such protocols, it is not even widely
   deployed for most of them. So allowing the next round of distributed
   protocols/services to be build without having to reinvent that wheel was one
   key goal. [ Likewise also the CBOR(binary JSON) and common discovery mechanisms
   of GRASP are tools to avoid the reinvention of discovery and encoding for every
   new distributed protocol.]

   Note also that the fully automated PKI architecture of ANI allows to remove
   suspcious nodes from the domain (group trust). 

d) ANI also uses this group-security to create a cryptographic version of standard
   "clamshell" security in network operations - even without building new protocols
   as proposed in c)". This is what the use case of ANI for centralized management
   is all about (RFC8368). Classically this security is done through ACL, separating
   "inside management" addresses from "user addresses", so replacing that with
   the cryptographic secured ANI model is certainly a big step to more security.

e) Instead of just having a single "controller" empowered to have more control than
   other nodes as you suggest, i did suggest the notion of "roles" in the ACP
   spec A.10.5, also embodied via the ANI domain certificates.
   
   The reason for not including this into the normative part of the
   ACP spec (and therefore also not into the current reference model document)
   is that pretty much everyting in the ACP spec if very much based on existing
   commercial implementations (plus trying to fix in the standard docs details
   we learned to be not good in products and/or requested by WG discussion).  The
   role assignment is more novel, not tested in deployment, and therefore better
   separated out.  Also, it would be a part of the solution that fully peer-to-peer
   networks would likely not want.

   Finally, just specifying the security model as in A.10.5 is not the hard part of
   role based security. Sitting down and defining the policies implied for the
   important existing OAM services in nodes and the different type of roles (is NOC 
   vs. non-NOC node good enough) will take more work and should be done with more time.
   At this stage of the ANI docs, it would just be scope creep for the existing docs.

f) The real fun part would actually be how a full peer-to-peer autonomic network
   with maybe just the existing group-security or even no security at all initially
   would try to bootstrap itself into a more structured security model. Alas,
   that is IMHO far beyond what IETF or especially an OPS WG like ANIMA could or
   should do. But i did bring this up tangentially in my IETF 102 DINRG talk
   about ANIMA. Distributed voting/decision making is in scope there, so distributed
   security and peer-to-peer role role would certainly be a good use-case area.

   Alas, while being more fun, i think like you that e) is what we should do next
   in ANIMA because it is more immediately necessary/deployable. If you would like
   to contribute to that follow-up spec, that would be great!

g) Final note: the reference model is really only focussing on the fully distributed
   ANI -> Autonomic Network primary target of ANIMA. My considerations above are
   also inclusive of the use of ANI standalone, e.g.: for centralized NOC operations,
   so please do not expect that everything i said is or should be in the reference
   model doc. For example re. suggestions like "sub-domains vs. what i wrote in
   f), i think the evolution of the fully distributed autonomic network is a lot
   more complex..

Cheers & thanks for the review

    Toerless

On Tue, Aug 21, 2018 at 09:29:34PM -0700, Radia Perlman wrote:
> this issue in the future, but unless I???m misunderstanding the approach this

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Aug 2018 08:10:03 +1200

Radia,

We've added this in version -07. It was definitely needed:

 The scope of this model is therefore limited to networks that are to	
 some extent managed by skilled human operators, loosely referred to	
 as "professionally managed" networks.  Unmanaged networks raise	
 additional security and trust issues that this model does not cover.

Regards
    Brian