Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

I can reproduce the error with a sysmoUSIM set to 2G=COMP128v3 3G=MILENAGE, and both 2G and 3G data available from the HLR db.

I observe two errors:

1. We send a UMTS AUTN challenge in the authentication request, even though 2G is set to COMP128v3.
   Nevertheless, the UMTS AKA succeeds, i.e. the SIM responds with a valid extended RES.
2. During the BSSMAP Cipher Mode Command that follows, according to wireshark, we are sending only A5/7 as permitted, while the MSC (as well as BSC) config has 'encryption a5 3' configured.

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    316 25.032538428   158    185                               187                                    BSSAP                                             SACK DT1 (DTAP) (MM) Authentication Request 

Frame 316: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Request
    Protocol Discriminator: Mobility Management messages (5)
        .... 0101 = Protocol discriminator: Mobility Management messages (0x5)
        0000 .... = Skip Indicator: No indication of selected PLMN (0)
    00.. .... = Sequence number: 0
    ..01 0010 = DTAP Mobility Management Message Type: Authentication Request (0x12)
    0000 .... = Spare bit(s): 0
    Ciphering Key Sequence Number
        .... 0... = Spare bit(s): 0
        .... .000 = Ciphering Key Sequence Number: 0
    Authentication Parameter RAND - UMTS challenge or GSM challenge
        RAND value: 06cf2ddd6a55e98693e55fd01f90cb6f
    Authentication Parameter AUTN (UMTS and EPS authentication challenge)
        Element ID: 0x20
        Length: 16
        AUTN value: d18b74d5ae0e00004686a93e9bcb9687
            SQN xor AK: d18b74d5ae0e
            AMF: 0000
            MAC: 4686a93e9bcb9687

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    333 25.965076597   118    187                               185                                    BSSAP                                             DT1 (DTAP) (MM) Authentication Response 

Frame 333: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Response
    Protocol Discriminator: Mobility Management messages (5)
        .... 0101 = Protocol discriminator: Mobility Management messages (0x5)
        0000 .... = Skip Indicator: No indication of selected PLMN (0)
    10.. .... = Sequence number: 2
    ..01 0100 = DTAP Mobility Management Message Type: Authentication Response (0x14)
    Authentication Response Parameter
        SRES value: 95c27877
    Authentication Response Parameter (extension) (UMTS authentication challenge only)
        Element ID: 0x21
        Length: 4
        XRES value: 98c48e56

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    335 25.966740569   134    185                               187                                    BSSAP                                             SACK DT1 (BSSMAP) Cipher Mode Command 

Frame 335: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Command
    Message Type Cipher Mode Command
    Encryption Information
        Element ID: 0x0a
        Length: 9
        1... .... = GSM A5/7: Permitted
        .0.. .... = GSM A5/6: Not permitted
        ..0. .... = GSM A5/5: Not permitted
        ...0 .... = GSM A5/4: Not permitted
        .... 0... = GSM A5/3: Not permitted
        .... .0.. = GSM A5/2: Not permitted
        .... ..0. = GSM A5/1: Not permitted
        .... ...0 = No encryption: Not permitted
        Key: 818709baba205891

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    337 25.967697395   122    187                               185                                    BSSAP                                             SACK DT1 (BSSMAP) Cipher Mode Reject 

Frame 337: 122 bytes on wire (976 bits), 122 bytes captured (976 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Reject
    Message Type Cipher Mode Reject
    Missing Mandatory element (0x04) Cause, rest of dissection is suspect
        [Expert Info (Warning/Protocol): Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
            [Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
            [Severity level: Warning]
            [Group: Protocol]
    Extraneous Data, dissector bug or later version spec(report to wireshark.org)
        [Expert Info (Note/Protocol): Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
            [Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
            [Severity level: Note]
            [Group: Protocol]

https://gerrit.osmocom.org/5376 fixes passing the proper encryption algorithm on from MSC to BSC.
https://gerrit.osmocom.org/5380 fixes passing encryption algorithms other than A5/1 on from BSC to BTS.

The remaining issue is that in the presence of both 2G and 3G tokens in the HLR db, we do UMTS AKA but send a GSM AKA Kc.

This happens because the MSC doesn't really know what algorithms have been set in the HLR db. All that the MSC sees is the presence of UMTS AKA tokens in the auth vector.

There will always be GSM AKA tokens in the vector as well: either because explicit GSM tokens are set in the HLR DB, or because the GSM tokens were derived from the 3G tokens. The 3G derived tokens and the 2G tokens take the same place in the auth vector, only one of the two will be provided, without an indication which ones they are.

So, if the MS indicates it is R99 capable on an R99 GERAN, and if there are 3G tokens available in the auth vector, we always send a UMTS challenge complete with AUTN. The response we receive is allowed to be just a GSM SRES, which the MS may decide to send when on a GERAN. But practically, what I see is, that, despite COMP128v3 set on the USIM as 2G algo, the USIM actually responds with a full UMTS AKA RES+XRES matching the 3G tokens. That works out and auth succeeds.

Next up is ciphering. On a GERAN, we always use the Kc from the auth tuple for the Ciphering Mode Command. Since the auth token received from the HLR contains a 2G Kc calculated separately from the 3G tokens, the Kc now mismatches the UMTS AKA that took place earlier. IOW, since COMP128v3 is set for that subscriber in the HLR db, that Kc has not been derived from the 3G data we used for authn, but it has been calculated from the GSM KI and uses COMP123v3. We naturally never receive a Ciphering Mode Response and reject in timeout.

How to solve this? Things that come to mind...

• Q: the sysmo-usim-tool names the USIM settings to set auth algos "2G" and "3G". Would the naming be more accurately be "GSM" and "UMTS"? i.e. that when "2G = COMP128v3" and "3G = MILENAGE" are set on the USIM, are we instructing to use milenage on R99 capable 2G networks, and COMP128v3 only in non-R99 2G networks? (This seems to make most sense to me)
  • If this is so, we need to receive a 3G-derived Kc from the HLR independently from whether aud_2g tokens were also provided or not. Currently, a 2G Kc completely replaces the 3G derived one, instead we need both sent in the vector from the HLR.
  • So, for an R99 GERAN or MS, we would use UMTS AKA and the 3G derived Kc.
  • For a pre-R99 GERAN or MS, we would use GSM AKA and the separately calculated Kc.

• If the MSC knew that the 2G tokens were explicitly calculated from a separate GSM algo and not derived from 3G, it could refrain from sending a UMTS challenge on 2G, even if it is R99. Hence we would use only the 2G data, the shorter SRES and the ciphering key Kc would correspond with the keys used for authentication. (This would mean we would do UMTS AKA on 2G only if no aud_2g tokens are added to the HLR DB; R99 or not. So we would not be able to dynamically choose between UMTS or GSM AKA, which makes little sense to me.)

• either to add a separate 3G-derived Kc and SRES (I'm favoring this),
• or to add a flag whether Kc was derived from 3G or not.

Am I missing something?

To clarify the status quo, a workaround is to have only one set of auth tokens in the HLR db, either remove the aud_2g or remove the aud_3g.

• If only 2G tokens are present in the HLR db, auth and ciphering works well, using GSM AKA.
• If only 3G tokens are present in the HLR db, auth and ciphering works well, using UMTS AKA if R99 and 3G derived Kc.
• If both 2G and 3G tokens are present in the HLR db, authentication works (using UMTS AKA), but ciphering fails.

so, to recap: if on R99 capable devices and aud_3g data is present in the HLR, we use full UMTS AKA and expect the "3G" a.k.a. USIM app's auth algo to be used (not the SIM app a.k.a. "2G").

My thinko there lies in the fact that the Kc-from-UMTS-tokens formula is actually algorithm agnostic.
3GPP TS 33.103 4.2.2 "Authentication and key agreement (AKA USIM )"

The following cryptographic functions need to be implemented on the USIM:
[...]
c3: Conversion function for interoperation with GSM from Ck and IK (UMTS) to Kc (GSM).

Since c3 is algorithm agnostic, the MSC can employ it without having to know whether the HLR and USIM are using Milenage or whatever.

When using UMTS AKA, we should never use the Kc we got from GSUP. Instead, we always use c3(). (If the Kc from GSUP was derived from 3G in the HLR, incidentally that will be the same Kc as we will calculate in the MSC, and that doesn't bear any meaning; ignore the GSUP Kc, calculate it from UMTS tokens.)

If there are no aud_2g data in the HLR, the HLR will derive Kc and SRES from the UMTS tokens; that will only be used on non-R99 MS/GERAN, in which case we use the GSUP Kc for ciphering.

The response we receive is allowed to be just a GSM SRES, which the MS
may decide to send when on a GERAN.

This is what I'm surprised to hear. Do you have a spec reference for
that?

There is a code comment in that direction:

osmo-msc/src/libvlr/vlr_auth_fsm.c

                /* We have a R99 capable UE and have a UMTS AKA capable USIM.
                 * However, the ME may still choose to only perform GSM AKA, as
                 * long as the bearer is GERAN */

You added that comment on first vlr_auth_fsm.c implementation, so you may have had your reasons for that?

issue fixed by https://gerrit.osmocom.org/5470 (And patches leading up to it, see topic 'encryption' on gerrit)
https://gerrit.osmocom.org/#/q/status:open+topic:encryption

Depends on libosmocore https://gerrit.osmocom.org/5466

all merged, yet #2793 may be related