Re: [homenet] HNCP security?

[Markus Stenberg <[e-mail]>]

On 25.9.2014, at 14.19, Tero Kivinen <[e-mail]> wrote:
> Markus Stenberg writes:
>>> Is there something else that’ll work as transport layer security
>>> for multicast, or should we send a request for the IETF leadership
>>> to investigate if this is something that needs to be developed? 
>> 
>> There is not that I know of. 
>> 
>> I believe msec work is somewhat outdated (based on IKEv1, and not
>> widely deployed), but security isn’t popular, and multicast isn’t
>> popular, so combining them is not usually win in IETF. (And
>> especially in seeing them implemented - still not sure how many msec
>> implementations there has been.)
> 
> There is also ikev2 version of group key management
> (draft-yeung-g-ikev2), but the draft seems to have expired some time
> ago. I still think it was supposed to be published.

Ah, interesting, did not know about that. Thanks ;)

> If homenet needs multicast support then it might be good idea to push
> that document forward. 

How does this solution work with e.g. link-local-only littleconf-TOFU setup?

To be more precise, I am not sure which node would be GCKS, and how other nodes would find that node. Based on cursory read of the draft, it seems to assume that non-GCKS nodes know GCKS address in advance.

> I do not think replacing the IKEv2 with TLS would help at all. If you
> go for application level protection then using DTLS or similar is
> better than getting ESP involved at all. 

DTLS has rather sad multicast story too (=manually keyed IPsec without IPsec and draft-only at the moment). Of course, whether or not we really have to secure multicast at all in case of HNCP is debatable. However, as a general solution, it is somewhat lacking, as leveraging same thing for e.g. bit more multicast-heavy routing protocols would not work in case of DTLS (then again, I am not sure if GDOI / G-IKEv2 are much better due to them being mostly draft-only vaporware at this point).

Cheers,

-Markus