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

"Michael H. Behringer" <> Sat, 08 February 2020 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6745312004D for <>; Sat, 8 Feb 2020 02:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lW7ELWUhkdBz for <>; Sat, 8 Feb 2020 02:36:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E651712004A for <>; Sat, 8 Feb 2020 02:36:11 -0800 (PST)
Received: by with SMTP id z3so1785329wru.3 for <>; Sat, 08 Feb 2020 02:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=peLEEYxF67KS2z/A4f6CTohEHqSpEPf+6UorR02VPjk=; b=im8r3X1iLA3KP1KDxNleLnYnPlA8L0RSIQtMPqqfRCWejOnqK0p47d1LNssvFd7GAn Czqp5CQ3/u5U1QxRjo43UAJor5lxPXnrzejPDFNE5+JQMRvkx0aFpeK83k5R/CXNAGoW /5kNHBXbdG17eiRu6Oc8e4ppWq+YKYKJCUev7KWmpDqjoI9pOg9En6QoK2Vt+FfEsVyM V2QnPD8uq8DnRC8zCQN3FhjVBT5r907nXL6N+KBLF9ioBaQMq5gQDjPIReXdn+qdEi8I 4qPCTfE0murV3O7SflBQ8Gy2qIIQ/y5QqH6pFR5JwhvEP3wjYRkKeR/xBxzp3K8t9NsV iMag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=peLEEYxF67KS2z/A4f6CTohEHqSpEPf+6UorR02VPjk=; b=Zs54X3HCSafp5hjpDvNyOUFE2HU0vd6gJaHWlZcvrONct0/ndeWbydUOzAvpYAtDRw S99ZT3OJ36GOkIB8ywpf3JiS1z8FLIEMpBBk9Rup4+4RH9BbG1bqRIPI2NlTYanzk44+ yoChrznJAhHlCumInZDaPG1AUXObH9oEQLsfYvnBdKMLWsptrD7RfDGZPsXkZoluxb4C ZCQTzqZsaJcF1y70eZNtlF2mYk/kNgGonlfdQhYZDTfIbn5BklOe68ZP5srRwQdfTGkX eq0Ipf4E76q9TTVtU25fUJ7XEotnkNMoEcNbCy5Fip27TgUT/uo7q1q3NZzr4Qe0na6Y L3bg==
X-Gm-Message-State: APjAAAW0CkUm5Fxp4B+cvPzcutCP9fQyzMhkORrIwvJ7mx7UA4sGPE8V GKLj62hp8fmRFIUAE8FgMoMkS1Wf
X-Google-Smtp-Source: APXvYqziQnKR2bLh0MmszwHVJz3V9EEv7LBaGPxhN1kiyXTlUPI99lRbk2ktH8Cc5nnqAVgyzxfofQ==
X-Received: by 2002:a5d:6a02:: with SMTP id m2mr4849125wru.52.1581158169921; Sat, 08 Feb 2020 02:36:09 -0800 (PST)
Received: from ?IPv6:2a01:cb1d:111:eb00:1c6:dd42:ea44:b699? ([2a01:cb1d:111:eb00:1c6:dd42:ea44:b699]) by with ESMTPSA id c9sm6767742wme.41.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Feb 2020 02:36:09 -0800 (PST)
From: "Michael H. Behringer" <>
X-Google-Original-From: "Michael H. Behringer" <>
References: <> <23372.1581026131@dooku> <> <>
Message-ID: <>
Date: Sat, 8 Feb 2020 11:36:09 +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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Anima] Brian/anima: trust notion of ASA communications
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Feb 2020 10:36:15 -0000

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

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.

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


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