Re: [homenet] HNCP security?

[Tero Kivinen <[e-mail]>]

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.

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


> > I just can't help seeing this problem popping up all over the
> > place and everybody solving it by writing their own code and doing
> > their own implementation. IPSEC isn't widely used because it
> > doesn't have ports so it can't be NATed (so its now run over UDP
> > to workaround that problem) and also because key management is
> > hard because keys are managed by the operating system and not by
> > the application?

NATs should not be problem here in the homenet, I would assume all
this runs inside the home, and the boxes in homenet are not going to
do nat for ipv6 addresses... 

> > So, do we need a mix between IPSEC and TLS that can be done on a
> > per-application level, but it’s still a generic framework so that
> > someone can develop generic code that projects like HNCP can use,
> > for instance by linking to libraries?

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. 

> TLS + (pure) multicast is more or less impossible. You could
> probably define pure-multicast key negotiation scheme too using
> multi-party D-H (for example), but I am not sure if there is any
> standard protocols for that. Still, it would not look like TLS so
> calling it e.g. MTLS would be somewhat misleading. You could use
> some packet encoding features, but that would be that.

If secure multicast is needed, I think going for the g-ikev2 and ESP
would most likely be best way. The g-ikev2 specification is as far as
I can see ready, so it should be something that can be published quite
soon. It will run over separate port from normal IKEv2, so it can be
deployed quite easily (meaning it does not mess up existing IPsec in
the box), and as msec was not really very widely deployed the changes
that the box already has exsiting msec implementation running on that
port, is small.

> I guess you could do some sort of msec GDOI-like solution for it too
> - perform unicast exchanges using something like DTLS encoding of
> TLS handshakes to agree on multicast encryption key to be used on
> DTLS-ish ESP-ish UDP multicast traffic with per-source replay
> windows.  

If I remember right g-ikev2 supports multiple group key management
protocols and allows download keys from the group controller / key
server (GCKS) using IKEv2 to the devices. 
-- 
[e-mail]