Subject: [Anima] GRASP as a secure session layer

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Nov 2019 09:01:48 +1300

Hi,

While thinking about what we need in an ANIMA ecosystem, and about how
we might marry ANIMA with more traditional techniques like NETCONF/YANG
(as indicated in RFC8368), I remembered one suggestion that I think came
from Toerless: is there a way for an ASA to use a secure "clear channel"
across the ACP? But of course if we do that, many of the features of
GRASP would be lost (discovery, session management).

So here's a possible solution. Allow an ASA to use GRASP discovery etc.
to set up a secure session with another ASA, but then instead of using
GRASP negotiation or synchronization messages, simply take over the session
and use simple send/receive primitives for whatever it wants.

No sooner thought than done. I added one optional parameter to
grasp.req_negotiate() to indicate this mode, and two new functions
grasp.send() and grasp.recv(), and GRASP became a secure session layer.
The code is really too new for me to commit to GitHub, but it's a very
convincing proof of concept.
 
Regards
   Brian Carpenter

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Nov 2019 02:49:39 +0100

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.

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.

Maybe in the generic case of an undefined "secure transport substrate"
below GRASP you give the app the option whether or not to encrypt ?

Maybe i am confused ?

Cheers
    Toerless

On Wed, Nov 13, 2019 at 09:01:48AM +1300, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Nov 2019 16:20:16 +1300

> 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.

> 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). 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()

> 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.

> 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.

Regards
    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Nov 2019 04:40:31 +0100

> 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.

> shared keys.  > All I've done now is add a new option where you use
> (encrypted or not).

Who am i ? ("hands the socket over to you")

> It could work exactly the same if GRASP

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.

> 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.

> I will be arriving Friday evening in SG and will likely hang around the

Yep, lets talk in person. Body will arrive also fri evening. After
17.5 hours flight, not sure about the mind though ;-)

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Nov 2019 17:30:45 +1300

Just responding on one point that is probably crucial:

> The main novel issue we

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?)

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 17 Nov 2019 05:51:44 +0100

> BRSKI gives us identities and surely the possibility of authzn built on

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.

> become universally trusted. I did call it QUick And Dirty Security for

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.

> 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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Nov 2019 21:38:55 +1300

> For a good self-organizing solution, it would be alot better to have

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.
 
> and then dynamically update the service quality parameters.

Yes, lots to be done still.

> 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

Ack
   Brian