Yeah, I think the ordering was my problem. It was finding AKA in the
method list first and stopping the search.
Thanks
On 09/25/2017 11:02 AM, Jouni Malinen wrote:
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.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
