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

From: "N. Asokan" <[email-masked]>
Date: Wed, 27 Oct 1999 16:20:17 +0300

Mohamed et al,

MIER is a nice and timely draft. Some comments and suggestions follow.

Encrypting NAI
--------------

We're assuming that what you had in mind was encrypting the user part
of the NAI with a key shared between the MN and the home domain (perhaps this
should be stated explicitly).

It is too strong to say that the "identity is fully hidden from the FA" as a
result (KENA, Section 7.2).  The SPI value, sent in the clear, has to
uniquely identify the NAI within the home domain.  Therefore, two different
registration requests of the same NAI can be linked by any onlooker (not just
the FA).  Perhaps this level of privacy is satisfactory for many users.  But
two things should be noted:

- 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.
- as a comparison, this level of privacy is _less_ than what is provided
  by the TMSI in GSM, where two different TMSIs used by the same IMSI
  cannot be linked.

On the other hand, the way you have defined the NAI extension can easily
support other forms of stronger privacy by way of a small modification.
Define the NAI extension as follows:

        Type | length | content-type | NAI-type
        NAI-INFO

where
        content-type is as you have defined (a better term in this case could
           be 'role-type')
        NAI-type is one of
                0 : shared-key encrypted user part (i.e., as you have
                     defined; hides the real NAI from FA and onlookers, but
                     does not provide unlinkability)

                    alternatively, since encryption doesn't buy any
                    additional protection, this NAI-type number can stand for
                    'no user-part in NAI'

                1 : public-key encrypted user part
                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)
                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.

People have argued that strong privacy is an overkill and/or a non-urgent
matter. Perhaps it is so.  But something like the above comes at little or no
cost and provides a good hedge so that if someone some day decides they want
strong privacy, we have the hooks to provide it.

Non-skippable jumbo extensions
------------------------------

It was observed by others (e.g., in the vendor-specific extensions draft)
that we can afford to have a 16-bit length field for non-skippable
extensions.  Would it make sense to have a general format for non-skippable
jumbo extensions like:

        Type (non-skippable) | reserved | content-type | reserved
        Extended-type (16 bits)         | Extended-type length (16 bits)

so that we use up only one non-skippable extension type to extend both the
non-skippable extension type identifier space, as well as the size of future
non-skippable extensions?

If space is a concern, it could be something like

        Type (non-skippable) | content-type | Extended-type length (16 bits)
        Extended-type (16 bits)

The exact format is not important, but the basic suggestion is to include, as
part of your rationalization, a standard way to define all future
non-skippable extensions.

Regards,
 - Asokan
 - Patrik Flykt

---
N. Asokan, Communication Systems Lab, Nokia Research Center, Helsinki

---

From: Mohamed Khalil <[email-masked]>
Date: Wed, 27 Oct 1999 17:10:10 -0500

The fundamental goals of MIER are two fold:-

                        -Conserve the 'type' space, since there is a real
dange that we may run out of them
                        -Define an extension format such that encryption may
be optionally applied

                                -----Original Message-----
                                From:   N. Asokan [SMTP:[email-masked]]
                                Sent:   Wednesday, October 27, 1999 8:20 AM
                                To:
[email-masked]
                                Cc:     Khalil, Mohamed [RICH2:IP15:EXCH]
                                Subject:        Comments on the MIER draft

                                Mohamed et al,

                                MIER is a nice and timely draft. Some
comments and suggestions follow.

                                Nortel> Thanks... we believe that too and
think it will fundamentally change the new extension
                                >formats impacting a some drafts currently
under consideration.

                                Encrypting NAI
                                --------------

                                We're assuming that what you had in mind was
encrypting the user part
                                of the NAI with a key shared between the MN
and the home domain (perhaps this
                                should be stated explicitly).

                                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?

                                It is too strong to say that the "identity
is fully hidden from the FA" as a
                                result (KENA, Section 7.2).  The SPI value,
sent in the clear, has to
                                uniquely identify the NAI within the home
domain.  Therefore, two different
                                registration requests of the same NAI can be
linked by any onlooker (not just
                                the FA).  Perhaps this level of privacy is
satisfactory for many users.  But
                                two things should be noted:

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

                                - as a comparison, this level of privacy is
_less_ than what is provided
                                  by the TMSI in GSM, where two different
TMSIs used by the same IMSI
                                  cannot be linked.

                                On the other hand, the way you have defined
the NAI extension can easily
                                support other forms of stronger privacy by
way of a small modification.
                                Define the NAI extension as follows:

                                        Type | length | content-type |
NAI-type
                                        NAI-INFO

                                where
                                        content-type is as you have defined
(a better term in this case could
                                           be 'role-type')
                                        NAI-type is one of
                                                0 : shared-key encrypted
user part (i.e., as you have
                                                     defined; hides the real
NAI from FA and onlookers, but
                                                     does not provide
unlinkability)

                                                    alternatively, since
encryption doesn't buy any
                                                    additional protection,
this NAI-type number can stand for
                                                    'no user-part in NAI'

                                                1 : public-key encrypted
user part

                                Nortel> I think the SPI is needed in public
key too because the home domain might use different types of >public key
algorithms with different set of private keys.
                                                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 ?

                                                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.

                                People have argued that strong privacy is an
overkill and/or a non-urgent
                                matter. Perhaps it is so.  But something
like the above comes at little or no
                                cost and provides a good hedge so that if
someone some day decides they want
                                strong privacy, we have the hooks to provide
it.

                                It was observed by others (e.g., in the
vendor-specific extensions draft)
                                that we can afford to have a 16-bit length
field for non-skippable
                                extensions.  Would it make sense to have a
general format for non-skippable
                                jumbo extensions like:

                                        Type (non-skippable) | reserved |
content-type | reserved
                                        Extended-type (16 bits)         |
Extended-type length (16 bits)

                                so that we use up only one non-skippable
extension type to extend both the
                                non-skippable extension type identifier
space, as well as the size of future
                                non-skippable extensions?

                                If space is a concern, it could be something
like

                                        Type (non-skippable) | content-type
| Extended-type length (16 bits)
                                        Extended-type (16 bits)

                                The exact format is not important, but the
basic suggestion is to include, as
                                part of your rationalization, a standard way
to define all future
                                non-skippable extensions.

                                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 ?

                                Regards,
                                 - Asokan
                                 - Patrik Flykt

                                ---
                                N. Asokan, Communication Systems Lab, Nokia
Research Center, Helsinki