On Feb 8, 2022, at 4:49 PM, Shane Guan via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Hello,

We are currently using freeradius v4.0.0 on the nested_coding branch to test our peer with the eap-aka method. We noticed a discrepancy in our understanding of the behavior of the AuC and what freeradius does. In TS 133 102 - V8.1.0 - Universal Mobile Telecommunications System (UMTS); LTE; 3G security; Security architecture (3GPP TS 33.102 version 8.1.0 Release 8) (etsi.org)<https://www.etsi.org/deliver/etsi_ts/133100_133199/133102/08.01.00_60/ts_133102v080100p.pdf> sections C.1.1.2, C.1.2, and C.3 imply that the sequence number generated by the AuC should have the least significant bits reserved for an index value IND, while the others are for the SEQ. While it doesn't specify how many bits are reserved for the IND, section C.3 suggests that 5 is a common number. However, freeradius doesn't seem to use any bits for the index, as the default SQN it uses if none is provided is 0x2. Is this desired behavior for freeradius?

FreeRADIUS doesn't generate an SQN, it's up to the administrator to create an appropriate policy to generate them: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... FreeRADIUS was never intended to act as an AuC, it's missing a lot more than SQN generation code if that's what you're intending to use it for. The triplet/quintuplet generation code is only there to facilitate quick and dirty tests nothing more. In a production environment you'd use the rlm_rest module or rlm_sigtran module to retrieve vectors from an external HLR/AuC, providing an appropriate number of vectors in the `send Challenge-Request {}` section. The SQN defaults to 2 because that's the lowest value that works correctly with eapol_test which is the test client I was using as I was writing the code. As you say, the number of index bits isn't specified, and as this value is only used for testing I don't really see a reason to change it. -Arran