Re: [Anima] GRASP as a secure session layer

Brian E Carpenter <> Thu, 14 November 2019 04:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3243120090 for <>; Wed, 13 Nov 2019 20:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 W3NKvmabgJVR for <>; Wed, 13 Nov 2019 20:30:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E5EF12006B for <>; Wed, 13 Nov 2019 20:30:52 -0800 (PST)
Received: by with SMTP id z24so2864205pgu.4 for <>; Wed, 13 Nov 2019 20:30:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=phPtYc/ccqScv6SVej2yW8dCPCghhX7FSTbUqTXUyWY=; b=drJEdWVUwdWVaLr3Uxs9oAkI11H7wYKYN5pgNg4LI3BBPFn3nNHBbmJTWAhz+A1Etb a9k+DXXsw2fMaF44sEUZfK5hW1ZznmPYhCuluyZLIAn3Wl4NA/CTaI+vx2rzYVklT1/K qQ9IH0tuWakmxr3NcrBXZfhDIR5kukQQdbKvvk2/+UxzGQLqHoA/i+hJ10o2yVM3krl6 iaGrln/r8JgKHK8OIIeSGKec24bn1JtJBhNGa5xOQbY4IxlyDTBSn7lfraHY/JdCpalk GOpJ1OXiFh9OYC2rngrJwDln+esQiURAm2XBJBgWkUaKbgkErdCNyb2jk7OCkZC5VIES Hf7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=phPtYc/ccqScv6SVej2yW8dCPCghhX7FSTbUqTXUyWY=; b=rJk/PnOB5qlCkZ49TY4UUXF310hobUffc/rLIrphz6HWIbaWHLaZLn8CDyw+DLEelU QIUCjdKmrygy7epLrS/zNTRPBB8sCD2g1Y3EAwjJIxtbg3UwRQ8EbQthGW9iA1sOeqn6 aAqs9JxBAThQWsfPvtvAtaZmblV7zokOF5g4LEq8DXcXdVqeXPRI+rVeY88UuXiTgJoV mjI+IppYCAshyXMeTpudhP+NHtjU2jkidFLGOr7hZ/ytAvQ6i/azDKVL0wQzNuxBstYr Yb6WUMlPd07ZL/xv2ZRMRs4udB3/jRlu39mYvYyGjTU63yaxrpuTjetlrMaLIaLXUsEC XjOQ==
X-Gm-Message-State: APjAAAVu9JPw20KTb5Td712aDn9kWEYU1RJElXC+9BMV4Y9NMZ8gu/nv JUseWVacBF5aY4/lbeLRgu6hlChN
X-Google-Smtp-Source: APXvYqwfQWWj9DKATZdte3DSkodv/8uDM80iUCNejrTvsRvUW71fs2+Sad9grp8RbXKmJcePub0r8w==
X-Received: by 2002:a63:f94e:: with SMTP id q14mr3000696pgk.411.1573705850346; Wed, 13 Nov 2019 20:30:50 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id n21sm3974920pjq.13.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 20:30:49 -0800 (PST)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 14 Nov 2019 17:30:45 +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: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] GRASP as a secure session layer
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: Thu, 14 Nov 2019 04:30:55 -0000

Just responding on one point that is probably crucial:

> The main novel issue we
> have in ACP is that we have no well-known unique identifies of peers.

Absolutely, and we left authorization out of scope until now. But
BRSKI gives us identities and surely the possibility of authzn built on
those identities?

Again - it depends on the threat model. My toy security uses AES and RSA
and all that good stuff, but if someone presents the right password they
become universally trusted. I did call it QUick And Dirty Security for
a reason.

(As for PFS, I don't see how that works for unsolicited multicasts.
Clearly once you start a new session, you could regenerate keys. But
for multicasts I think a shared key is unavoidable, isn't it?)


On 14-Nov-19 16:40, Toerless Eckert wrote:
> On Thu, Nov 14, 2019 at 04:20:16PM +1300, Brian E Carpenter wrote:
>> On 14-Nov-19 14:49, Toerless Eckert wrote:
>>> So.. in the ACP document, the hop-by-hop GRASP connections across
>>> the ACP are using TCP because there is no added benefit of TLS
>>> given how the connection is to a direct neighbor to which the
>>> ACP already uses the secure channel encryption (e.g.: IPsec).
>>> End-to-end GRASP connections across the ACP are expected to use TLS.
>> Assuming we are worried about MITM attacks by other nodes enrolled
>> in the ACP, yes. But if that isn't part of the threat model, TLS
>> isn't really needed there.
> Actually that was what trickled through during IESG security review.
> Without the end-to-end encryption one could argue that the the simple
> "trust every node in the ACP equally" would not really be a sufficient
> basis for GRASP apps to exchange all type of probably mutually
> confidential app-data. Hence the move of end-to-end GRASP connections
> across ACP to TLS.
>>> So, i would argue that the peer-to-peer communication of GRASP
>>> across ACP is a secure session layer. Just the discovery by
>>> its nature requires to trust the third party mitigating the
>>> discovery. Because we're doing hop-by-hop forwarding this means
>>> discovey needs to trust the intermediate GRASP ACP nodes. If we had
>>> a client-server model, (e.g.: unicsat DNS servers), we'd have to
>>> trust those servers.
>>> So i am not quite sure what you suggested to change.
>> Remember that I started this 3 weeks ago because I got bored
>> waiting for the real ACP. Running code, right? My first step was
>> to add shared-key encryption to *all* GRASP packets. My second
>> step was to use a Diffie-Hellman exchange to safely spread those
>> shared keys.  > All I've done now is add a new option where you use
>> GRASP discovery to find a server and a GRASP request message to
>> start a session. In effect, GRASP hands the socket over to you
>> (encrypted or not).
> Who am i ? ("hands the socket over to you")
>> It could work exactly the same if GRASP
>> was using TLS sockets. I'm sure you suggested something like that
>> a couple of years ago. 
>> Server: wait for GRASP M_REQ_NEG
>>         do forever:
>>             grasp.grecv()
>>             grasp.gsend()
>> Client: discover peer (GRASP M_DISCOVERY etc)
>>         send GRASP M_REQ_NEG
>>         do forever:
>>             grasp.gsend()
>>             grasp.grecv()
> Sounds like being on the way to some form of lightweight security
> substrate instead of ACP.
> What you should try to achieve is to go from the shared secrets to PFS
> for the encrypted P2P connection. DH seems like the usual tool here
> but i am not sure i understand the complete mechanism you implemented.
>>> Maybe in the generic case of an undefined "secure transport substrate"
>>> below GRASP you give the app the option whether or not to encrypt ?
>> I'm not suggesting that we should formally add encryption to GRASP. It's
>> not a game for amateurs. Remember that the main issue we have is insecure
>> multicast, which is why GRASP is defined only to use LL multicast. If DTLS
>> supported multicast, things could be different, But yes, we could choose to
>> handle this explicitly - it's really an implementation and API issue.
> In my previous email i tried to explain how this is not an issue
> of insecure multicast but the fundamental fact that you need to trust
> a discovery mechanism as a third-party anyhow. The main novel issue we
> have in ACP is that we have no well-known unique identifies of peers.
> Aka: i don't think trying to encrypt discovery would add more security.
>>> Maybe i am confused ?
>> Maybe my explanations are confused. You can see examples
>> and at
>> I will be arriving Friday evening in SG and will likely hang around the
>> hackathon.
> Yep, lets talk in person. Body will arrive also fri evening. After
> 17.5 hours flight, not sure about the mind though ;-)
> Cheers
>     Toerless
>> Regards
>>     Brian