Re: [Anima] GRASP as a secure session layer

Brian E Carpenter <> Sun, 17 November 2019 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 559341200DF for <>; Sun, 17 Nov 2019 00:39:00 -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 pVv3yo0XuGq8 for <>; Sun, 17 Nov 2019 00:38:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 439931200D5 for <>; Sun, 17 Nov 2019 00:38:58 -0800 (PST)
Received: by with SMTP id o9so7799463plk.6 for <>; Sun, 17 Nov 2019 00:38:58 -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=I0UG2jjTLTKU3s2wMdbpOR3buqQl2oVWDGnMTJo6AQw=; b=trDcEuzrWIN0Vx3HqC+NdM0G5/Q5DRQt/MWYkqJyWvWTolSAfuOo+HxrcJrELtRJHN ur2Y8iTRT8BeZwOAMOL3GPY0YRenNqlvJXaWRn6SBL13lPyrvb/RrwNm/lCiu4HtoQBT B9PljZqaHqh4oZEe6ckb3lf1bB/Zu/98ikiL62NuCiGwKnoQEeiklc1dVrbmB0AmLhw5 YvhEVOQJQ9n5Wi/pnnWuXHqKT3+dirh1IAdnafB8tHWg2ypgevsj3HoEnrRfesGi4J8m kOI15Ykdox6gDQb8gcyqOVETXWIzlkoK0iHpXGyLSf5OtfesGZEbl1AshQCzSBjKYnHM vm0g==
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=I0UG2jjTLTKU3s2wMdbpOR3buqQl2oVWDGnMTJo6AQw=; b=BD1iKpLpJmPPfXG2d/pfozs2QPv6by9u/eDydzWoVtjPYNZwWzC4Speb4aI7fVi/WK LfeQRBacPEL23FO6XjwKqFVyewVaH8IvRpbNU/XMyZIpJsu9Y+yATRXaDgSAwlXDOouB Yv8woU8wfPgS+y37tPgzSPS/6U2xa3CdDPaGF6H/UCYJYxMDv2fUeEZ5+CUV/jqeI66C Ua6kvY1T+afsirtPEytTRp6+XKHwTudx2XHYdLy5FdzEFs2y138KLF/QFZ1jd2zROXXo OmXRWeFFusC/rr4v2m9ax/0qBElzz/wDHIO2PFdqZqiiFnvki/4zmgovhCHWFTrpD7Q4 cTJA==
X-Gm-Message-State: APjAAAX+m6DtkUB29fJeq90NFUNj6xQyCl21oliGWvxtUYibm6EDhur4 qU7p7riEflJEMChcCInbZ5mtibFj
X-Google-Smtp-Source: APXvYqxaYhYsRGQmSoJxWKQsC5kwBqxqPqT6HcSY+y9Nx6R/PPxeZt+Tn3Cak7AL0oPSGPQOD/sVDA==
X-Received: by 2002:a17:90a:348c:: with SMTP id p12mr31364121pjb.105.1573979937157; Sun, 17 Nov 2019 00:38:57 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id n18sm15076124pff.152.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 00:38:56 -0800 (PST)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 17 Nov 2019 21:38:55 +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: Sun, 17 Nov 2019 08:39:00 -0000

On 17-Nov-19 17:51, Toerless Eckert wrote:
> On Thu, Nov 14, 2019 at 05:30:45PM +1300, Brian E Carpenter wrote:
>> 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?
> Yes, it does, except we are missing the "well-known" part that we
> have in the Internet through a combination of (A) knowledge
> " has the best 'whatever' product", and (B) the certificate
>  for so that you securely know you are connecting to
> IMHO, in a fully autonomic network, the problem is not (B), but (A).
> (B) can easily be an ACP (ANI/BRSKI) certificate. The problem is (A):
> How do you know from multiple GRASP offers which one to trust "most".
> Right now we have the model that all nodes are equally trustworthy.
> For a good self-organizing solution, it would be alot better to have
> mechanisms beyond this.

Agreed. We should perhaps look at MUDs for this. I'm biased because I
spent the hackathon writing code for a "thing" to send its MUD URL
via GRASP to a MUD Manager, which can then fetch and validate the 
signed MUD file for the "thing" and authorize it accordingly.
>> 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.
> I don't think this is only a security issue. I think more about a
> service quality vetting problem. In my DNS-SD -> GRASP drafts, i am
> just mapping service quality parameter as we did in DNS-SD, but that
> model implies tht there is a magic external entity that can assign
> consistent service quality parameters aross multiple instances. Like
> the magic operator or SDN controller. We do not have self-organization
> of this based on e.g.: control loops that measure the service experience
> and then dynamically update the service quality parameters.

Yes, lots to be done still.

>> (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?)
> The discovery is only has domain-membership-group-security.

Right. But in GRASP there are only two things that you can learn
from multicasts: Node A is looking for a node that supports
Objective X, or Node B is flooding the value of objective Y to
everybody (which is the purpose of flooding). A group security
model seems reasonable for that.

> But once
> you build a p2p connection, your security association mechanism should
> ensure PFS. Which means that as soon as you start talking to a
> particular peer you will be sure you will continue to talkk only to that
> peer and can not be interepted by another peer. Most TLS options
> offer PFS. I am just not 100% sure right now if any simple DH step
> already is sufficient for PFS.

> Cheers
>     Toerless
>> Regards
>>    Brian
>> 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