On 08/24/2011 07:19 PM, M P wrote: Hello Marvin,
> As a follow-up to my previous e-mail, I found out that the IMSI information > sometimes appear on the User-Name attribute (with an additional prefix of 1) > and sometimes as part of the long value of the EAP-Message attribute. It's > not consistent though. But lately I noticed that the User-Name attribute now > contains TMSI instead of IMSI and even the EAP-Message attribute, it's the > TMSI that is present instead of IMSI. > - - - < s n i p > - - -# grep -i 525053102410897 * | grep -v -i query | grep > -v -i GSM-IMSI | grep -v -i DEBUGradiator-20110614.log: User-Name = > "1525053102410897"radiator-20110614.log: EAP-Message = > <2><0><0>8<1>1525053102410...@wlan.mnc005.mcc525.3gppnetwork.orgradiator-20110614.log: > User-Name = "1525053102410897"radiator-20110614.log: User-Name = > "1525053102410897"radiator-20110623.log: EAP-Message = > <2><2><0>X<18><10><0><0><14><14><0>[email protected]<16><1><0><1><7><5><0><0>5k<129><138>u<152><132><213><20><146>Y<169><245>Y<238><196>radiator-20110714.log: > EAP-Message = > <2><2><0>X<18><10><0><0><14><14><0>[email protected]<16><1><0><1><7><5><0><0><241><169><204><25>2<190><157>u<189>]@<160>>A<130>j- > - - < s n i p > - - - Yes, this is allowed according to the EAP-SIM RFC. You are seeing the IMSI in the initial request, but subsequent requests use TMSI to hide the real identity. To keep track of the IMSI, you would need to follow the EAP session and subsequent reauthentication using the context Radiator creates for EAP authentication. In other words, this means digging into Radiator more instead of being able to handle the requests simply packet by packet. > Is there any configuration that I can do in Radiator in order for me to see > the actual IMSI value consistently in one of the RADIUS attribute from every > Access-Request? eap_simoperator.cfg has an example of how to control TMSI generation. Please see the example and try "UseTMSI 0" to turn it off. There's also "UseReauthentication" just below you could try to turn off. Note that identity hiding is generally considered a good feature so turning off TMSI and reauthentication may not be a good idea outside of lab environment. >From your previous message: >> One of the parameters is a pointer to EAP context Radiator keeps and the >> IMSI should be available from the context information. > > Are you saying that I only have to uncomment the below line from the > configuration? > AuthorisedHook sub {print "here in AuthorisedHook @_\n";} Also you would need to expand the hook with real code that uses the parameters Radiator passes to it. The parameters should give you access to e.g. EAP context that contains IMSI. > Moving forward on the EAP-SIM authentication, if I am going to try > authenticating via the API of the MAP gateway, I shoul > d only be using the "AuthBy EXTERNAL" and execute a script whenever there is > an Access-Request and I don't need the configurations of the "AuthBy > SIMOPERATOR" anymore, right? You might also see if expanding AuthSIMOPERATOR.pm would be useful. As the README and the comments in the .pm file say, it can and should be expanded as needed. Depending on your environment EXTERNAL might be an answer too. SIMOPERATOR will probably be useful as a reference since it is meant as the first component in Radiator that processes the incoming EAP-SIM requests from NASes. Thanks! -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
