Re: [Anima] GRASP as a secure session layer

[Brian E Carpenter <[e-mail]>]

Just responding on one point that is probably crucial:

> The main novel issue we
> have in ACP is that we have no well-known unique identifies of peers.

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

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
>