Re: [Anima] GRASP as a secure session layer

Toerless Eckert <tte@cs.fau.de> Thu, 14 November 2019 03:40 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 6484E120103 for <anima@ietfa.amsl.com>; Wed, 13 Nov 2019 19:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0AzaoGXDS2qX for <anima@ietfa.amsl.com>; Wed, 13 Nov 2019 19:40:36 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DB21200B1 for <anima@ietf.org>; Wed, 13 Nov 2019 19:40:36 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4222A548005; Thu, 14 Nov 2019 04:40:31 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320D1440015; Thu, 14 Nov 2019 04:40:31 +0100 (CET)
Date: Thu, 14 Nov 2019 04:40:31 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de>
References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com> <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de> <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2bee821e-cdeb-187f-f5be-f8527313ead0@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/yv6eSPasig1NSdycVd47bJ4Ry7g>
Subject: Re: [Anima] GRASP as a secure session layer
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: Thu, 14 Nov 2019 03:40:40 -0000

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 testclient.py
> and testserver.py at https://github.com/becarpenter/graspy
> 
> 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