eap Mailing List: RE: A question about Protected result indications in EAP-AKA.

[henry.haverinen (henry.haverinen]

Hello Hisatoshi,

It is true that there are denial of service attacks
that can be performed against EAP-AKA, and I'm afraid
with any other EAP method. The attacker typically doesn't
need to wait for the end of the exchange, but it will be even 
more productive to spoof packets in the beginning of exchange, 
where methods typically cannot provide EAP packet integrity 
protection. Denial of service attacks are notoriously easy
to mount in wireless networks.

That said, we are currently consider whether we need to improve
the result indications in EAP-SIM and EAP-AKA.

Best regards,
Henry


> -----Original Message-----
> From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com]On Behalf Of
> ext Hisatoshi EGUCHI
> Sent: 21 January, 2004 06:38
> To: EAP WG
> Subject: [eap] A question about Protected result indications 
> in EAP-AKA.
> 
> 
> Deer all,
> 
> I have a question about EAP-AKA [1].
> Does EAP working group solve following problem?
> 
> "EAP-AKA is intended for use over both physically insecure and 
> physically or otherwise secure networks." (10. Security Claims [a])
> EAP [2] (Issue 208) is intended for use over physically 
> insecure networks.
> Use cases of EAP-AKA are different to those of EAP.
> Nevertheless, current EAP-AKA notifies authentication result by 
> unprotected EAP Success/Failure.
> 
> In EAP-AKA, peer receives bogus Success/Failure from attacker. 
> ([1] Section 9.8)
> Then, I am anxious that if attacker sends bogus Failure in case of 
> authentication Success in network, legitimate peer can never 
> get access
> of network.
> It is DoS attack by sending bogus authentication result.
> As a result, any peer cannot get access of network in case of bogus 
> Failure sent by attacker.
> 
> So, I think that current notification of authentication result is 
> contradictory to Security Claim [a].
> Isn't it necessary to update current EAP-AKA to be suitable 
> for Security
> Claim [a]?
> 
> To solve this problem, for example, I think that EAP-AKA should be 
> improve to send integrity-protected Success/Failure like PEAP [3].
> Then, IK can be used to protect Success/Failure in EAP-AKA.
> 
> Thank you for reading.
> 
> References
> [1] J. Arkko, et al., "EAP AKA Authentication," 
> draft-arkko-pppext-eap-aka-11.txt, October 2003.
> [2] L.Blunk, et al., "Extensible Authentication Protocol (EAP)," 
> draft-ietf-eap-rfc2284bis-08.j.txt, November 2003.
> [3] D. Simon, et al., "Protected EAP Protocol (PEAP) Version 2," 
> draft-josefsson-pppext-eap-tls-eap-07.txt, October 2003.
> 
> With Best Regards,
> 
> Hisatoshi EGUCHI 
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>