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

From: Raja Narayanan <[email-masked]>
Date: Mon, 1 Nov 1999 13:03:24 -0600

Binar,

Comments prefixed with RN>

--Raja Narayanan
Nortel Networks

-----Original Message-----
From: BINAR, Simon [mailto:[email-masked]]
Sent: Monday, November 01, 1999 10:12 AM
To: [email-masked]
Subject: [MOBILE-IP] KENA - Comments and questions

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?

RN>Our intent here is to establish (per registration) session keys. SS1 and
SS2 capture the existence of a secure path such that keys K1, K2 and K3 and
corresponding SPI may be dynamically distributed. Security capabilities may
be different across serving networks and therefore the keys and SPI need to
be established dynamically.

RN>For your ref, there is another thread of discussion (raised by Asokan)
that pertains to the shared secret versus private public and 1 to 1 versus
many to 1.

- 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?

RN>It would be necessary to undergo the proposed key distribution process
whenever the MN handover from one FA to another and goes through the
registration process.

----------------------------------------------
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: Mohamed Khalil <[email-masked]>
Date: Mon, 1 Nov 1999 15:02:13 -0600

Hi  Binar,

look for MK for more comments.

> From: Narayanan, Raja [RICH1:IP14-I:EXCH]
> Sent: Monday, November 01, 1999 1:03 PM
> Subject:      Re: [MOBILE-IP] KENA - Comments and questions
>
> Binar,
>
> From: BINAR, Simon [ <mailto:[email-masked]>]
> RN>Our intent here is to establish (per registration) session keys. SS1
> and SS2 capture the existence of a secure path such that keys K1, K2 and
> K3 and corresponding SPI may be dynamically distributed. Security
> capabilities may be different across serving networks and therefore the
> keys and SPI need to be established dynamically.
>
        MK> I would like to add  that K1, K2, K3 (secret keys)  might be
used to encrypt data as well as control signals. Since SS1 and SS2 might be
public key so I don't think it is wise, for efficiency reasons, to encrypt
the data using public keys.

---

From: Raja Narayanan <[email-masked]>
Date: Mon, 1 Nov 1999 14:55:21 -0600

Comments prefixed by RN>

--Raja
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 01, 1999 10:45 AM
To: [email-masked]
Subject: Re: [MOBILE-IP] KENA - Comments and questions

[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?

RN> The obvious rationale here is that the users need to be protected from
malicious FAs. With respect to billing in particular, once the Home domain
has authenticated the FA [refer KENA], the registration response has
information regarding the mobile user that would let the FA bill.

|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.

RN> The [previously mentioned] issue with the example mentioned above is
that in cellular networks the implicit assumption is that serving VLRs are
trusted entities and known to the home domains --- as assumption which may
not be true in IP domains. In anycase building a malicious FA in a packet
switched IP domain would be easier than building a malicious VLR.

>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.

RN> The issue is not whether BIG COMPANY and SMALL COMPANY could setup a
direct businees relationship. The issue is whether a security model SHOULD
mandate them to do so and we think not. Binar's point regarding whether
encrypting user part of the NAI alone would suffice is quite valid. Also, we
are not limiting discussion to AAA/AAA messages. KENA draft identifies
implementation by extending Mobile IP.

[SNIP]

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

PatC