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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
