Project

General

Profile

Feature #1593

UMTS AKA support

Added by laforge about 5 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

100%

Spec Reference:

Description

Even over a GSM/GPRS RAN, most phone today can perform mutual authentication based on UMTS AKA.

libosmocore also already has the UMTS authentication code in place for years, but OsmoNITB is not using it. HLR changes are associated with it, as we need to store K+OPC+SQN.


Related issues

Related to OsmoNITB - Feature #1711: 3G AuthClosed05/14/2016

Related to OsmoSGSN - Feature #1956: UMTS AKA support in OsmoSGSNClosed02/20/2017

Associated revisions

Revision 3b8cb39e (diff)
Added by neels about 4 years ago

fix osmo_auth_gen_vec_auts: copy rand to auth vector

Related: OS#1593
Change-Id: If943731a78089f0aac3d55245de80596d01314a4

Revision abb23698 (diff)
Added by neels about 4 years ago

gsup test: add decoding test for UMTS IEs

This would have caught the wrong expectation of AUTS' length fixed recently
(3a5ca647c531b7761dc6c555e5e0cabc972bd3ac).

Besides AUTS, add AUTN, RES, CK, IK which were also not tested yet.

Change-Id: I6fddf8d7ce97137b0a585d365807bcaf90a319d0
Related: OS#1593

Revision d1c2fc6d (diff)
Added by neels about 4 years ago

gsm_04_08.h: add R99 MSCR and CBQ3 to SI3 Ctrl Chan Descr

MSCR and CBQ3 are Release 1999 additions to the Control Channel Description IE
of SI3.

Assuming that no-one is using the spare bits, this will not cause any code
conflicts.

In the R99 struct, spare1 and spare2 are in different places, so rather rename
them to spare_1 and spare_2 to make sure we get a compiler barf if anyone
tries to use them with the wrong structure.

Adjust the spec reference to TS 44.018; TS 04.08 Figure 10.5.33 is replaced by
TS 44.018 Figure 10.5.2.11.1 which is right there in the named Section
10.5.2.11, so drop the explicit reference.

Motivation: the R99 Control Channel Description defines MSCR to indicate
whether the MSC is R99+ or not. To use UMTS AKA on GSM networks, we want to
indicate that our libmsc is capable of R99, like OsmoSGSN already does.

CBQ3 is merely added for completeness, no particular use case in mind.

Related: OS#1593
Change-Id: If87e07b5d04e1617155383e14c98d2125fdd0608

History

#1 Updated by laforge almost 5 years ago

  • Status changed from New to In Progress
  • Assignee set to laforge

#2 Updated by laforge over 4 years ago

#3 Updated by laforge over 4 years ago

  • Priority changed from Low to High

#4 Updated by laforge over 4 years ago

  • Assignee changed from laforge to neels

#5 Updated by neels about 4 years ago

First UMTS AKA test suites have been added to osmo-hlr (testing e.g. correct tuples generated
for GSM with UMTS AKA with test vectors taken from 3GPP TS 55.205) and on openbsc on the
neels/vlr branch (testing pure UMTS AKA over UTRAN). More details: https://osmocom.org/issues/1711#note-12

#8 Updated by neels about 4 years ago

#9 Updated by neels about 4 years ago

  • % Done changed from 0 to 50

copied from "3G Auth" #1711:

Verified with real equipment that our GSM-Milenage algorithm (for abbreviated Milenage on pre-R99 networks)
works with a sysmoUSIM-SJS1 configured to do Milenage for both 2G and 3G.

One thing though, I expected this to now do full UMTS Auth when using an R99+ MS, and the GSM-Milenage fallback
only when the MS is pre-R99. But even though the USIM is in an R99+ MS (Samsung Galaxy S4m), the LU Request still
indicates "GSM phase 2" in the classmark and GSM-Milenage is used instead of normal UMTS Milenage.

Unless we find out how to test this on pre-R99, we will only be able to test full UMTS auth when we have the
sysmocom/iu branch rebased onto the VLR developments. So far the msc_vlr end-to-end tests suggest that UMTS AKA
will work on real equipment with OsmoNITB (branch neels/vlr).

#10 Updated by neels about 4 years ago

The Quectel EC20 also sends classmark "GSM phase 2" even though it is R99 with a USIM.
Next: try to find out whether some SI we transmit tells the MS to not do R99.

#11 Updated by neels about 4 years ago

Indeed SI3 contains a Control Channel Description with a previously spare bit set to 1 for R99 or later,
which our MSC sends as 0 and thus indicates to the MS that we're not capable of UMTS.
3GPP TS 44.018 9.1.35 'System information type 3' and 10.5.2.11 'Control Channel Description'

#12 Updated by neels about 4 years ago

We currently send "MSC is pre R99" for MSC in SI3 and "SGSN is R99+" in SI13.

First test with MSCR set to R99 reveals that now the MS (Quectel EC20) indeed sends R99 in
classmark1 and happily runs an authentication sync request (Auth Failure with AUTS token),
after which our MSC/VLR fails to send another Authentication Request.

After a few attempts, the LU is successful because no sync is requested.
That's because the USIM was also used on another test setup and has a higher key SQN,
and the HLR db by coincidence caught up with that SQN after a few LU requests.

So the conclusion is that basic UMTS AKA works, but we still have some bug in the AUTS process.
Debugging it now.

#13 Updated by neels about 4 years ago

One problem is that we still missed one spot where our gsup.c code expects a 16 byte AUTS, it has to be 14 instead.
https://gerrit.osmocom.org/1860

There's apparently still some other problem, debugging now.

#14 Updated by neels about 4 years ago

  • % Done changed from 50 to 90

Found these fixes:
https://gerrit.osmocom.org/1860
https://gerrit.osmocom.org/1870
https://gerrit.osmocom.org/1864

accompanied by tests and others:
https://gerrit.osmocom.org/#/q/topic:auts

With these fixes and the VLR branch, tests with real equipment show successful UMTS AKA
including AUTS resync with OsmoNITB on a GSM network with R99 MSC and MS. Excellent!

#15 Updated by neels about 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

The sysmocom/iu branch has been rebased onto the vlr branch and now also features UMTS AKA
in the 3G OsmoMSC (= the OsmoNITB without BSC and with a separate HLR).

#16 Updated by laforge almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)