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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 07 February 2020 03:42 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 336E712011D for <anima@ietfa.amsl.com>; Thu, 6 Feb 2020 19:42:20 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-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 MO4NaApstHyh for <anima@ietfa.amsl.com>; Thu, 6 Feb 2020 19:42:18 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 488D812001B for <anima@ietf.org>; Thu, 6 Feb 2020 19:42:18 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id dw13so335570pjb.4 for <anima@ietf.org>; Thu, 06 Feb 2020 19:42:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=c8EWojBs5lWBIQIZIK6fC7995Ent0pK5V0XclWeNkBFxsgB5tPYCn1Evathwo9hrAH QJppiZnrOXcRa3fuYdilH07p7cTV9ScLgNitrZjJ/6wlVAr7BxpBlyv6lr3vaSLw99WT fSy53TDszcPjs/lzM50TMloNxMwLkAKTuHOIE4zSCVu83sLCxPhgo1p/pku4dwYDp0uP 8Oc4+4YBiTtyA2HKbq+z6JpVTi3A1/NAx6XDkbn0m3pO1IP0TCunagq09SRnJ/P91Exa 9+/JhVZdjVgJpRn2HWTY/WLkcVKy4RYGeVX59tp88IvjeqpD/t2lzUdHYFTKklBSXpaD tzSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=GScXG+nKsTB6YC5p8dN5EGfLfZ4Ki2qbaqJsYkkFFW7uLsUykyMCB2dSrbYItU6m9L qEd1w7C3PmZcIDhJlLKVRQHldA8g/y7QGd1xSnF959riPWO1LzuATlD+Oxb1j4mh8loG 6SicK8RIMZKORqVUoR085ag1dMF9U96yYBSyrBd7dvvL7hIenbJY29R49Fa8BCeE5eTO 0+R3jKxCWA7lyTghvGgL5ScvEBqv9swQdzPe/12Rt6w5YffXsllk7NxnmKKOPYO2kwvn Bi/hCtLzsfAkteigOHHGR3Bh0aLr6nz0ejbcfVMz4yZazWri6/CGAA33eg2jfCujXIro QeiQ==
X-Gm-Message-State: APjAAAUqr59OGJyv3v4dSmDpcV1eB9bsnL096TRSH1/8OA4le+VI+M6p XkyJRdVjANF4fl+RBAY2SqvbR1ii
X-Google-Smtp-Source: APXvYqxWuUbNcIhpXgaEFX2+Nl+EhLRFkW8SH0fyCcszdDFoTIBbtTsDAOOtIWcLmUDaGaIezwFcpA==
X-Received: by 2002:a17:90a:ac18:: with SMTP id o24mr1414873pjq.33.1581046937431; Thu, 06 Feb 2020 19:42:17 -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 b3sm846450pfr.88.2020.02.06.19.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 19:42:16 -0800 (PST)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>
Cc: anima@ietf.org
References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de> <23372.1581026131@dooku>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <3777ab26-2a73-2cf6-75ea-7573681b64b7@gmail.com>
Date: Fri, 7 Feb 2020 16:42:13 +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: <23372.1581026131@dooku>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/KXrMzpyFjLTYRruA4YZsITTR8qU>
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: Fri, 07 Feb 2020 03:42:20 -0000

Yes, this is certainly a gap, and it's why I put register_asa and register_objective in the API, thinking that when we add some kind of trust/authorize magic dust, this would be created when registering the ASA to (a) run and (b) manage certain GRASP objectives. I feel quite far from having a complete model in my head though. I guess we should start with understanding what threats we are protecting against.

Regards
   Brian Carpenter

On 07-Feb-20 10:55, Michael Richardson wrote:
> 
> Toerless Eckert <tte@cs.fau.de> wrote:
>     > I just got reminded through ongoing ACP spec review about something that
>     > would be good to write into the appropriate ASA spec, but not sure which
>     > one:
> 
>     > One of the fundamental problems we have to solve longer term is how we
>     > can establish better than "Any ANI peer is equally trusted" notion.
> 
> I agree.
> But, at this point, all the ANI peers are equal.
> 
> None do anything special yet... Once we have protocol(s) that can do
> something different, then we need to figure out what the requirements for
> that protocol.
> 
> Putting the trusted-to-do-foo bit into the certificate is probably unwise.
> 
> It seems that in an autonomic network that there ought to be a service that
> can be used to ask, "should I trust node FOO to do X?".
> That could be the (cmc)RA or another node so designated.
> It seems that GRASP can pretty much do all of this.
> 
> COSE can be used to sign answers.
> That is probably a thing we need to add.
> 
>     > I think DINRG is working in this direction, but have failed to track.
>     > Maybe there is a way to collaborate on this, aka: see if/when they might
>     > have output we could think to adopt/leverae.
> 
> I don't know what they are doing either.
> 
>     > Right now we expect objective announcements from any node to be equally
>     > trustworthy and decide on selecting one only on announced parameters
>     > (also subject to equal trust) and network parameter comparison.
>     > And of course, this goes beyond trust into performance vetting by
>     > others and so on.
> 
> At some level, if you are looking for resource X, and some node can provide
> X, and it works and does what you need... then maybe it is reasonable to
> trust it.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>