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 <[email protected]> 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 >
