On Apr 9, 2023, at 3:51 PM, Karl Norrman <karl.norr...@ericsson.com> wrote: > [K]: Correct. The assumption in 1 is that the traffic is protected with IPsec > or TLS. > Thanks for the reference. I read it, but it does not seem to consider the > forward secrecy > aspects I try to describe here.
I can add some text about PFS to the document. From a practical point of view, I think PFS issues are less of a problem than other issues. > [K]: There is another attack even if TLS uses a PFS (the one I describe here), > which works if one does not establish a new TLS connection or does a key > update after > each EAP run. Similarly for IPsec. Systems like Eduroam currently transport 2-5K full EAP sessions per second for national proxies, with 10+ packets per session. OpenRoaming systems have similar or larger amounts of traffic. Which means that it is not realistically practical to re-key the AAA connection after every successful EAP authentication. Even re-keying the AAA connections once a second is a lot to ask. > However, because the IPsec tunnel is only rekeyed after 59 more minutes, the > MSK will > not be forward secret. The adversary compromising S could get the IPsec keys, > and > decrypt the stored IPsec packets that contain the message transporting the > MSK from S to A. > That is, the channel between S and A is a form of storage for the MSK which > remains even after it > should be deleted. So what can be done here? What solutions should be implemented which are practical, and which also increase security? > The only thing that seems to help is to rekey the IPsec connection and delete > the previous key material. I think this issue is more theoretical than practical. If someone can snoop random AAA traffic, then either (a) they are a trusted member of the AAA ecosystem, or (b) they have nation-state level access to network traffic. There are few practical defences against either of those attacks. For me, this issue falls into the same area as "my front door lock is insecure, because the lock-picking lawyer can pick it in 30 seconds". Well, $2000 for a perfect front door lock is impractical, because the determined adversary will simply throw a rock through a side window, and bypass the lock entirely. To put it another way, the theoretical attacks are much less interesting than the practical attacks. And the defences against theoretical attacks are not interesting if the defences are entirely impractical. What solutions can be implemented here? What recommendations can we make which are both practical, and secure? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
