On 17-Nov-19 17:51, Toerless Eckert wrote:
> 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.
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.
>> 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.
Yes, lots to be done still.
>
>> (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.
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
> 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.
Ack
Brian
>
> 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
>>>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
