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

[Brian E Carpenter <[e-mail]>]

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
On 2018-08-22 16:47, Brian E Carpenter wrote:
> Hi Radia,
> 
> Thanks for the review.
> 
>> 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.
> 
> 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
> 
> On 2018-08-22 16:29, Radia Perlman wrote:
>> 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.
>>
>