Re: [Anima] Brian/anima: trust notion of ASA communications

"Michael H. Behringer" <michael.h.behringer@gmail.com> Mon, 10 February 2020 09:26 UTC

Return-Path: <michael.h.behringer@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D731200B4 for <anima@ietfa.amsl.com>; Mon, 10 Feb 2020 01:26:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 H9sra7H4IWOD for <anima@ietfa.amsl.com>; Mon, 10 Feb 2020 01:26:42 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 2899A12008C for <anima@ietf.org>; Mon, 10 Feb 2020 01:26:42 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id g3so5566825wrs.12 for <anima@ietf.org>; Mon, 10 Feb 2020 01:26:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=RTu6wpP1hxIEB6BON2k6tPRyH+tq2SrUCLdIYxFmx+0=; b=f7URVcysxPKo1QxjD5BY7qg+eLTb5ytepjXCCufa1G8kMoaLdpuEGuuZdqw+yDKZbz vryEsE+Q61o9/bmiODZq9bBWrtgFujmSIu44jD+kG+d1HRduLNGebDXqQ91+T257KDFE e2Li5sTPQINlzfdUdkdp8MnY1zUXSdTDFDuFHqvezvcK19nKZGeKk0w7a+U6MZ7FJzfW AENjR07kcChOhUaqPlyfoz4S1IQ5lbHC/nvtMS9931sZdIyoxkJWZf1GZVA+Vas7M7lW 3KqXprinvzRdILynxoePB6XAKtbrTpycTxQXIjJoBv3LxZdCzDOALd/kqz0Iwei1gsfB hS4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RTu6wpP1hxIEB6BON2k6tPRyH+tq2SrUCLdIYxFmx+0=; b=aAzfpSPj2pjpdw4hVbmlkKm/Iji3i0DR/tJQNYsPohk80UVgi5soZdxsCxAbibyd9B 5NEo34OJnWC1VW0owS2jmzVFoJUc6RssSR7nYvafJjMxsw0LzHOnA+mgjvBOjBkkL1zn X3IT539Qlq08rA0uftjNPKgPYY6CDuUPIw91uACkTZ57nP92f/ZrNTqNLqXAzL3dknaU W0rL+ny5F9+kAXd/S14GpDox+yGR67V7cs3MRkdxGvbpCq8s1LVG7tsoTXLdtcFe/I2J j6tPzCPyp7hGsmoMaN8MOil8evs7A4s6t6YVpIRVtFr8N976G1f3ThoXoaJ9ZE/jePRW gm3w==
X-Gm-Message-State: APjAAAUCj+NGicB8/cjtETPLKH6if0ZHAyMgHLnlnpoIYcSkq6ih2Blp PITj/qeAg9eFltEwbZvF8+bD61ws
X-Google-Smtp-Source: APXvYqyj4OShIo7MGZmWe6boMs9tDQe5tbquwA42KTY+r3yc8mLCp5iS84Q+m6bKv0tQRj/koMSKeA==
X-Received: by 2002:a5d:51ce:: with SMTP id n14mr887495wrv.426.1581326800120; Mon, 10 Feb 2020 01:26:40 -0800 (PST)
Received: from ?IPv6:2a01:cb1d:111:eb00:24ff:9485:d3dd:68b9? ([2a01:cb1d:111:eb00:24ff:9485:d3dd:68b9]) by smtp.gmail.com with ESMTPSA id l8sm14816284wmj.2.2020.02.10.01.26.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Feb 2020 01:26:39 -0800 (PST)
From: "Michael H. Behringer" <michael.h.behringer@gmail.com>
X-Google-Original-From: "Michael H. Behringer" <Michael.H.Behringer@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, anima@ietf.org
References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku> <20200207145802.GA37834@faui48f.informatik.uni-erlangen.de> <253d0b55-485e-3f09-adb4-2aa843420fa3@gmail.com> <e815de18-bb91-9054-9b9b-375117ccc1ec@gmail.com> <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com>
Message-ID: <5c85e950-41f1-7fa3-cded-7d6c807b9afd@gmail.com>
Date: Mon, 10 Feb 2020 10:26:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dnDCXlVO1GZBkAa5uOb_2stJLoI>
Subject: Re: [Anima] Brian/anima: trust notion of ASA communications
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 10 Feb 2020 09:26:45 -0000

On 08/02/2020 20:05, Brian E Carpenter wrote:
> On 08-Feb-20 23:36, Michael H. Behringer wrote:
>> Brian, I'm not sure I understand your phrase "the private key will be
>> scattered around the autonomic domain." Are you suggesting to create a
>> key pair for a role, and if several nodes have the same role, they will
>> have the same private key?!? That strikes me as very unusual...
> Yes. But if you're a network operator, you're very pragmatic and if you have
> an updated binary of an ASA that you need to install on 500 nodes, you won't want
> to add a complex key management task to the installation.
>
> Indeed it's bad security to share a key. I just think that it will happen, if
> we propose an alternative that is perhaps as complex as BRSKI itself but is
> applied at the ASA level instead of the node level.
OK, I think we agree: let's make sure that doesn't happen! :-)   In any 
case, if the goal is to prevent a potential hacker to spin up any ASA on 
a hacked node, then a key delivered with the ASA won't do the job, 
right? Because that could potentially be found on another hacked node, 
and copied as well.

We need to first define the problem statement precisely. (Maybe it's 
just me who doesn't have it clear?)

The problem is that a node runs an ASA which it shouldn't. Right?

There is however more than one way to get to this situation:
1) A node may be hacked, have all sorts of ASAs installed manually by 
the hacker, and use those in ways not intended by the operator. 
("malicious case")
2) Autonomic nodes may well decide by themselves to run certain 
functions if needed. ("Erroneous case")

I agree with Toerless: The concept with a special bit in the certificate 
isn't all that bad. If it's a pretty static function, it's perfectly 
appropriate. (Like a diplomatic passport). Let's not throw this out.

As Toerless said: "crowd intelligence based on client measured service 
performance experience" would be a solution to the 2nd case. But that's 
to me for further study, not a short-term goal. And that may well be 
different for different types of ASA.

The middle way would be a centrally controlled directory, that nodes can 
query. Needs more thinking. Do we want to check permissions for all 
types of ASAs? How long can you cache permissions? Do we want to define 
different "security levels" of ASAs, to distinguish between "to be 
checked at each usage" and "trust crowd intelligence" and "trust 
implicitly"? Should we just re-use an existing scheme for that? (AAA?) 
This isn't going to happen in a rush...

Michael


>
>> I think we're back to really old concepts of security:
>>
>> A node has an identity and a role. The identity is proven by a
>> certificate. The role (ex: Prefix Manager) is assigned to an identity.
>> And a role may require a specific ASA to fulfil its function.
> Make that plural. A node may have mutltiple roles and a role may
> multiple ASAs.
Yes. The word "a" was not meant as an enumeration.
>> As Toerless points out, we CAN (and do) assign roles statically in a
>> certificate. In the "real" world a diplomatic passport is exactly that:
>> It's an identity of a person, plus a role (diplomat). But that only
>> makes sense for fairly static roles, and I would not suggest that for
>> things like Prefix Manager.
>>
>> There are two alternatives:
>> 1 - We come up with a consensus model (see Toerless' mail). In a
>> distributed model such as ANI very interesting, but I think needs a lot
>> more work. Much more common though:
>>
>> 2 - We maintain a directory (read: a secured database), where we assign
>> roles to identities. This is "normal" in standard security. Role based
>> access control for example, Active Directory, etc.
>>
>> I would vote for a directory type of solution at first. This way an
>> administrator can assign and change roles quite easily. Later we can
>> look into consensus models.
> I agree entirely, but it wasn't obvious that Toerless was heading in that
> direction.
>   
>> I'd need a lot more convincing that certificates for roles (or ASAs) are
>> a good idea. And shared private keys (actually: Contradiction in terms,
>> I probably misunderstood Brian there) definitely not.
> Again, I agree. I was simply speculating about what I expect operators would
> do if presented with too much complexity.
>
>      Brian
>
>> Michael
>>
>>
>> On 08/02/2020 00:04, Brian E Carpenter wrote:
>>> On 08-Feb-20 03:58, Toerless Eckert wrote:
>>> <snip>
>>>> Sure, and i am going to run a hacked ACP node thats announcing in GRASP
>>>> to be the "best-ever" node to provide that service ;-) How to you
>>>> prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
>>>> there is some ACP crowd intelligence that says i am untrustworthy.
>>> I don't see how you can get away from asymmetric crypto to do that. An ASA
>>> comes up and says 'I support "DANGER"', which is a GRASP objective for doing
>>> something very dangerous. Take a concrete example: 'I support "PrefixManager"',
>>> which is defined in draft-ietf-anima-prefix-management and will be in an
>>> RFC one day soon. So this ASA needs to be trusted to allocate or assign
>>> IP address space.
>>>
>>> How can we check this is OK? As far as I can see, only if we have previously
>>> decided to trust any PrefixManager ASA that can prove possession of a given
>>> private key, or more precisely one of a given set of private keys.
>>>
>>> In practical reality, I'm sure operators will want to install identical
>>> binaries of a given ASA on multiple autonomic nodes. So the private key
>>> will be scattered around the autonomic domain. My guess is that a lot of
>>> operators would not see this as any better than just trusting the nodes,
>>> not the individual ASAs.
>>>
>>>       Brian
>>>
>>>
>>> _______________________________________________
>>> 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
>>