Re: [Anima] GRASP as a secure session layer
Toerless Eckert <tte@cs.fau.de> Sun, 17 November 2019 04:51 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 37DE3120043 for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 20:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 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, URIBL_BLOCKED=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 r2cyy4leK_f9 for <anima@ietfa.amsl.com>; Sat, 16 Nov 2019 20:51:51 -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 0952E120018 for <anima@ietf.org>; Sat, 16 Nov 2019 20:51:50 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B5431548056; Sun, 17 Nov 2019 05:51:44 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B0AB0440055; Sun, 17 Nov 2019 05:51:44 +0100 (CET)
Date: Sun, 17 Nov 2019 05:51:44 +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: <20191117045144.GB56410@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> <20191114034031.GA56410@faui48f.informatik.uni-erlangen.de> <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <74b44d7a-92b8-e51b-8575-658ded0762b9@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Z-aFnxNrh74sGtW9TPMBCTSd03I>
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: Sun, 17 Nov 2019 04:51:54 -0000
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 "example.com has the best 'whatever' product", and (B) the certificate for example.com so that you securely know you are connecting to example.com. 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. > 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. > (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. 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 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 > > -- --- tte@cs.fau.de
- [Anima] GRASP as a secure session layer Brian E Carpenter
- Re: [Anima] GRASP as a secure session layer Toerless Eckert
- Re: [Anima] GRASP as a secure session layer Brian E Carpenter
- Re: [Anima] GRASP as a secure session layer Toerless Eckert
- Re: [Anima] GRASP as a secure session layer Brian E Carpenter
- Re: [Anima] GRASP as a secure session layer Toerless Eckert
- Re: [Anima] GRASP as a secure session layer Brian E Carpenter