Subject: [MOBILE-IP] true user privacy (Was: Re: Interim WG meeting minutes posted)

From: Tom Weckström <[email-masked]>
Date: Fri, 11 Feb 2000 16:14:00 +0200

I send this discussion also the the MIP mailing list just to let you
know...

Is there any need for a REAL user privacy? (If we consider the use of
non-trivial NAIs not true privacy.) Will MIP WG be interested to think
about a solution for a true privacy, and when, if so? Or is the 'CrYpTeD
NAIs' e.g. [email-masked] enough?

Below some discussion and suggestions...

Patrice Calhoun wrote:
> see below.

as well... :)

>
> >Patrice Calhoun wrote:
> >>
> >> In the context of Mobile IP, it means that the roaming user provides an
> >> identity that is encrypted in a way that only the home can decrypt it.
> >>
> >> The issue I have with this requirement, is that it is very difficult to
> >> get REAL privacy (given the state of the protocol). Without some challenge
> >> of some form (or some unique random data), the encrypted text is always
> >> the same, providing encryption, but not privacy. The ISPs can look for
> >> the same sequence of binary bits to identify the user.
> >
> >You are right. REAL privacy would probably mean that the ISPs would not
> >get any static ID with which to refer to the user (and with which to
> >build e.g. user statistics, profiles, etc.). This clearly requires true
> >random idientifiers for users for each registration, AAA session, or
> >other renewable entity.
> >
> >Encypting the user identity so that only the AAAH, HA (or UHO in
> >gengeral) can decrypt it, brings still quite a bit more privacy.
> >Actually, this might be a desired solution from ISPs' point of view,
> >since they might want to build user profiles to learn how their services
> >are used. However, linking the encrypted string to a specific user is
> >very hard, if all you have is the short string (let's say we would use a
> >SHA-1 has from a bunch of data about the user).
>
> My point of view on this one is simply to use a cryptic (non-encrypted)
> NAI. Something along the lines of [email-masked] is just as
> good as an encrypted, and constant, value.
>
> >
> >>
> >> More work is needed in Mobile IP to really understand how this can be
> >> done.
> >>
> >> PatC
> >
> >Yes, indeed. More work is needed, and the goal is quite novel, I think.
> >So why was this requirement dropped, then?
>
> Because the IESG wanted to have a reasonable set of goals that the WG could
> achieve. Once the requirements are set, one could always bring in an
> I-D that proposes how this can be done, and specifically how it maps to
> the specific application being used (Mobile-IP in this case).
>
> The above is my understanding, I am not speaking for the IESG in this case
> (nor have I ever).
>
> >
> >I think even a more complete privacy is achievable. Just my 2 cents in a
> >form of a 'quick sketch suggestion':
> >
> >The mobile user could use a has of his usercode and a one time passwords
> >as his identifier. The one time password could be obtained the same way
> >as Secure-ID produces its one-time-passwords - through a seeded random
> >number gengerator at both ends (AAAH, MN). The AAAF would only know the
> >random hash. The recalculation of the one-time-password could be user
> >initiated, or timer-based...
>
> Of course, this requirements an additional Mobile IP message to the Mobile
> Node to issue the challenge. As far as PPP is concerned, this can easily
> be done via EAP, but in Mobile IP, there isn't a way to issue the
> challenge from the AAAH to the Mobile. This is primarily because the
> adv that contains the challenge is not generated by the AAAH (since the
> FA still has no idea what mobiles are in it's service area).

(Note, that my term 'password' is just a term for a random renewable
string, that can  be used in en/decrypting the NAI.)

My idea did not have anything to do with FA advertisements... nor
challenges.
MN would just renew the password and then inform the AAAH/HA to do the
same. All we need is an extension / a bit telling that MN has renewed
its password. Since the seeds would be the same, AAAH/HA would be able
to calculate the new password, too.
The other option was to have this automated so, that the new passwords
would be generated every X minutes. This, of course requires clock
synchronization. NTP should do.

>
> So, we (Mobile-IP) need to be a little more clear in how we would actually
> support encrypted NAIs before we can make this a real requirement, IMHO.
>
> PatC

OK. Thanks for telling the background.

Maybe the use of "scrambled" NAIs is then enough for now.
If needs arise and good solutions are proposed, maybe MIP WG can provide
a draft for TRUE privacy then... :)

Regards,
         Tom

> >
> >
> >Regards,
> >        Tom
> >> >Perhaps I misunderstand the reason for having "Anonymous Access" but if it
> >> >means what I think we have discussed in the past, it would be of value to
> >> >ISPs who offer free trial and sign-up services.
> >> >
> >> >Richard
> >> >
> >> >On Fri, 11 Feb 2000, Tom Weckström wrote:
> >> >> In the meeting minutes it says:
> >> >>
> >> >> "Anonymous Access: Can we remove this requirement?
> >> >> Answer: Yes. "
> >> >>
> >> >> I would like to get justifications for the removal.
> >> >>
> >> >> To me, removing this requirement would mean that I would always have to
> >> >> reveal my identity to the network operator.
> >> >> Am I correct?
> >> >>
> >> >> It does not matter, if my Home organization AAA knows my identity, but I
> >> >> would like to remain anonymous for service providers. If this
> >> >> requirement is not fulfilled, then the loads of information the AAAF
> >> >> stores may in some occasions be very harmful to roaming users when
> >> >> misused. Anonymity would protect roaming users from this kind of terror.
> >> >
> >> >
> >

--
        Tom Weckström           [email-masked]
        Otakaari 20 B 39        Helsinki University of Technology
        02150 Espoo             Department of Computer Science
        09-4683249/040-5642709  http://www.niksula.cs.hut.fi/~tweckstr