Hi! Is there any RFC to reference for forward secrecy for the EAP+AAA framework, which gives recommendations for preventing the attack below?
Many RFCs for EAP methods and AAA contain various recommendations regarding forward secrecy, but I did not find any that gives concrete guidance to prevent the following attack on forward secrecy for the established session key. The attack seems applicable regardless of EAP method used. 1. Adversary records all traffic between EAP server S and pass-through authenticator A even though it is protected by IPsec or TLS. In particular, the adversary records the traffic containing the session key sk that is passed from S to A after successful completion of the EAP run. 2. Session using sk expires and all involved parties delete sk. 3. Adversary now compromises S and obtains its long-term key. If the EAP method provides forward secrecy, this does not help the adversary get to sk. So, there is forward secrecy w.r.t. the long-term key. However, it is not inconceivable that the adversary at the compromise also gets hold of the session keys for IPsec/TLS, at least for some deployments. If IPsec/TLS has not been rekeyed since step 2, then the adversary can use the IPsec/TLS session key to decrypt the traffic recorded in step 1 and obtain sk. That is, the sk is not forward secure in practice on a system level. To protect against the attack, one can for example update the keys for long-termed IPsec/TLS sessions after every EAP handshake, or for TLS maybe even run a new handshake for every EAP run. For a more relaxed version of forward secrecy, one can do key updates at regular intervals. The AKE establishing keys for IPsec/TLS must also be forward secure w.r.t. its long-term keys. I plan to add such recommendations to draft-ietf-emu-aka-pfs, but it seems wrong that such recommendations should be in individual EAP methods RFCs. It seems a better fit for a more general EAP/AAA document that implementors of any EAP method would read. BR Karl _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
