EAP-AKA will not bid up to AKA'

[James Prestwood]

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 at example.com" 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.
>