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

From: Raja Narayanan <[email-masked]>
Date: Mon, 11 Oct 1999 09:03:19 -0500

> Hello,
>
> Some users may prefer that their identity is not revealed to a foreign
> domain until their home domain has a trust relationship with the foreign
> domain. According to the current MIP protocol, the MN IP address/MN NAI is
> sent in the clear at Registration time thereby clearly compromising user
> privacy. Sending NAI in the clear also comprises the location and identity
> of the user to potential eavesdroppers.
>
> User privacy at registration time is not a requirement in MIP. From a
> security standpoint is this breach of privacy?  Do we need to address this
> ?
>
> Appreciate comments from WG and from the TR45.6 perspective.
>
> --Raja
> Nortel Networks
>
>

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 13 Oct 1999 07:54:05 -0700

Let me ask a slightly different question, but perhaps related.

Does a VLR know of a user's IMSI, or is this hidden from the VLR and only
the HLR is aware of it? If the VLR has access to the user's IMSI, how
is this less of a privacy issue? An NAI can be about as cryptic as an NAI.
It seems logical to have a user's NAI be the same as his/her e-mail address,
but this is not a requirement (and specifically stated in RFC 4286).

So, if the "user" portion of the NAI is cryptic (e.g. 342134234454), and
only the domain is known, how is this different from, perhaps, only passing
the AAAH's NAI?

PatC

---

From: First_Name Last_Name <[email-masked]>
Date: Wed, 13 Oct 1999 17:34:19 +0200

The VLR indeed does know the IMSI. However, my mobile wouldn't even try
to connect to a visited mobile network if my home network has no trust
relationship. This information (allowed and forbidden network IDs) is
on the SIM-card I get from my service provider. Network operators
broadcast their network ID on the beacon channel.

Konstantin

Alcatel

----------
From: [email-masked]
To: [email-masked]
Subject: Re: [MOBILE-IP] Lack of User privacy - IS it a security problem ?
Date: Wednesday, 13. October 1999 16:54

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 13 Oct 1999 09:10:42 -0700

Putting aside the fact that it seems ugly, at best, to require that a SIM
card be updated everytime my home provider sets up, or tears down, a
business relationship, it seems to me that if the IMSI is provided to
the foreign network, there is no additional security issue with having the
NAI provided as well.

PatC

---

From: "Munson, Mark A." <[email-masked]>
Date: Wed, 13 Oct 1999 13:09:29 -0400

Currently  ANSI-41 based networks do not behave as the GSM-MAP networks
Konstantin described.  Based on the model of handset, it may or may not try
and register if a network ID is not in a preferred list.  So, I think to
answer Pat's question, the visiting network does learn the IMSI.

I don't think it's accurate, however, to equate the privacy treatment of the
IMSI with the NAI.  Certainly [email-masked] contains a lot clearer
"identity" than 0016783394439 does.  That said, we haven't heard any
requirements within TR-45.6 to this point requiring that the privacy be
maintained within the wired part of the visited network (FA and AAA).
Certainly privacy is required over the airlink because outside entities can
try and sniff it, but this is covered by several layers of encryption.

It is an interesting question, however.  I'll give it some more thought.

Regards,
Mark Munson
> ----------
> From:         Patrice Calhoun[SMTP:[email-masked]]
> Reply To:     [email-masked]
> Sent:         Wednesday, October 13, 1999 12:10 PM

---

From: Emad Qaddoura <[email-masked]>
Date: Wed, 13 Oct 1999 11:28:55 -0500

Also, cloning an FA would be much much simpler than cloning a VLR. This
should make some concerns about the privacy of the MN, until the FA is
trusted.

With respect to sending the NAI in the clear, I believe the MN should have
the option of not sending it in the clear.

> -----Original Message-----
> From: First_Name Last_Name [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 10:34 AM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] Lack of User privacy - IS it a
> security problem
> ?
>
>

---

From: [email-masked]
Date: Wed, 13 Oct 1999 12:19:12 -0600

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: "Munson, Mark A." <[email-masked]>
Date: Wed, 13 Oct 1999 15:28:00 -0400

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

> ----------
> From:         [email-masked][SMTP:[email-masked]]
> Sent:         Wednesday, October 13, 1999 2:19 PM
> To:   [email-masked]; [email-masked]
> Subject:      RE: [MOBILE-IP] Lack of User privacy - IS it a security
> problem ?
>

---

From: [email-masked]
Date: Wed, 13 Oct 1999 15:14:19 -0600

Mark,

Yes, TMSI is for identity confidentiality over the air. Since GSM uses
secret key based ciphering, without identifying the user, it's impossible to
establish ciphering. Does cdma2000 uses a DH-key exchange like CDPD does to
establish ciphering without identifying itself to the network?

My assumption about the need for a T-NAI was that NAI may have to be sent in
clear during the initial registration before the access-level ciphering is
established if the access-level, e.g., TDMA, CDMA, GSM, etc., is closely
tied to mobile IP.

Regards,

Murat Bilgic

> From: Munson, Mark A. [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 1:28 PM
> > list. It's dynamically built based on the failed access
> attempts and as
> > far
> > 4) There is also a preferred PLMN list, with upto 8 entries
> in the SIM,
> > used
> > lack a very fundamental piece, i.e., the SIM card. However,
> even without
> > all

---

From: "n. asokan" <[email-masked]>
Date: Thu, 14 Oct 1999 08:27:37 +0300

[email-masked] (EXT Pete McCann) writes:
> 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> 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?
[....]

Session keys are almost always keys for a symmetric key cryptosystem.
This implies a problem.  When presented with an encrypted NAI, the
verifying entity has to figure out which decryption key to use.  The
MN cannot send any hints in the clear, because it is equivalent to
leaking information about the real identity.

The basic problem is how to construct psuedonyms that look random to
outsiders but can be efficiently associated with the real identity by
legitimate verifiers.  There are various solutions to this problem:
- use public key cryptosystems: compute the pseudonym as a randomized
  encryption with the verifier's public encryption key
- construct pseudonyms as E(K, real_id) where E() is some randomized
  symmetric key encryption algorithm but K is a key known _only_ to the
  verifier.  This means that the verifier constructs future pseudonyms
  and hands them to the MN.  They are opaque to MN.  This is like the
  GSM TMSI approach, but more robust.
These and other solutions were described several years ago.  Each has
its advantages and drawbacks.

IMHO, privacy concerns are likely to become very important.  At the
least, proposed standards should not preclude later applicability of
privacy protecting mechanisms. I again suggest this for consideration
as an additional 'Mobile IP requirement for AAA'.

- Asokan

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki

---

From: Emad Qaddoura <[email-masked]>
Date: Thu, 14 Oct 1999 09:17:31 -0500

> From: Pete McCann [mailto:[email-masked]]
> Sent: Wednesday, October 13, 1999 6:04 PM

Or having the home domain as a seperate field. Not sure if we should have
the
mobility agents reconstruct the whole NAI. I am sure it can be argued both
ways.

[....]

---

From: "Munson, Mark A." <[email-masked]>
Date: Thu, 14 Oct 1999 13:27:20 -0400

This (obscure NAIs for those who want them) probably will be a sufficient
solution for the short term.  I believe that traditional PPP users in a
roaming environment tell the local server their NAI before service is
authorized, which seems to be an equivalent case.  This makes me think it is
not a critical issue today.

Certainly we should not preclude any mechanisms which allow the NAI to be
kept confidential in the future, and we should probably pursue this.  I do
not think, however, that we should hold up the current generation of work
while we try to solve it.

Regards,
Mark Munson

> ----------
> From:         Matthew Ford[SMTP:[email-masked]]
> Reply To:     Matthew Ford
> Sent:         Thursday, October 14, 1999 12:54 PM
> Can anyone be bothered to explain to me why an NAI like
> [email-masked] is preferable to [email-masked]? Using the latter
> masks the MNs identity from the foreign network (unless there is some
> collusion between the foreign network and the home network to associate
> number and name). This solution seems to me to be trivial to implement
> and probably sufficient to persuade most users (i.e. all but the
> ultra-paranoid) that their privacy is protected.
>
> Mat.
>
> Emad Qaddoura wrote:
> >
> > > From: n. asokan [mailto:[email-masked]]
> > > Sent: Thursday, October 14, 1999 12:28 AM
> > I support the statement.

---

From: "Lipford, Mark" <[email-masked]>
Date: Thu, 14 Oct 1999 12:45:16 -0500

I support the comments below.  While being able to provide a method to keep
the NAI confidential is an excellent goal, I do not believe it should hold
up work.

        ----------
        From:  Munson, Mark A. [SMTP:[email-masked]]
        Sent:  Thursday, October 14, 1999 12:27 PM
        To:  [email-masked]
        Subject:  Re: [MOBILE-IP] Lack of User privacy - IS it a security
problem ?

        This (obscure NAIs for those who want them) probably will be a
sufficient
        solution for the short term.  I believe that traditional PPP users
in a
        roaming environment tell the local server their NAI before service
is
        authorized, which seems to be an equivalent case.  This makes me
think it is
        not a critical issue today.

        Certainly we should not preclude any mechanisms which allow the NAI
to be
        kept confidential in the future, and we should probably pursue this.
I do
        not think, however, that we should hold up the current generation of
work
        while we try to solve it.

        Regards,
        Mark Munson

security

---

From: "Lipford, Mark" <[email-masked]>
Date: Wed, 13 Oct 1999 10:33:41 -0500

I agree with Pats comments.  There is one issue that may need to be
discussed.  While the VLR does know the IMST of the mobile the IMSI is not
past over the RF in the open.  I think I read somewhere on either this tread
or another where the NAI is past over the open to/from the FA.  As a future
provider of mobile IP services this is much more of a concern then having
the FA know the NAI.

Thanks
        ----------
        From:  Patrice Calhoun [SMTP:[email-masked]]
        Sent:  Wednesday, October 13, 1999 9:54 AM
        To:  [email-masked]
        Subject:  Re: [MOBILE-IP] Lack of User privacy - IS it a security
problem ?

        Does a VLR know of a user's IMSI, or is this hidden from the VLR and
only
        the HLR is aware of it? If the VLR has access to the user's IMSI,
how
        is this less of a privacy issue? An NAI can be about as cryptic as
an NAI.
        It seems logical to have a user's NAI be the same as his/her e-mail
address,
        but this is not a requirement (and specifically stated in RFC 4286).

        So, if the "user" portion of the NAI is cryptic (e.g. 342134234454),
and
        only the domain is known, how is this different from, perhaps, only
passing
        the AAAH's NAI?

        PatC

---

From: "Munson, Mark A." <[email-masked]>
Date: Fri, 15 Oct 1999 08:56:37 -0400

Hi Mark,

I had attempted to indicate that the NAI is not passed in the open over the
air.  Maybe I didn't get the words right.  Anyway, the access network
(airlink) registration happens first, which sets up encryption, and then the
mobile requests packet data service, and then it is assigned to a traffic
channel at which point the NAI passes.  The traffic channel is certainly
encrypted.  Does that alleviate your concern?

Regards,
Mark Munson

> ----------
> From:         Lipford, Mark[SMTP:[email-masked]]
> Reply To:     Lipford, Mark
> Sent:         Wednesday, October 13, 1999 11:33 AM
>         >> domain until their home domain has a trust relationship with
> the
> foreign
>         >> privacy. Sending NAI in the clear also comprises the location
> and
> identity

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 15 Oct 1999 07:38:02 -0700

This was my point all along. An NAI can be as cryptic as an IMSI.

PatC

---

From: Thomas Eklund <[email-masked]>
Date: Fri, 15 Oct 1999 16:46:29 +0200

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Friday, October 15, 1999 4:38 PM

So why use it, when there is a widespread usage of IMSI?

-- Thomas

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 15 Oct 1999 08:36:26 -0700

>provider of mobile IP services this is much more of a concern then having

I was under the impression that in a CDMA network, the traffic was protected.
If the traffic is in the clear between the base station and the FA, I don't
think that we need to worry about that too much.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 15 Oct 1999 10:23:40 -0700

Because routing of AAA packets using an NAI is a well known problem and
is already deployed. Routing of AAA packets using IMSI is *very* specific
to Mobile-IP for cellular networks (read: no other service uses IMSI), and
does not currently have any solution/deployment.

Lastly, if Mobile-IP is run over an etherhet link, 802.11, etc. you would
end up having to using something other than IMSI. Presumably the NAI.

PatC

---

From: "Walsh, Patrick J." <[email-masked]>
Date: Fri, 15 Oct 1999 14:58:50 -0500

It makes sense to have a requirement "to protect user confidentiality".
However, I'm still not sure what confidentiality is compromised by an FA
being able to see the user part of the NAI (user@domain).   To put it
another way, how does the FA know that the user identified in user@domain is
valid and hasn't been spoofed?

Regards,
PatW.

> From: Raja Narayanan [SMTP:[email-masked]]
> Sent: Friday, October 15, 1999 2:27 PM
> To perhaps take a stab at paraphrasing opinions/comments:-
>
> 1.) While it is important not to hold up current work, it is desirous to
> protect user confidentiality in the future. This may very well translate
> into having to encrypt the user NAI.
> 2.) The above would result in somehow having to transmit the 'home domain'
> info to the FA.
>
> While it is somewhat clear how the confidentiality is maintained within
> the
> existing current cellular networks [the visiting networks are trusted],
> MIP
> implementations will span a whole bunch of heteregenous access networks.
> In
> this context, the visited FA may or may not be trusted and therefore there
> needs to an option for the mobile/nomadic user to be guaranteed privacy.
>
> Do we have consensus in the WG that we need to consider taking this in as
> an
> additional requirement into 'Mobile IP requirement for AAA'.
>
> --Raja
> Nortel Networks
>
>
>
> Sent: Friday, October 15, 1999 12:24 PM

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 15 Oct 1999 13:26:40 -0700

If the home domain authenticates the mobile, then the FA can have some
pretty good guarantees that the NAI wasn't spoofed.

PatC

---

From: Emad Qaddoura <[email-masked]>
Date: Fri, 15 Oct 1999 16:59:20 -0500

> From: Walsh, Patrick J. [mailto:[email-masked]]
> Sent: Friday, October 15, 1999 2:59 PM

The compromise would be if the FA is possibly a cloned one. Would you agree?

> valid and hasn't been spoofed?
[...]

---

From: "n. asokan" <[email-masked]>
Date: Mon, 18 Oct 1999 09:27:33 +0300

Matthew Ford wrote:
| Can anyone be bothered to explain to me why an NAI like
| [email-masked] is preferable to [email-masked]?

There isn't a big difference between the two, and therein lies the
potential problem.  If a user doesn't care about privacy (and many
users may not), then using either is fine.  If a user does care about
privacy, [email-masked] is not much better than [email-masked]
if [email-masked] is also an unchanging identity whose activities over
time can be linked.

Perhaps the most serious privacy concern we need to guard against is a
sensationalist headline along the lines 'IETF mobile-IP forces users
to lose their privacy' (as some recent press coverage attempted w.r.t
ipng stateless address autoconfiguration).  I agree that there may not
be a burning need to develop privacy protecting mechanisms right now.
It might be sufficient to just check that we don't require users to
reveal more information than necessary.

PatC, in reply to PatW wrote:
|
| If the home domain authenticates the mobile, then the FA can have some
| pretty good guarantees that the NAI wasn't spoofed.
|
|                   PatC
| >It makes sense to have a requirement "to protect user confidentiality".
| >However, I'm still not sure what confidentiality is compromised by an FA
| >being able to see the user part of the NAI (user@domain).   To put it
| >another way, how does the FA know that the user identified in user@domain is
| >valid and hasn't been spoofed?

I agree.  For example, if a suitable AAA backend exists, FA may not
care who 'user' is, as long as it receives authorization from the AAA
cloud. Therefore, if mobile IP does _not_ require that the foreign
domain _authenticate_ the mobile user, we won't be precluding later
provision of anonymity.

- Asokan

---

---

From: "Lipford, Mark" <[email-masked]>
Date: Mon, 18 Oct 1999 08:36:15 -0500

Technically there is nothing wrong with this.  The problem is that is a user
is roaming on a wireless network (in my case a cdma2000 network) then the
NAI would be assigned by his home network, which may not be a wireless
network and not know anything about IMSI.  IMSI is a wireless network access
device identifier.  Our vision is that the terminal (PC, Palm, CE, etc.)
device will be what is roaming, not the cell phone.  If your solution is to
work it looks like the IT Admin would then have to create multiple types of
NAI's in their network.  One type would be IMSI@Domain <mailto:IMSI@Domain>
for the users that use wireless as an access medium.  Here the IMSI may need
to be the IMSI of the radio device that the user uses.  Another type of NAI
could be username@domain <mailto:username@domain> .  This could be used for
people that do not use wireless to access their network.

I guess there could be a single NAI type.   It could be any random set of
alphanumeric characters at the domain.

I have no issues with your thoughts, but I do believe there are some
implementation issues that would need to be addressed.  There was a response
from someone that indicated that the NAI is not transmitted in the open over
the air .  Once the access device (cdma2000 radio) is authenticated all over
the air messaging and signaling is encrypted.  Since this is the case the
NAI is not seen until the FA receives it.  Since the NAI will need to know
the home domain to forward the registration message to, it seems to me that
having the FA know the NAI is not an issue.

Regards

        ----------
        From:  Patrice Calhoun [SMTP:[email-masked]]
        Sent:  Friday, October 15, 1999 9:38 AM
        To:  [email-masked]
        Subject:  Re: [MOBILE-IP] Lack of User privacy - IS it a security
problem ?

        PatC