Project

General

Profile

Actions

Bug #3017

closed

HLR and MSC setup for COMP128v1 with only 2G KI set fails to authenticate

Added by neels about 6 years ago. Updated about 6 years ago.

Status:
Rejected
Priority:
High
Assignee:
Target version:
-
Start date:
02/28/2018
Due date:
% Done:

0%

Spec Reference:

Description

In the attached trace, the MSC fails to get the SRES indicated by the HLR tokens.
Need to clarify where exactly the problem lies (and then put this issue in the proper redmine project category).

HLR config is:

OsmoHLR# subscriber msisdn 101 show              
    ID: 1
    IMSI: 901700000014701
    MSISDN: 101
    PS purged
    2G auth: COMP128v1
             KI=25acc13e226dc91520af5c0dc25bfd4d

(A report has come in on the openbsc@ mailing list about this)


Files

Actions #1

Updated by neels about 6 years ago

All seems to be in order, except that the SIM returns a differing SRES. Verified the values with

▶ osmo-auc-gen -2 -a comp128v1 -k 25acc13e226dc91520af5c0dc25bfd4d -r 75c265176ae1f89fe39ccf1808ffddce
osmo-auc-gen (C) 2011-2012 by Harald Welte
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY

RAND:    75c265176ae1f89fe39ccf1808ffddce
SRES:    a37ffa47
Kc:    90546a83850cf800

so unless our comp128v1 itself is broken, I don't see how this is going wrong.
Now double checking the SIM's configured auth parameters.

Actions #2

Updated by ipse about 6 years ago

Not sure if that's your case but I recently spent several hours scratching my head with the same symptoms, until II realized that (1) HLR caches triplets, (2) I've just changed Ki on the SIM card, (3) cached triplets were not flushed in the HLR, so it was comparing triplets from an old Ki to SRES coming from SIM card with new Ki.

Actions #3

Updated by neels about 6 years ago

  • Status changed from New to Rejected

Gah

 * Current algorithm setting:
   2G: 7=COMP128v3
   3G: 1=MILENAGE

With COMP128v1 configured for 2G algo instead, all works out and we have no bug.

ipse, appreciate your comments though : ) -- btw, HLR doesn't cache, the MSC / SGSN cache the authentication tuples. So if you restart MSC+SGSN you're guaranteed to use the new data.

Actions #4

Updated by neels about 6 years ago

to clarify above comment, that was output pasted from the sysmo-usim-tool showing that the USIM was actually configured to do COMP128v3, while the HLR was using COMP128v1. Re-configuring the USIM to actually use COMP128v1 fixed all problems.

Actions #5

Updated by laforge about 6 years ago

Hi Neels,
On Wed, Feb 28, 2018 at 03:04:27PM +0000, neels [REDMINE] wrote:

ipse, appreciate your comments though :) -- btw, HLR doesn't cache, the MSC / SGSN cache the authentication tuples. So if you restart MSC+SGSN you're guaranteed to use the new data.

please also note that this caching is not a bug but is how 3GPP authentication is
designed to work. IF you want to avoid any caching, you can make the HLR always only
return only one and make sure MSC/SGSN are not permitted to re-use a tuple after
being used once.

neels: Do we have all related vty config options for this yet? If not, It would be a good feature.

Actions #6

Updated by neels about 6 years ago

created #3019

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)