Re: [Emu] System level forward secrecy for EAP+AAA

[Alan DeKok <[e-mail]>]

On Apr 9, 2023, at 2:06 PM, Karl Norrman <karl.norrman=[e-mail]> wrote:
> 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.

  If the AAA transport isn't secured, then anyone can observe EAP traffic, or the location, "obfuscated" passwords, etc.  The attacks are described in some detail in https://datatracker.ietf.org/doc/draft-dekok-radext-deprecating-radius/.

  If the AAA traffic is protected by IPSec or TLS (as is commonly done), then the EAP traffic can only be observed by (a) radio-level sniffing of supplicant to AP traffic, or (b) trusted parties in the AAA framework.

  The one remaining attack is if the AAA systems use TLS without a method providing PFS.  In which case anyone capable of recording all of the traffic on the net can do so, and then crack the session keys at their leisure.

> 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.

  i.e. if TLS doesn't use PFS, and EAP methods don't use PFS, then sessions can be compromised.

> To protect against the attack, one can for example update the keys for long-termed IPsec/TLS sessions after every EAP handshake,

  Is that for AAA sessions?

  I'd agree that EAP methods should provide PFS.  TLS does this for TLS-based EAP methods via RFC7525, etc.

  My confusion is that EAP doesn't use IPSec.  Connections between AAA systems might use IPSec or TLS, but those connections are 100% independent of the data which they transport.  AAA servers will not change the status of inter-AAA connections based on snooping the contents of AAA traffic.

>  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.

  I'm trying to understand the attack here.  I'm not sure how EAP has anything to do with IPSec or AAA transport.  EAP doesn't use IPSec, and AAA transports aren't affected by EAP.

  What I understand as as the problem is:

a) people snooping supplicant -> AP traffic can attack an EAP session

b) AAA systems can snoop all EAP traffic that they forward

  this is pretty much by design, as AAA does not provide for end-to-end security.

c) AAA systems not using PFS are vulnerable to an attacker who can snoop the traffic, and crack it at their leisure.

  TLS/IPSec makes this a bit harder against an attacker with few resources.  UDP/TCP transport is not recommended when AAA traffic sent across insecure networks.

  Alan DeKok.