Subject: Re: [MOBILE-IP] Lack of User privacy - IS it a security problem ?

From: Basavaraj Patil <[email-masked]>
Date: Wed, 13 Oct 1999 16:44:06 -0500

>Isn't the TMSI to provide privacy protection over the air?  The NAI should
>already be protected because (at least for cdma2000 packet data) it
wouldn't
>pass over the air until airlink encryption has already been set up.  Note
>this is different than any encryption being done at the IP or data link
>(PPP) layers.
>
>Regards,
>Mark Munson

Although the NAI may be protected over the air interface by virtue of
airlink encryption, the question here is more with regards to
maintaining confidentiality of the users identity in the visited
network until authorized by the home network.

A Mobile node may roam into a network that may be considered as
hostile or malicious. In such a case you would not want the identity
of the user (NAI) to be disclosed to the mobility agents in that
network until the home network has authenticated/validated the
visiting networks credentials. Subsequent to that the home network may
allow the MN to gain access to the network via the service providers
network that it is currently trying to get service from. At that point
in time it may be okay for the visited network to learn the users/MNs
identity (NAI). Users worried about privacy would value a proposition
like this in my opinion. The concept of a T-NAI does not sound very
promising in this scenario.

Cheers,
-Basavaraj

>
>> ----------
>>
>> Regarding the allowed or forbidden PLMN list for GSM, to set the record
>> straight GSM uses a number of mechanisms:
>> 1) Regional subscription capability. There are four possible values for
>> accessible area for service: all PLMNs, one national and all foreign
>> PLMNs,
>> regionally restricted, and regionally restricted plus all other PLMNs.
>>
>> 2) Barring of roaming. Three possible cases: No barring, barring of
>> roaming
>> outside the home PLMN, barring of roaming outside the home PLMN country.
>>
>> 3) The forbidden PLMN list mentioned in the previous emails is not a
>> static
>> list. It's dynamically built based on the failed access attempts and as
>> far
>> as I remember it's pretty short, i.e., a maximum of 4 PLMNs. In addition,
>> user can override this restriction, if she performs a manual mode network
>> selection.
>>
>> 4) There is also a preferred PLMN list, with upto 8 entries in the SIM,
>> used
>> for network selection in the automatic mode.
>>
>> At least some of the above cannot be done by ANSI-41 networks because
they
>> lack a very fundamental piece, i.e., the SIM card. However, even without
>> all
>> this capability, one thing is critical as mentioned previously in this
>> thread: the susbscriber identity confidentiality. That's why there is
TMSI
>> in addition to IMSI to minimize the chance of eavesdropping for
identities
>> when signaling messages have to be carried in clear before the
>> establishment
>> of ciphering. I wonder if it's possible to introduce a mechanism such as
>> T-NAI for mobile IP's use. Any comments?
>>
>> Murat Bilgic
>> Omnipoint Technologies Inc.
>>

---

From: Tom Weckström <[email-masked]>
Date: Thu, 14 Oct 1999 01:17:18 +0300

Hi,

I agree with you, Basavaraj.
The scenario seems just like it might be one day.

I was wondering...
Is there some restriction that makes it impossible for a MN to send the
NAI encrypted with the MN-HA shared secret in the Registration Request,
when no session keys are established?

The HA would be able to check the MN's NAI and the HA would then include
the NAI encrypted with the HA-FA session key or alternatively, with FA's
public key. the FA would get the encrypted NAI and successfully decrypt
it.

If session keys were established, the MN would encrypt the NAI with the
session key. The FA would be able to decrypt the NAI right away when it
received the new request.

So, only trusted FAs that knew the session key, would get to know the
NAI.

Well, this approach certainly increases computation burden, but are
there any other restrictions for this idea?

Regards,
         Tom

--
        Tom Weckström           [email-masked]
                                Helsinki University of Technology
                                Department of Computer Science

---

From: Pete McCann <[email-masked]>
Date: Wed, 13 Oct 1999 18:03:44 -0500

There may be a problem with this approach if the NAI is used for
"routing" the request back to the home domain, a scenario that pops up
in some proposals where HAs are dynamically assigned.  I don't think
we can really hope to hide the home *domain* from the FA, even if we
manage somehow to hide the *user* from the FA.  This seems to argue
for breaking the NAI into pieces that can be selectively encrypted...

-Pete

Tom WeckstrÂ€m <[email-masked]> (TW) writes:

TW> Hi,
TW> I agree with you, Basavaraj.
TW> The scenario seems just like it might be one day.

TW> I was wondering...
TW> Is there some restriction that makes it impossible for a MN to send the
TW> NAI encrypted with the MN-HA shared secret in the Registration Request,
TW> when no session keys are established?

TW> The HA would be able to check the MN's NAI and the HA would then include
TW> the NAI encrypted with the HA-FA session key or alternatively, with FA's
TW> public key. the FA would get the encrypted NAI and successfully decrypt
TW> it.

TW> If session keys were established, the MN would encrypt the NAI with the
TW> session key. The FA would be able to decrypt the NAI right away when it
TW> received the new request.

TW> So, only trusted FAs that knew the session key, would get to know the
TW> NAI.

TW> Well, this approach certainly increases computation burden, but are
TW> there any other restrictions for this idea?

TW> Regards,
TW>          Tom