HLR and MSC setup for COMP128v1 with only 2G KI set fails to authenticate
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)
#1 Updated by neels about 1 year 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.
#2 Updated by ipse about 1 year 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.
#3 Updated by neels about 1 year ago
- Status changed from New to Rejected
* 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.
#5 Updated by laforge about 1 year ago
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.