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

From: Mohamed Khalil <[email-masked]>
Date: Thu, 28 Oct 1999 10:03:32 -0500

Hi Asokan and Patrik,

        I found your comments is extremely useful to the issues of user
privacy and managing the space of extension more efficiently so I found that
it be more useful if we share our thoughts  with the WG. This is any way
what is the WG mailing list is created for.

> -----Original Message-----
> From: N. Asokan [SMTP:[email-masked]]
> Sent: Thursday, October 28, 1999 3:38 AM
> To:   Khalil, Mohamed [RICH2:IP15:EXCH]
> Cc:   Patrik Flykt
> Subject:      RE: Comments on the MIER draft
>
>
> Hi Mohamed and others,
>
> On Wed, 27 Oct 1999, EXT Mohamed Khalil wrote:
> [....]
> |     Nortel >In the matter of fact I have in mind to encrypt the
> | MN-NAI entirely because the
> | > domain name sometimes doesnot carry enough routing information to
> | deliver control
> | >messages. To clarify the previous point let me ask the following
> | question, how the HAAA
> | >delivers the AAA-registration request targeted to specific HA if we
> | assume that the
> | >home domain has multiple HAs? similarily how the FAAA delivers
> | AAA->Registration
> | >Reply back to a specific FA if we assume that the foreign domain has
> | multiple FAs?
> |
> [...]
>
> 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.
>
> |
> |     - for this level of privacy, no encryption is needed.  Just omit
> | the user
> |   part of the NAI.  Home domain will be able to uniquely identify the
> | user
> |   based on SPI alone.
> |
> |     Nortel> I think I missed your point how the SPI (Security
> | Parameter Index) will be used to uniquely identified > the user ?
>
> I guess you are thinking about multiple NAIs using the same MN. In
> that case, we agree that the SPI alone is not sufficient for the home
> domain to uniquely identify the user.  However, the point about
> linkability remains: typically only one (or a small number of) NAI(s)
> will be in use by the same MN.  This means using the same SPI value in
> subsequent registrations. Thus the SPI value leaks information to anyone
> who can see the registrations made from the MN. Therefore the NAI is not
> 'fully hidden'.
>
        Nortel> 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 ?

> [....]
> |
> |                     2 : secret-key encrypted user part (using a
> | secret-key known
> |                      only to the home domain; this means that home
> | domain has
> |                      to provide a new NAI periodically, e.g.,
> piggy-back
> | it
> |                      in every successful registration reply)
> |
> |     Nortel> I wonder if the MN does not know this secret key then
> | how it will decrypt the NAI ?
>
> MN does not need to decrypt this temporary NAI (someone coined the
> term T-NAI) - MN uses it as an opaque token: a temporary alias.  When
> a registration request with a T-NAI comes in, the home domain can
> efficiently figure out the corresponding real NAI by decrypting the
> T-NAI. MN simply keeps the T-NAI "token" in its storage and uses the
> T-NAI "token" until it gets a new one from the home domain (it could get
>
> a new one in every registration).  Two different T-NAIs used by the same
> NAI cannot be linked by anyone other than the home domain.  Thus, it
> provides the same level of untraceability and unlinkability as the GSM
> TMSI while avoiding any synchronization problems.
>
        Nortel> I think TNAI solution will create an extra implementation
complexity and management problems which can be avoided by simply encrypting
the user NAI
> |
> |                     etc.
> |
> |     If NAI-type is 0, NAI-INFO starts with a 32-bit SPI.  The other
> | two NAI-types
> | do not require an SPI.  The latter two types of NAI also provide
> | unlinkability.
> |
> |     Nortel> This makes it restrictive since we do not know if at
> | some future date if we would need
> | > encryption or not.
>
> Let me try to rephrase our observation.  To hide the real NAI, you
> have to replace it with a pseudonym.  The pseudonym can be computed in
> many ways.  The best ways involve encryption of some sort.  But you
> can also have pseudonyms that are derived by other means.  So the NAI
> sent in the registration request could be
>
> 1 unencrypted real NAI
> 2 pseudo-NAI (T-NAI) assigned and updated by the home domain (a la TMSI)
> 3 NAI encrypted with key shared between MN and home domain
> 4 NAI encrypted with the home domain's public key
> 5 pseduo-NAI (T-NAI) computed by the home domain by encrypting the NAI
>   with a secret key known only to the home domain (a la TMSI but without
>   its synchronization problems)
> 6 ...
>
>
>
> 1 and 2 do not use encyrption.  2-5 do.  You can support all of these
> forms in your current format by reserving some of the SPI values for
> these purposes.  However, we think it is cleaner to define the above as
> NAI-types (e.g., by using the E bit as you have defined, plus using the
> remaining reserved bits), and use the SPI in the usual sense when a
> shared key is used.
>
        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.

> [...]
> |     Nortel> Skippable or non skippable should really be a part of
> | the message definition
> | > rather than a charaterisitic of the extension. Did we miss something ?
> [...]
>
> Yes, we are not suggesting that you should decide whether an extension
> is skippable or not.  But rather, if someone decides that their new
> extension is non-skippable, then they can follow a standard format
> that you (could) define in your MIER draft.  Doing so would seem to be
> consistent with your goal of conserving 'type' space.
>
> Regards,
>
> - Asokan
> - Patrik
>
        Regards,

        M K

---

From: "N. Asokan" <[email-masked]>
Date: Fri, 29 Oct 1999 08:38:16 +0300

Hi Mohamed,

On Thu, 28 Oct 1999, EXT Mohamed Khalil wrote:
|       Hi Asokan and Patrik,
|
|       I found your comments is extremely useful to the issues of user
| privacy and managing the space of extension more efficiently so I found
| that it be more useful if we share our thoughts  with the WG. This is
| any way what is the WG mailing list is created for.

Ok, we can continue this discussion on the mailing list.  I took it
off-line because I thought a long message on privacy issues will be
considered a waste of bandwidth in the WG if most people in WG consider
privacy to be a non-issue or a non-urgent issue.

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

[...]
|       Nortel> 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.

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

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

Regards,
- Asokan

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