https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-05-14T00:06:58ZOpen Source Mobile CommunicationsOsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=14292016-05-14T00:06:58Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-high2 closed" href="/issues/1592">Feature #1592</a>: VLR in libmsc, to connect to HLR asynchronously</i> added</li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=14312016-05-14T00:07:57Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>so far hardcoded 2G KI are used on the sysmocom/iu branch</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=19862016-08-01T12:23:23Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-3 priority-high3 closed" href="/issues/1593">Feature #1593</a>: UMTS AKA support</i> added</li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=19882016-08-01T12:23:30Zlaforge
<ul><li><strong>Assignee</strong> set to <i>laforge</i></li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=20212016-08-09T12:15:52Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=24412016-11-11T08:38:24Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>neels</i></li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=24972016-11-24T16:42:37Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Started off by a small detour: write python code to produce dotty graphs<br />from osmo_fsm C code.</p>
<p><a class="external" href="https://git.osmocom.org/libosmocore/log/?h=neels/fsm-to-dot">https://git.osmocom.org/libosmocore/log/?h=neels/fsm-to-dot</a><br />temporary example upload: <a class="external" href="http://kleinekatze.de/quooXai5/">http://kleinekatze.de/quooXai5/</a></p>
<p>Writing this first off helped in understanding how these structures are built,<br />and the graphs will help tremendously during further development.</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=25302016-12-02T17:16:52Zlaforge
<ul><li><strong>Target version</strong> set to <i>Asynchronous HLR+AUC for CS</i></li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=25602016-12-06T12:20:48Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=27612017-01-10T12:57:25Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>The VLR integration work is tracked in <a class="issue tracker-2 status-5 priority-4 priority-high2 closed" title="Feature: VLR in libmsc, to connect to HLR asynchronously (Closed)" href="https://osmocom.org/issues/1592">#1592</a>. So when that is done and the 3G branch gets rebased onto it, this issue's progress will probably jump to 100%. So let me set it to 50% for now, showing that things are in progress.</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=29152017-01-23T11:50:11Zwirelesss
<ul></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=29712017-02-02T03:11:15Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>60</i></li></ul><p>On the vlr branch, the first end-to-end test for UMTS milenage authentication is in place<br />and working, though still lacking the milenage sequence nr synchronisation procedure,<br />and not tested with real equipment yet.</p>
<p>Done:</p>
<ul>
<li>MM Auth Request composition and Response parsing were extended to accomodate UMTS extensions.</li>
<li>the VLR now detects whether a subscriber connection is via UTRAN or GERAN</li>
<li>and whether the subscriber is capable of R99,</li>
<li>it detects whether the HLR provided UMTS and/or GSM auth tokens and</li>
<li>sends the corresponding Auth Request message.</li>
<li>res/sres is parsed from the auth response in the MSC and</li>
<li>the VLR verifies against the expected res/sres.</li>
</ul>
<p>Next:</p>
<ul>
<li>milenage seq sync: add parsing of AUTS message, handle in VLR to re-issue Auth Request.</li>
</ul>
<p>After that:</p>
<ul>
<li>more regression tests verifying graceful rejection in auth failure cases.</li>
<li>test gsm-milenage, i.e. compatibility mode of milenage in a pre-R99 environment.</li>
<li>try to rebase the sysmocom/iu branch onto the VLR changes to test real world 3G auth?</li>
</ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=30122017-02-07T11:15:30Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>UMTS Resync: Parsing of AUTS (auth response resync token) is merged to openbsc master.<br />On the VLR branch, the UMTS (milenage) resync procedure is implemented and tested<br />across MSC, VLR and HLR (i.e. is complete).</p>
<p>libosmocore and osmo-hlr (as well as some docs and cmdline util) had the wrong<br />size for AUTS, which is now comprehensively fixed from 16 to 14 bytes:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/1731/">https://gerrit.osmocom.org/#/c/1731/</a>, <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: OAP doc (Closed)" href="https://osmocom.org/issues/1874">#1874</a></p>
<p>Found a problem in osmo_auth_gen_vec_auts() where the API .h had different arg ordering<br />than the implementation. This is fixed in<br /><a class="external" href="https://gerrit.osmocom.org/#/c/1737/">https://gerrit.osmocom.org/#/c/1737/</a>, <a class="external" href="https://gerrit.osmocom.org/1739">https://gerrit.osmocom.org/1739</a></p>
<p>Clarified resync output for osmo-gen-vec in <a class="external" href="https://gerrit.osmocom.org/1734">https://gerrit.osmocom.org/1734</a></p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=30242017-02-09T03:26:12Zneelsnhofmeyr@sysmocom.de
<ul></ul>A few oddities were found and fixed while writing the MSC+VLR tests for HLR rejects as described in <a class="issue tracker-3 status-5 priority-3 priority-high3 closed" title="Support: comprehensive test of MSC subscriber connection and request handling (Closed)" href="https://osmocom.org/issues/1922">#1922</a>:
<ul>
<li>don't send auth failure to HLR when the auth failure was due to the HLR not knowing the subscriber / not providing auth tuples</li>
<li>proper auth reject cause if IMSI is known but no auth tuples are obtained</li>
<li>auth reject logic fix in case a GSUP auth ACK contains no tuples</li>
<li>introduced optional vlr->cfg.auth_tuple_max_use_count (though re-using the exact same auth tuples opens the doors for replay attacks; the default is to use once only, even on HLR error).</li>
</ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=30602017-02-14T15:22:24Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>60</i> to <i>80</i></li></ul><p>Verified with real equipment that our GSM-Milenage algorithm (for abbreviated Milenage on pre-R99 networks)<br />works with a sysmoUSIM-SJS1 configured to do Milenage for both 2G and 3G.</p>
<p>One thing though, I expected this to now do full UMTS Auth when using an R99+ MS, and the GSM-Milenage fallback<br />only when the MS is pre-R99. But even though the USIM is in an R99+ MS (Samsung Galaxy S4m), the LU Request still<br />indicates "GSM phase 2" in the classmark and GSM-Milenage is used instead of normal UMTS Milenage.</p>
<p>Is there something else we can set on the USIM to make it show as R99 on the GSM network?<br />(It does show as R99 on a 3G network.)</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=31472017-02-28T02:23:50Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>neels wrote:</p>
<blockquote>
<p>Is there something else we can set on the USIM to make it show as R99 on the GSM network?<br />(It does show as R99 on a 3G network.)</p>
</blockquote>
<p>As described elsewhere, this was due to the MSCR in SI3 being 0, indicating a pre-R99 MSC.<br />Full UMTS AKA has been verified to work with a USIM on a GSM network (with MSCR set to 1),<br />with real equipment.</p>
<p>All that would be missing now is a rebase of the 3G work onto the VLR work and a test of UMTS AKA on UTRAN.</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=32002017-03-01T16:41:46Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Started to rebase the sysmocom/iu branch onto the neels/vlr branch.<br />The first conflict resolution is done, but I need to re-check pretty much every detail,<br />to make sure nothing got lost.</p>
<p>Rebasing a long branch like this is not very efficient -- a given resolved conflict potentially re-appears N times, e.g. if a given section was deleted, and the branch edits that section in N separate commits. Each edit brings back the same conflict and the given section has to be removed again each time.</p>
<p>It might make sense to collapse the Iu branch into one code bomb commit to cut short future rebases, but then I might have to re-untangle the spaghetti later for code review by others.</p>
<p>An alternative is to merge instead of rebasing, but that will make the history less linear once things get merged to master. I'd prefer to avoid that confusion.</p>
<p>I will see how it goes on, for now amending / purging the individual iu patches to make sense with the new VLR auth, hoping that most of these conflicts are done now anyway and won't re-appear; but if I continue to spend time in rebase conflicts I will reconsider.</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=32012017-03-01T20:18:45Zlaforge
<ul></ul><p>On Wed, Mar 01, 2017 at 04:41:46PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>Rebasing a long branch like this is not very efficient [...]<br />It might make sense to collapse the Iu branch into one code bomb commit [...]<br />An alternative is to merge instead of rebasing, [...]</p>
</blockquote>
<p>I'm quite flexible here, we should try to make sure you can work<br />efficiently.</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=32102017-03-03T03:26:44Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>All conflicts have been resolved.<br />The combined code compiles.<br />All tests pass, including msc_vlr end-to-end tests, notably some running for RAN_GERAN_A and some for RAN_UTRAN_IU.</p>
<p>The function to transmit over A-interface, a_tx() (vs. iu_tx()), is of course not implemented yet,<br />but the msc_vlr tests override it to evaluate what messages <em>would</em> be sent over the A-interface.<br />Also added an a_page() function (vs. iu_page_cs()) for the same purpose.</p>
<p>Added a vlr_subscr->cs.via_ran indicator to remember which RAN it attached over, mostly to know which way to send Paging,<br />to a_page() or iu_page_cs(). This will probably change when we enhance OsmoMSC Paging to use the LAC.<br />Added a check that prevents mixing RAN types (not sure about 2G/3G handover, but for now mixing is prohibited).</p>
<p>Next up:</p>
<ul>
<li>actual tests with the nano3G, sysmoUSIMs and Galaxy phones</li>
<li>check for important FIXMEs and errors</li>
<li>fixup / collapse commits, obliterate scores of dead code</li>
</ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=32202017-03-04T03:21:17Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>The rebased iu-onto-vlr branch works with real USIM on real nano3G!<br />Both OsmoMSC and OsmoSGSN authenticate the USIM via real IuCS+IuPS using the new OsmoHLR, using milenage successfully!<br />This is a major milestone, I'm quite satisfied right now.</p>
<p>The sysmocom/iu branch as of now includes the VLR branch, talks to OsmoHLR and is capable of full UMTS Authentication.<br />Some code cleanup is pending, but that's not of concern to this 3G Auth issue.</p>
<p>Notably: it works well with the USIM that dexter programmed to use Milenage on both 2G and 3G,<br />but another unchanged sysmoUSIM keeps failing to authenticate. It does an AUTS resync which seems to not work out.<br />I tried setting other algos in the HLR, they are all rejected with "GSM auth not acceptable" or the HLR errors out.<br />So the accelerate3g5 guys may have to reprogram their USIMs to EF.AUTH = 0101 like the one I got from dexter.<br />I'll investigate further in another ticket: <a class="issue tracker-3 status-5 priority-3 priority-high3 closed" title="Support: use sysmoUSIM-SJS1 with 3G OsmoMSC (Closed)" href="https://osmocom.org/issues/1965">#1965</a></p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=32232017-03-04T05:29:20Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>The rebased iu-onto-vlr branch works with real USIM on real nanoBTS!</p>
</blockquote>
<p>Typo! nano3G!!</p> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=33002017-03-08T22:08:36Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-3 status-5 priority-3 priority-high3 closed" href="/issues/1965">Support #1965</a>: use sysmoUSIM-SJS1 with 3G OsmoMSC</i> added</li></ul> OsmoNITB - Feature #1711: 3G Authhttps://osmocom.org/issues/1711?journal_id=36392017-04-25T13:57:28Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>