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
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
