Subject: [MOBILE-IP] KENA - Comments and questions

From: "BINAR, Simon" <[email-masked]>
Date: Mon, 1 Nov 1999 16:12:07 -0000

Hello again.

I would have a comment and a couple of questions for clarification about
the KENA draft.

At first, one comment. The draft mentions that a security requirement
should be to only reveal the user's identity (his NAI, or his MN's IP
address) once the FA has been authenticated by the HA. However, it has
been also mentioned that this would not allow implementation of dynamic
HA allocation (I think such a dynamic allocation is a good thing, if
just to be able to do load sharing between multiple HAs).

It was then proposed that the MN should encrypt the user part of the
NAI, while the domain part (to be used by the FA) would be sent as plain
text. Some people now say that this is too complex to implement. So now,
obviously, we are in a dilemma... Are there any suggestions of how to
get out of this dilemma?

BTW, I believe that sending the user's NAI in plain text can compromise
at least the privacy of the organisation to which the user belongs. If
the same NAI is always used, the foreign domain could gain information
about the movement of specific mobile nodes/users in the network.

Furthermore, with access to location information (which will be a
standard feature of 3G systems), it could be even possible for the
foreign network to find out the following type of information: "People
from BIG COMPANY have been recently increasing their visits to SMALL
COMPANY, which is actually financially in a bad situation and whose
products could fit neatly into BIG COMPANY's portfolio". This is
definitely NOT the type of information BIG COMPANY wants to become
available to anyone... Thus, even if user privacy might not be that much
at stake (using NAIs that don't say much), a company's privacy could be
compromised.

Thus, somehow, the foreign domain/agent should first be authenticated by
the home domain/agent before the user's NAI becomes available to the FA.
Which brings us back to the original dilemma...

Now a few quick questions about the KENA draft:

- If a secured link already exists between the MN and HA (using SS1) and
between the FA and HA (SS2), why is it necessary to establish new shared
secret keys for the same links? Are these keys (SS1 and SS2) shared by
many MNs registered with the same home domain? If this is so, how could
the distribution of the keys K1 and K3 be safe, if other MNs from the
same home domain and connected to the same FA could be listening to the
distribution of these keys as well? If these keys are unique (i.e.,
especially SS1 reflects a 1-to-1 association between a MN and its HA),
why is a new shared secret key required?

- Would the Key K3 be distributed to all FAs in the foreign domain (or
to all FAs that are neighbour to the current "serving" FA), or would it
be necessary to undergo the proposed key distribution process whenever
the MN hands over from one FA to another?

----------------------------------------------
Simon Binar
NEC Europe Ltd.
Tel:   +44 (0)1753 606933
Fax:   +44 (0)1753 606901
EMail: [email-masked]
-----------------------------------------------
DISCLAIMER:  Any views or opinions expressed in
this E-Mail message should be considered as the
personal views/opinions of the author.  They do
not  necessarily  represent  the  views  of the
author's employer.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 1 Nov 1999 08:45:27 -0800

[SNIP]

> about the movement of specific mobile nodes/users in the network.

What exactly am I missing here? The foreign domain needs to know the
organization that the user belongs to. Otherwise, how would billing
occur?

Furthermore, in the cellular networks, the VLR and EIR already keep track of
the mobiles in the local network, so this information is already tracked,
independant of Mobile-IP.

>at stake (using NAIs that don't say much), a company's privacy could be

Of course, BIG COMPANY and SMALL COMPANY could setup a direct business
relationship, and the AAA messages would not have to traverse any third
party AAA servers.

[SNIP]

So, to re-state my previous question, what are we achieving here?

PatC