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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 08 February 2020 19:05 UTC

Return-Path: <brian.e.carpenter@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 19F561200B1 for <anima@ietfa.amsl.com>; Sat, 8 Feb 2020 11:05:31 -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 Xk1QiloYMadY for <anima@ietfa.amsl.com>; Sat, 8 Feb 2020 11:05:29 -0800 (PST)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 E5F9E120059 for <anima@ietf.org>; Sat, 8 Feb 2020 11:05:28 -0800 (PST)
Received: by mail-pf1-x42c.google.com with SMTP id y5so1508821pfb.11 for <anima@ietf.org>; Sat, 08 Feb 2020 11:05:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xD3KZiolPWLsNkpAAhiwGzeWc90j+L1R/T6xPh7yGTQ=; b=SH7mXLonSkyCgG0JQKRO4+S1YqvB/rktb5k4RUw+miBzUpn19VtFN9gfCBWTe4NDDn eShw6R8ZkZpRjieTnrGT5jrQ1TTLnRsaBJkbPFkOf5Oyl0DtKumx9xxacVhFb9RdUHOE eaVE2AxO+i1R5V7Mmh5qCRSXQONwMpgAQUJy+WJyUj0+CvIcUafb+XoQLbj9Pip5z646 mO46woSBHj7YOM0T0kgvsxU0I/Hme7jBOyis3O3KDa/gEydtGPt4ah4j1/QvyaHQptpb JEmZnFtSxhXdn2k5ICavYcY+Hu8t6id39JdQtDzseVGJIwkMmR01AmNH5ENGqloUONyp CmJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xD3KZiolPWLsNkpAAhiwGzeWc90j+L1R/T6xPh7yGTQ=; b=EDy/jizoBS50bXITpe0l4/MuyueKZLmZQp5Wy1jwq5zKjmgsgxwueMM8shJsLhjvxM BeEwrNTWKlgOIA6TexH9+jS8hpn7mJmxjuPbfS5PTyc5fXM32wP4w401Rs/e6PU5EwGj /Mhw7zD71AU4Usl9TO3N3/UZ2zWyxlCTRJrLYBc/OWK6ynJyf2MkNsgZoW7F3UMiE5b6 ceiSZ//xCrXgn3SD94vIaDNNYtIxVGTpRy19D4n3RfmhF7DQWJTdDS4l2yiONDdGpMPw VHNT009jRwH8mdBD0lEWtR6iVHPOM0/3mZDT1/KB8XMcg8kBOuhGdAuU4MaTCJKMZLn8 YdRA==
X-Gm-Message-State: APjAAAVbnMoT5GLIReA3WALx+j343bGXvcURH16Y128Zeyu/q1CJFGbL aJObB2MJ+TRFP4I+mdkDl6CWgALk
X-Google-Smtp-Source: APXvYqyY6V01mNjawWILZjk/zp6XX6R9irUUQesHbS4lImHBwGby3La/PeFN0Of1tRlm84eTdCxPqQ==
X-Received: by 2002:a63:9251:: with SMTP id s17mr5831425pgn.127.1581188727988; Sat, 08 Feb 2020 11:05:27 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id w8sm7558889pfj.20.2020.02.08.11.05.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2020 11:05:27 -0800 (PST)
To: "Michael H. Behringer" <michael.h.behringer@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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6e2c4a6b-c31b-427f-191e-68d7ef44b452@gmail.com>
Date: Sun, 9 Feb 2020 08:05:25 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <e815de18-bb91-9054-9b9b-375117ccc1ec@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/UQUHAzBoPSMNr4JTMRcCoTunUBE>
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: Sat, 08 Feb 2020 19:05:31 -0000

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.

> 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.
 
> 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
>