On Mon, 10 Apr 2023 at 19:20, Karl Norrman <karl.norrman= 40ericsson....@dmarc.ietf.org> wrote:
[K]: I have described only one. I also gave a concrete example, which may > have caused confusion. > I will try to describe it again in clearer terms, but shorter. Point 2 > answers the direct question. > > 1. There is an EAP server S and a pass-through authenticator A. For > simplicity, say they are operated > by a single honest organization, which the client trusts. S and A protect > the traffic sent between > them using IPsec. > > 2. An adversary listens to the IPsec encrypted traffic sent between S and > A. The adversary cannot decrypt > the traffic, but records the encrypted traffic anyway. (This is who and > what I meant by having access to the traffic). > > 3. After a successful EAP authentication between a client and S, S will > send the established MSK to A over > the IPsec tunnel. > > 4. The adversary records the (encrypted) MSK. But at this point the > adversary cannot decrypt the MSK. > > 5. The MSK is used to protect a session. The session terminates. If one > cares about PFS, the MSK > and any data from which it can be derived shall be deleted when the > session terminates. Otherwise, > the MSK would not be forward secret. > > 6. If one cares about PFS, then one would worry that the adversary would > hack into the server S, > obtain the IPsec session keys and decrypt the encrypted MSK from step 4. > Wouldn't the solution here be upgrading the MSK users to be PFS enabled? For example, Security Considerations in draft-ietf-emu-aka-pfs says: This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy. For instance, when used with IKEv2 [RFC7296], the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful. As I understand the above, when an EAP method generates an MSK that's used with IKEv2, step 6 above would still reveal the MSK but the MSK is not usable to decrypt traffic that was secured with IKEv2. For Wi-Fi authentication, the handshake between the wireless device and WLAN access point could run the kind of 'further mixing' draft-ietf-emu-aka-pfs mentions? We're now at Wi-Fi 7 and the future versions could incorporate these changes, if they'd be needed for Wi-Fi. I haven't checked if any of the 802.* specifications already define something like this that's already used with wired and wireless LANs. How common are the link layer protocols that use MSK in such a way that forward security is not achieved? -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
