Subject: [MOBILE-IP] New Registration Keys draft

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Feb 2000 14:43:34 -0800

Hello folks,

I would like to revise the existing Registration Key draft to
take into account the possibility for managing Registration Keys
delivered by the mobile node to the new foreign agent, as indicated
in a recent draft by Pat Calhoun et.al.  I believe that the handling
for the latter draft will stay the same in the Registration Keys
draft, even as the specifics of the opaque data mechanism evolve.

The Registration Keys draft has already been updated, although not
finished, to define two new Generalized Registration Key extensions
-- namely, a Key Request extension and a Key Reply extension.  All
of the previous extensions for Key Request and Key Reply are now
subtypes of one of those generalized extensions.  The opaque data
extension is a subtype of the Generalized Key Reply extension.

Lastly, I would like to change the default key-exchange algorithm.
In the old draft, it was Diffie-Hellman exchange using the
modular exponentiation group.  For some years now it has been
known that using the elliptic curve groups is _much_ faster
computationally.  Furthermore, it has been made clearer that
assigning key exchange responsibility to the foreign agent and
the home agent, instead of the mobile node, offers several advantages.
Since the modular exponentiation algorithm has not been widely
implemented, I suspect that changing the defaults will not cause
any significant hardship.  And, it could offer quite significant
benefits for the future.

I mentioned this strategy in an earlier note, and it was pointed
out that not all foreign agents would be willing to carry out
a Mobile IP registration, much less one with a key exchange,
without some sort of authentication of the mobile node.  If this
is a concern, then such foreign agents may require the mobile node
to already come equipped with a Registration Key (perhaps from a
previous registration).  The elliptic curve algorithm to be used
in this Registration Key draft will not serve the needs for such
foreign agents.  On the other hand, if someone would like to figure
out how to make the adaptation, I would be very interested to look
into making the necessary changes.

Unless someone offers a better solution, I will probably specify
some default parameters from the "well-known group" GF(2^185),
as discussed in appendix E.4 from RFC 2412, using the suggested
generating point (24,13) and so on.  I can also enable the mobility
agents to exchange optional fields to select non-default parameters.

Your comments are requested.

Thanks,
Charlie P.

---

From: FUKUMOTO Atsushi <[email-masked]>
Date: Mon, 14 Feb 2000 15:32:29 +0900

Charlie Perkins wrote:
> generating point (24,13) and so on.

I'm no cryptographer, but, wasn't the GF(2^185) questioned its
strength in IPSec group, and incompatible with other standards such as
IEEE, ANSI, or NIST recommendation?
(ref. draft-ietf-ike-ecc-groups-01.txt)

                                        FUKUMOTO Atsushi
                                        [email-masked]