On Wed, Sep 13, 2017 at 11:30:38AM -0700, James Prestwood wrote: > I was testing out EAP-AKA/AKA' server and found that if the eap_user file > defined an identity which used both AKA and AKA' e.g. > > "abc@xxxxxxxxxxx" AKA,AKA' Please note that this configuration tells the server to prefer EAP-AKA over EAP-AKA' which is unlikely what you really want here. The normal way to configure this would be to use AKA',AKA instead to give preference to EAP-AKA'. > the server will never bid up to use AKA' with the AT_BIDDING attribute. I > traced it down to src/eap_server_aka.c in the function > eap_aka_build_challenge(). Near the bottom in the while loop it checks all > available methods to see if AKA' is supported. The problem is that there is > a check for EAP_TYPE_AKA, and if found it breaks out of the loop. This means > that the aka_prime_preferred flag will never get set if AKA is found (and it > will always be found since we are using AKA). This whole loop is surrounded > with a check for EAP_TYPE_AKA, so I don't quite understand why the while > loop has the check anyways; it should only be looking for AKA'. Removing > this check for EAP_TYPE_AKA fixes the problem, and the server correctly > sends the AT_BIDDING attribute. > > Was there a reason this check was done? If not could it be removed? (I can > send a patch if so). Yes, the bidding flag D is documented to be set to 1 "if the sender supports EAP-AKA', is willing to use it, and prefers it over EAP-AKA". The first two conditions are met here, but the last one is not. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
