Feature #1593
closedUMTS AKA support
Added by laforge over 8 years ago. Updated over 7 years ago.
100%
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
Updated by laforge over 8 years ago
- Status changed from New to In Progress
- Assignee set to laforge
Updated by neels over 7 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
Updated by neels over 7 years ago
- Related to Feature #1956: UMTS AKA support in OsmoSGSN added
Updated by neels over 7 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).
Updated by neels over 7 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.
Updated by neels over 7 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'
Updated by neels over 7 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.
Updated by neels over 7 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.
Updated by neels over 7 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!
Updated by neels over 7 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).
IMPORTANT NOTICE: This page contains information about a legacy version of the Osmocom software. This legacy version is no longer maintained. If you use it, don't be surprised if it doesn't work. It was your choice to ignore man-years worth of developments, improvements and fixes. Please migrate to the active/supported software (Osmocom CNI, consisting of OsmoBSC, OsmoMSC, OsmoHLR, OsmoSTP, OsmoMGW - a NITB style setup is described at Osmocom_Network_In_The_Box).