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

[Karl Norrman <[e-mail]>]

Hi!

Thanks for the quick reply.

Please see [K] inline.

> -----Original Message-----
> From: Alan DeKok <[e-mail]>
> Sent: Sunday, 9 April 2023 20:56
> To: Karl Norrman <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Emu] System level forward secrecy for EAP+AAA
>
> 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/.
>

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

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

[K]: What I mean with 1 is that the adversary records the encrypted traffic.
The adversary cannot decrypt it at this point in time. It only stores the encrypted data.

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

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

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

[K]: Yes.

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

[K]: Let me give a concrete example. We have server S and pass-through authenticator A,
which is a WiFi access point. They use an IPsec tunnel to protect the traffic between them.
Say the IPsec tunnel is rekeyed every hour. Say there is an EAP session run and an MSK established
between S and a client. S sends the MSK to A over the IPsec tunnel. A and the client use the MSK
to secure the WiFi air-link. The air-link protection session terminates after 1 minute. At this point,
everything needed to derive the MSK shall be deleted.

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.

The attack here is against the PFS property of the MSK. Once the WiFi air-link session using MSK
is terminated, it should not be possible to retrieve the MSK if it is forward secure. Here it seems to be possible
to obtain MSK after the WiFi session has terminated even if the EAP methods have PFS and AAA is protected
with TLS/IPsec using a PFS handshake.

Note that it doesn't help that IKE has PFS as long as the IPsec session state remains
in S and A for 59 more minutes.  Neither does it seem to help that the EAP method has PFS, since the
MSK is sent over the AAA protocol and gets "stored" in the channel.

The only thing that seems to help is to rekey the IPsec connection and delete the previous key material.

BR Karl

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