Project

General

Profile

Bug #4830

LU reject when no authentication data in HLR but "authentication optional"

Added by laforge about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
High
Assignee:
Category:
VLR
Target version:
-
Start date:
10/25/2020
Due date:
% Done:

0%

Resolution:
Spec Reference:

History

#1 Updated by laforge about 1 month ago

  • Category set to VLR
  • Assignee set to neels
  • Priority changed from Normal to High

I have a network configured as follows in the msc:

network
 network country code 901
 mobile network code 70
 short name OsmoMSC
 long name OsmoMSC
 encryption a5 0 1 3
 encryption uea 1 2
 authentication optional
 rrlp mode none
 mm info 1
msc
 mncc guard-timeout 180
 ncss guard-timeout 30
 assign-tmsi
 cs7-instance-a 0
 cs7-instance-iu 0
 auth-tuple-max-reuse-count 3
 auth-tuple-reuse-on-error 1
 mgw local-port 2728
 mgw remote-ip 127.0.0.1
 mgw remote-port 2427

So A5/0 is permitted, and authentication is entirely optional.

But what seems to happen is that the MSC asks the HLR for authentication data. However, the HLR doesn't have any authentication data for that subscriber (it only knows the IMSI, but no key material):

<0012> hlr.c:314 GSUP 6: MSC-00-00-00-00-00-00: IMSI-001010000000001 OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: IMSI unknown in HLR: IMSI known, but has no auth data; Returning slightly inaccurate cause 'IMSI Unknown' via GSUP

The MSC then subsquently rejects the LU:

<0002> gsm_04_08.c:347 msc_a(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91be0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=IMSI-001010000000001 LU-type=NORMAL
<0002> gsm_04_08.c:390 msc_a(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91be0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 001-01-0
<000e> fsm.c:461 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: Allocated
<000e> fsm.c:491 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: is child of msc_a(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91be0]
<000e> vlr_lu_fsm.c:1523 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
<000e> vlr_lu_fsm.c:1529 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
<000e> vlr.c:435 set IMSI on subscriber; IMSI=001010000000001 id=1010000000001
<000e> vlr.c:386 New subscr, IMSI: 001010000000001
<000e> vlr_lu_fsm.c:924 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1_pre()
<000e> vlr_lu_fsm.c:901 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
<000e> vlr_lu_fsm.c:908 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_IDLE}: State change to VLR_ULA_S_WAIT_AUTH (T0, 30s)
<000e> fsm.c:461 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH}: Allocated
<000e> fsm.c:491 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]
<000e> vlr_auth_fsm.c:628 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
<000e> vlr_auth_fsm.c:318 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH}: State change to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI (T0, 30s)
<000e> vlr.c:767 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_NACK
<000e> vlr_auth_fsm.c:339 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: GSUP: rx Auth Info Error cause: 2: IMSI unknown in HLR
<000e> vlr_auth_fsm.c:244 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Authentication terminating with result IMSI unknown in HLR
<000e> vlr_auth_fsm.c:250 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: State change to VLR_SUB_AS_AUTH_FAILED (no timeout)
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_AUTH_FAILED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_AUTH_FAILED}: Removing from parent vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_AUTH_FAILED}: Freeing instance
<000e> fsm.c:573 VLR_Authenticate(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae92020]{VLR_SUB_AS_AUTH_FAILED}: Deallocated
<000e> vlr_auth_fsm.c:253 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
<0002> gsm_04_08.c:108 msc_a(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91be0]{MSC_A_ST_AUTH_CIPH}: LOCATION UPDATING REJECT
<000e> vlr_lu_fsm.c:741 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_WAIT_AUTH}: State change to VLR_ULA_S_DONE (no timeout)
<000e> msc_a.c:836 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT)
<000e> msc_a.c:836 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_DONE}: Removing from parent msc_a(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91be0]
<000e> vlr_lu_fsm.c:1448 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
<000e> msc_a.c:836 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_DONE}: Freeing instance
<000e> fsm.c:573 vlr_lu_fsm(IMSI-001010000000001:GERAN-A-6:LU)[0x5652eae91d10]{VLR_ULA_S_DONE}: Deallocated
<000e> vlr.c:306 freeing VLR subscr IMSI-001010000000001 (max total use count was 4)

I think this is a perfectly valid configuration for people who don't have the key material for their SIM cards. They identify the subscriber via IMSI but don't cryptographically authenticate.

Is this not how it's supposed to work? If we have a bug, we should certainly have a related TTCN3 test...

#2 Updated by neels about 1 month ago

Taking a look:

The MSC part invokes the VLR part and passes in flags whether auth and ciph are required.
For LU:

vlr_loc_update(authentication_required = is_utran || net->authentication_required,
ciphering_required = is_utran ? net->uea_encryption : net->a5_encryption_mask > 0x01)

So as soon as any A5 besides A5/0 (==0x01) is enabled, we pass in
ciphering_required = true, which also implies authentication_required = true.

For the other Complete Layer 3 it's the exact same thing, just via arguments to vlr_proc_acc_req().

So I guess instead of just the flag, the VLR should get the full encryption
mask and decide whether to do auth or not depending on the HLR's response.

That should be relatively trivial to implement, but then again not so trivial
since it affects the inner workings of the VLR FSMs.

#3 Updated by laforge about 1 month ago

On Tue, Oct 27, 2020 at 02:46:26PM +0000, neels [REDMINE] wrote:

The MSC part invokes the VLR part and passes in flags whether auth and ciph are required.
For LU:

> vlr_loc_update(authentication_required = is_utran || net->authentication_required,
> ciphering_required = is_utran ? net->uea_encryption : net->a5_encryption_mask > 0x01)
> 

So as soon as any A5 besides A5/0 (==0x01) is enabled, we pass in
ciphering_required = true, which also implies authentication_required = true.

interesting, and - of course - a bug. Just because A5/1 or A%/3 are supported in the
network doesn't mean it is mandatory. Mandatory would only be in case no A5/0 is allowed.

So I guess instead of just the flag, the VLR should get the full encryption
mask and decide whether to do auth or not depending on the HLR's response.

looks reasonable.

That should be relatively trivial to implement, but then again not so trivial
since it affects the inner workings of the VLR FSMs.

But I guess we should have pretty good test coverage with the unit tests and the TTCN3
tests, so I'd think if something breaks we should see it in the tests and not in the field.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)