Re: [Anima] Security Levels//RE: Ownership Concept

Rene Struik <rstruik.ext@gmail.com> Thu, 26 March 2015 15:27 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01F1A1B21 for <anima@ietfa.amsl.com>; Thu, 26 Mar 2015 08:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG9kkATjOrqr for <anima@ietfa.amsl.com>; Thu, 26 Mar 2015 08:27:00 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7903B1A00ED for <anima@ietf.org>; Thu, 26 Mar 2015 08:26:59 -0700 (PDT)
Received: by wibg7 with SMTP id g7so152805559wib.1 for <anima@ietf.org>; Thu, 26 Mar 2015 08:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=GB3x4e+yCxXxm2sGpVoySGloKfR1KHbb/c1Kzx91McM=; b=eYwI1uq8gg19eEkeG+5JSaxaKYYcnt+pGScfSDPbDrjRdrcaOMyd3WpahLN+AfcOcs ky8TC2b8r+Mk8apPLa8VCDGx+osLDarKb8tcYRfTear1EZuAZdpspoaTYLTN3nC5RePH 0zk21b+Uv3Drr3rqVV7fsTvODANw+ILjD1SPcxDVu3U9+qK5zSEiv7IL29iYjixi7vpQ NkdjBTsJ6MCvKxiC3yCeykzSrXzId9pU8hi3V8HNU9+6xGxYEjFptL7Y1dTyuwCNO99F mU2QK1PrdOBK+sYbgbT5eSJkZZBVL1/te/RWzm3b6Ezp0q1jRs0T0fo3QSONmgO0eUBV 15oA==
X-Received: by 10.194.59.199 with SMTP id b7mr29700531wjr.26.1427383617281; Thu, 26 Mar 2015 08:26:57 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:2581:da2a:4964:7646? ([2001:67c:370:160:2581:da2a:4964:7646]) by mx.google.com with ESMTPSA id ax10sm8859962wjc.26.2015.03.26.08.26.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 08:26:56 -0700 (PDT)
Message-ID: <55142538.6010703@gmail.com>
Date: Thu, 26 Mar 2015 11:26:48 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Sheng Jiang <jiangsheng@huawei.com>, "Hedanping (Ana)" <ana.hedanping@huawei.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <5D36713D8A4E7348A7E10DF7437A4B925F4C4FC9@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C4FC9@NKGEML512-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------040802090204030307050603"
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/YdRQlUHGbKKEt5Pcp4O5ixg8jMM>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Anima] Security Levels//RE: Ownership Concept
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 15:27:03 -0000

Dear colleagues:

I think some of the discussion would benefit from distinguishing 
different objectives one may have for security services. The (very old - 
2003) two paras below illustrate this, in terms of network security vs. 
application security.

Max Pritikin mentioned the risk that a device that joins the network may 
end up with malware, which may end up with the correct network it may 
later on join.

I think his example conflates network security and application security, 
since the underlying assumption seems to be that the (adversarial) 
network manager (the one injecting the malware) has both authority to 
communicate network-related parameters and to change huge chunks of 
internal state of the device that does not have to do anything with 
infrastructure security (but with device management).

So, finer detail on the underlying security model and granularities at 
play helps.

Rene
==
Security policy and trust model
The main objectives of network security are to provide for 
infrastructure security and application security. Infrastructure 
security deals with controlling admission to networks. The objective 
here is to restrict access to scarce network resources to authorized 
resources only, such as to ensure proper bandwidth allocation, 
protection of commands (such as those regulating network membership and 
exchange of status information), and, e.g., power drain savings. 
Application security deals with controlling access to actual 
information. The objective here is to restrict access to information 
shared between members of a group of network devices to precisely these 
group members, such as to prevent external parties from learning the 
contents of exchanged messages and from modifying message traffic or 
injecting their own messages in an undetected way.

Infrastructure security and application security have different 
underlying trust requirements. With infrastructure security, the network 
owner may have an interest in restricting access to his network to 
privileged devices only, based on specific criteria, such as device 
subscription to the network or charging for airtime/bandwidth, whereas 
network devices might not care who the actual network coordinator is, as 
long as access to bandwidth is satisfactory. With application security, 
devices that exchange information may have a vested interest in keeping 
their communications private, also from the network owner. Both types of 
security involve the management of groups of devices, either for 
controlling network membership (by a network coordinator) or for 
restricting access to information to specific groups (by a security 
manager).

On 3/26/2015 11:11 AM, Sheng Jiang wrote:
> Hi, Ana,
>
> You have mentioned security levels, which I think it is worth a separated threat to discuss it.
>
> For my understanding, in Autonomic Network, we want to minimize the human operating, which includes the operating on security level. Therefore, we would like to design a system with as less as possible security levels.
>
> By having domains, we may be able to get the simplest - one security level - full trust/security.
>
> I also understand, in IoT scenarios, you probably need at least one more security level - exchanging information without trust relationship. This may be categoried into unsecure communication. So, this may still ok for the one security level design: secure+unsecure.
>
> Cheers,
>
> Sheng
> ________________________________________
> From: Anima [anima-bounces@ietf.org] on behalf of Hedanping (Ana) [ana.hedanping@huawei.com]
> Sent: 26 March 2015 13:48
> To: Brian E Carpenter; Rene Struik
> Cc: Hannes Tschofenig; anima@ietf.org
> Subject: Re: [Anima] Ownership Concept
>
> I agree that ownership is important in life-cycle consideration, but I believe it belongs to higher security level that impacts the interaction or manipulation between NEs or between NEs and owner.
>
>    > -----Original Message-----
>    > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>    > Carpenter
>    > Sent: Thursday, March 26, 2015 12:12 AM
>    > To: Rene Struik
>    > Cc: Hannes Tschofenig; anima@ietf.org
>    > Subject: Re: [Anima] Ownership Concept
>    >
>    > I think it is unanswerable, or at least the answer is YMMV. You may
>    > remember that one of my comments on draft-pritikin was basically: I hate
>    > the MASA. I was glad to see the connection to the MASA was clearly
>    > indicated as optional in the slides yesterday. The point is that we have no
>    > control over this - different classes of device and different vendors will have
>    > different ideas about this. I firmly believe that any design we do in the IETF
>    > has to be very flexible on this point.
>    >
>    > Regards
>    >    Brian
>    >
>    > On 25/03/2015 11:21, Rene Struik wrote:
>    > > Hi Hannes:
>    > >
>    > > I think supply chain issues, and transgression from one supply chain
>    > > step to the next, are important in life-cycle considerations. This
>    > > includes how to move from one logical "owner" to the next and potentially
>    > "cutting the ties" with the former. These aspects certainly require more
>    > work.
>    > >
>    > > A very simple example of supply chain would be relabelling a device as
>    > > a "white goods" device (e.g., by selling a branded good at a
>    > > superstore, such as Walmart, under the Walmart brand, whereas in reality
>    > it outsourced all production (except perhaps putting the sticker on top).
>    > >
>    > > Best regards, Rene
>    > >
>    > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>    > >> There was no time during the meeting today to ask too many questions
>    > >> (because of lack of time). That's unfortunately and so I have to fall
>    > >> back to the mailing list.
>    > >>
>    > >> I wanted to get some better understand what the ownership concept is
>    > >> about and what the implications are for the protocol design. The term
>    > >> came up in various presentations today and it appears to be important.
>    > >>
>    > >> Many parties are involved in the manufacturing process of products
>    > >> today and the value chain is certainly complex. Hence, who the owner
>    > >> of what is and at what point might be difficult to determine.
>    > >>
>    > >> Does it really matter who the owner actually is?
>    > >>
>    > >> Ciao
>    > >> Hannes
>    > >>
>    > >>
>    > >>
>    > >> _______________________________________________
>    > >> Anima mailing list
>    > >> Anima@ietf.org
>    > >> https://www.ietf.org/mailman/listinfo/anima
>    > >
>    > >
>    > >
>    > >
>    > > _______________________________________________
>    > > Anima mailing list
>    > > Anima@ietf.org
>    > > https://www.ietf.org/mailman/listinfo/anima
>    > >
>    >
>    > _______________________________________________
>    > Anima mailing list
>    > Anima@ietf.org
>    > https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363