Sending EAP Identity Encrypted

Jouni Malinen j at
Thu Sep 22 14:33:34 PDT 2016

On Thu, Sep 22, 2016 at 02:22:36PM -0700, alan furlong wrote:
> An attacker could request permanent ID with AT_PERMANENT_ID_REQ. Maybe
> we could configure wpa_supplicant to be conservative to defend in such
> scenario, but that also means if auth server loses the pseudonym then
> peer will fail to connect with legitimate server too.

I did consider doing that, but the possibility of getting completely
stuck without any clear way of noticing why and then trying to get the
user to clean this up did not seem very appealing.. Anyway, if there is
a use case where this is desired behavior, I'm open to adding a
configuration parameter to force such behavior.

> So maybe encryption needs to happen in the AT_IDENTITY attribute
> present in the EAP-Response/SIM/Start message (EAP-SIM) and in the
> EAP-Response/AKA-Identity message (EAP-AKA). Also because of size
> limitation in RADIUS attribute "User-Name", it may not be possible to
> do RSA encryption of EAP Identity in EAP-Response/Identity packet.

This is again in the category of having to modify protocol definition
for something that has been already deployed.. Feel free to try to bring
this up in 3GPP and IETF. I don't see much of a point in modifying
anything in wpa_supplicant for this before there is consensus between
sufficient number of entities deploying EAP-SIM and EAP-AKA.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list