Subject: Re: [MOBILE-IP] Comments on the MIER draft

From: Mohamed Khalil <[email-masked]>
Date: Fri, 29 Oct 1999 11:37:09 -0500

Hi Asokan and Patrik,

> -----Original Message-----
> From: N. Asokan [SMTP:[email-masked]]
> Sent: Friday, October 29, 1999 12:38 AM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] Comments on the MIER draft
>
> Hi Mohamed,
>
> [...]
> |       If you encrypt the whole NAI, then do you have some other means
> | in
> | mind for the foreign domain to figure out where the home domain is?
> | (Perhaps you are suggesting the use of 'home address';  what if there
> | is no home address?)
> |
> |       Nortel> We are expecting that the HA, FA as well as the MN will
> | be identified by an NAI. If the MN knows its HA, then it will add its
> | HA's NAI to the registration request sent to the FA. The FA will build a
> | AAA message which contains the HA's NAI and forward the message to the
> | FAAA. The FAAA will use the HA's NAI to forward the AAA Registration to
> | the proper distination.
>
> Ok, so from a privacy point-of-view, this is the same as encrypting only
> the user part of the NAI since you will be identifying the home domain in
> the clear.
>
>
>
MK>We don't beleive encrypting the whole NAI or user part alone has any
     significance the Home Agent field has the IP address of the HA. It is
simpler
     and more efficient to encrypt the whole NAI rather than just the user
part.

> [...]
> |  The SPI might be shared by many users and the home
> | domain at the same time  so i don't think that it can be used to
> | uniquely identify the user. Since the SPI is encapsulating the SA
> | association information which  is known only by the two parties sharing
> | this security association, i don't know how sending SPI in the clear
> | will leak any information ?
>
> I am not quite sure what the above means.  As I see it, it could mean two
> things (please correct me if I am wrong).
>
> [In the discussion below I take 'no leakage of information' to mean 'an
> attacker can only tell which domain the user is from but nothing else'.
> i.e., the attacker cannot narrow the user down to a smaller group than the
> set of all users in the home domain.  This is consistent with the standard
> notion of leaking information from a security point of view.]
>
>
> 1. All (or many) MNs from the home domain use the same SPI for encrypted
>    NAIs. But the SPI refers to an SA-bundle containing N SAs, each of
>    which is shared between only one MN and the home domain.
>
>    If so, each time a registration request with an encrypted NAI
>    comes in, the home domain has to walk through each SA in the SA-bundle
>    performing trial decryptions because it has no other information to
>    identify the correct SA.
>
>    If N is large, this can be very expensive.  If N is small, the SPI
>    leaks information about the NAI (if 10 NAIs share an SPI, then the
>    SPI indicates that the NAI is one of those 10).
>
>
> 2. All (or many) MNs from the home domain use the same SPI pointing to
>    a single SA shared by the home domain and N mobile nodes.
>
>    If this is correct, then the home domain and N mobile nodes share a
>    security association corresponding to the key SS1 (as in your KENA
> draft).
>    I am pretty sure you don't mean this because in the KENA draft you
>    indicate that session keys MN-FA, and MN-HA are delivered to the mobile
>    encrypted with SS1 (e.g., Figure 2).  If SS1 is shared among many
> users,
>    you couldn't use it for this purpose.  You really have to use the long
>    term key shared between MN and HA.
>
>    But just in case you meant this:
>
>    If N is large (in the best case, all the mobile nodes from the home
>    domain), then the SPI indeed does not leak any information.  However,
> you
>    will have the usual logistical problems that arise out of sharing the
> same
>    secret among a large number of parties:
>    - MNs do not have untraceability with respect to other MNs from its
> home
>      domain.  Any other user who shares the same SPI with me will be able
>      to recognize my registration requests (over the air, or in the wired
>      network).  Again, this is a lower level of privacy than provided by
> GSM
>      TMSI.
>    - Each user has to trust all other users to adequately protect the
> shared
>      key.  If one user is compromised, all other users could potentially
> lose
>      their privacy.  Detecting a compromised server (such as HA or HAAA)
> is
>      relatively much easier than detecting compromise on an MN,
>
>    If N is small (in the best case, 1) the impact of these problems is
>    reduced.  But there is a corresponding increase in the amount of
>    information leaked.  Again, if 10 users share the key... etc.
>
MK> SS1 is a key which could be secret or public. In both cases the
relationship
is many [MNs] to 1 [home domain]. In the case of shared secret key, a
particular
key and SPI are randomly distributed to many users. This ensures that there
no
privacy is lost with SPI being in the clear. If we use a
public key encryption then this problem doesn't exist any more. To
give an example assume that the MN encrypts its NAI using the home
domain's public key so the only one who can decrypt the NAI is the
home domain because the home domain is the only one who owns the
private key. If the home domain wants to respond back, it  encrypts
information using the public key of the MN and the MN will decrypt
this information  using the private key which is only known by the
MN. The SPI is just a pointer to SA table which defines some
information required in case of enc/dec such as the type of enc/dec
alg. etc. Since, this process is inefficient, so we use this mechanism
to transfer safely the other secret keys (K1, K2, K3) which will be
used in the future for encryption/ decryption process.

> [...]
> |
> |  I think TNAI solution will create an extra
> | implementation complexity and management problems which can be avoided
> | by simply encrypting the user NAI

        MK>I hope that the example I mentioned above showed that the
encryption of NAI doe not provide any lower level of privacy

> It certainly provides the same level of privacy as GSM TMSI, while it
> seems to me that the 'encrypt the NAI with a shared key' approach either
> provides a lower level of privacy (when N is small) or significantly
> increases overhead (when N is large).  But as I said, I could still be
> misunderstanding what your real solution is.
>
>
> [...]
> |       Nortel>Those are good ideas but I guess it will be more useful
> | to encapsulate these information as part from the SPI instead of sending
> | it in the clear.
> [...]
>
> Ok.  I guess in the end, it is a subjective decision: it seemed to me that
> instead of using the 'E' flag to differentiate between 'encrypted NAI' and
> 'non-encrypted NAI', it would be cleaner to use more bits to encode 'NAI
> type', where some types are encrypted and some are not.  It makes it clear
> th
>
> at encryption is just one method to generate pseudonyms.
>
> It is true that one could encode the NAI type in the SA.  In that case,
> one could also not use the E flag at all, but use the SPI to indicate to
> the home domain how to interpret the NAI field (e.g., SPI=0 indicates
> unencrypted real NAI).
>
>
>
        MK>The approach of E flag is more efficient because if E= 0, you
don't to include SPI in your message (4 bytes) If E=1 then the SPI will
define completely all types of encryption you mentioned before

> Regards,
> - Asokan
        Regards

         Mohamed
> ---
> N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki
> E-mail: [email-masked],  [email-masked] (private)
> Phone:  +358 40 743 1961; PGP Key for private use at
> http://www.acm.org/~asokan

---

From: "N. Asokan" <[email-masked]>
Date: Sat, 30 Oct 1999 09:45:01 +0300

Hi Mohamed,

On Fri, 29 Oct 1999, EXT Mohamed Khalil wrote:
[...]
|
|          But just in case you meant this:
|
|          If N is large (in the best case, all the mobile nodes from
| the home
|    domain), then the SPI indeed does not leak any information.  However,
| you
|    will have the usual logistical problems that arise out of sharing the
| same
|    secret among a large number of parties:
|    - MNs do not have untraceability with respect to other MNs from its
| home
|      domain.  Any other user who shares the same SPI with me will be
| able
|      to recognize my registration requests (over the air, or in the
| wired
|      network).  Again, this is a lower level of privacy than provided by
| GSM
|      TMSI.
|    - Each user has to trust all other users to adequately protect the
| shared
|      key.  If one user is compromised, all other users could potentially
| lose
|      their privacy.  Detecting a compromised server (such as HA or HAAA)
| is
|      relatively much easier than detecting compromise on an MN,
|
|          If N is small (in the best case, 1) the impact of these
| problems is
|    reduced.  But there is a corresponding increase in the amount of
|    information leaked.  Again, if 10 users share the key... etc.
|
| MK> SS1 is a key which could be secret or public. In both cases the
| relationship
| is many [MNs] to 1 [home domain]. In the case of shared secret key, a
| particular
| key and SPI are randomly distributed to many users. This ensures that
| there no
| privacy is lost with SPI being in the clear. If we use a
| public key encryption then this problem doesn't exist any more. To
| give an example assume that the MN encrypts its NAI using the home
| domain's public key so the only one who can decrypt the NAI is the
| home domain because the home domain is the only one who owns the
| private key. If the home domain wants to respond back, it  encrypts
| information using the public key of the MN and the MN will decrypt
| this information  using the private key which is only known by the
| MN. The SPI is just a pointer to SA table which defines some
| information required in case of enc/dec such as the type of enc/dec
| alg. etc. Since, this process is inefficient, so we use this mechanism
| to transfer safely the other secret keys (K1, K2, K3) which will be
| used in the future for encryption/ decryption process.

The public key case is blindingly obvious.  I have no problems with that.

So take the secret key case.  You do not respond to the points I raised
(quoted above).  Suppose N is large: say I share SS1 (a shared secret key)
with 10,000 users.  Any of these 10,000 can recognize the SPI in my
registration request and decrypt it to find my real identity and find out
where I have been roaming.  Do you consider "no privacy is lost" in this
case?  Any of these 10,000 can recover session keys K1, K2 and K3 which
were intended only for my use and then masquerade as me.  Do you consider
this to be "transfer safely"?  Again, I am not talking about the public
key case.  I am talking about the case you illustrate in your KENA draft,
where you say "SS1 is a shared secret that is predefined between the MN
and HA".

The fact that the N users sharing SS1 are chosen randomly does not help
much.  It is true that the adversary who wants to attack a specific victim
will find his job harder.  But a mobile user who cares about privacy is
not going to be able to sleep any easier knowing that 10,000 randomly
chosen others have the ability track his movements or steal his session
keys.

In addition to the degradation of security, you have other problems (see
quoted text above) that arise when one key is shared among many partners.

I still _hope_ that I am completely missing your point!

|       [...]
| |
| |  I think TNAI solution will create an extra
| | implementation complexity and management problems which can be avoided
|
| | by simply encrypting the user NAI
|
|
|       MK>I hope that the example I mentioned above showed that the
| encryption of NAI doe not provide any lower level of privacy

Not yet.  Again, the public key case is obvious.  The T-NAI approach
provides the same level of privacy to mobile nodes which are not able to
do public key cryptography.

[...]
|
|       MK>The approach of E flag is more efficient because if E= 0, you
| don't to include SPI in your message (4 bytes) If E=1 then the SPI will
| define completely all types of encryption you mentioned before
[...]

Not quite.  I am still assuming that you want your scheme to be general
enough to cover many possible means of providing privacy.  If you are not
interested in that, then the following comment does not apply.

Consider the approach where the home domain assigns temporary aliases to
mobile nodes (a la the TMSI approach).  This involves no encryption by the
mobile node.  Therefore, they will set E to 0.  However, there can be more
than one way by which the home domain computes the aliases (two trivial
examples: the T-NAI approach where home domain computes T-NAI by
encryption, and the random alias approach, where home domain has to
maintain a table of alias->real-NAI mappings).  In other words, the
registration request should identify the "algorithm" that the home domain
should use to interpret the NAI in the request.  For this you need an SPI.
Either that, or you include a specific NAI-type in the NAI extension
field.

Regards,
- Asokan

---