[strongSwan] EAP-AKA failure: AKA_SYNCHRONIZATION_FAILURE

[Tomasz Osiński]

Hi Tobias,

Finally, I was able to find the root cause. There is a bug in the
eap-aka-3gpp plugin implementation regarding updating of SQN. Currently,
strongswan increments the SQN number, which it receives from UE. However,
based on [1] the SQN (32 bits) is composed of two elements: SEQ + IND. SEQ
is the actual sequence indicator, while IND is some kind of the index and
normally it occupies 5 bits. Thus, SQN should be updated with the value of
SQN + 32 (32 = 2 ^ sizeof(IND)). The nice visualisation of this process is
shown in [2].

Once I have modified the eap-aka-3gpp code it works perfectly with
commercial Samsung UE.

If you are interested I can prepare a fix for eap-aka-3gpp.

[1] 3GPP TS. 33.102
[2]
https://diameter-protocol.blogspot.com/2013/06/umts-3g-utran-authentication-procedure.html

śr., 24 kwi 2019 o 18:29 Tobias Brunner <tobias at strongswan.org> napisał(a):

> Hi Tomek,
>
> > Thanks for your answer. The phone indicates the invalid value of SQN,
> > see the logs below:
>
> Check the implementation of resync() in your implementation of
> simaka_card_t (and whatever it actually calls/does) for details on this.
>  That it initially fails could be due to how the SQNs are generated.
>
> > Do you think
> > that the EPDG (strongswan) have been resynchronized?
>
> Initially probably not if the SQNs are generated differently.  But after
> the client sent its SQN and the server used that (+1) the client should
> be happy with it.  If not, something might be wrong (e.g. incorrect
> secrets).
>
> > And because of
> > time-based SQN generation it generates the invalid SQN?
>
> You have to check the client implementation for what it considers
> invalid.  In particular after it sent the SQN and then still does not
> like what it gets back.
>
> Regard,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190521/6836e2eb/attachment.html>