On 24.9.2014, at 12.07, Mikael Abrahamsson <[email protected]> wrote: > On Wed, 24 Sep 2014, Markus Stenberg wrote: >> Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well >> with multicast. Certainly, you can use manually keyed (static) IPsec SAs >> (although in case of Linux, out of the box, it does not work either but is >> easy to patch), but they have somewhat worse security properties, main >> things being lack of replay protection and fixed key used for crypto. > How does multicast work at all with replay-protection? I am not a crypto guy, > but is there any way of doing multicast and not have this problem?
Well, effectively per-source replay window _and_ rekeying to make e.g. system restarts not be vulnerable to this. I don’t remember how GSA in msec was specified anymore, but it is not intractable problem (at least in theory). It has been many years since I read msec work though. > 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.) > 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? > > 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? 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. 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. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
