Subject: [MOBILE-IP] Registration Keys draft and D-H key exchanges

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 4 Feb 2000 08:29:44 -0800

Hello folks,

I'm still involved with revisions to the Registration Keys draft.
Currently, the draft requires a foreign agent supporting smooth
handoffs to implement Diffie-Hellman key exchange based on the
modular exponentiation group.  This facilitates the establishment
of keys when there is not any other security association available
with that particular foreign agent.  However, it turns out that
using an elliptic curve group instead is much faster computationally.
The algorithms for Diffie-Hellman key exchanges based on the elliptic
curve groups are becoming more well known.  Standards exist, and
in order to speed up smooth handoffs when such key exchanges are
needed I think it is prudent to make an elliptic curve algorithm
to be the default, instead of the way it is now with exponentiation.

I propose to make another basic change.  Right now, the key exchange
occurs between the foreign agent and the mobile node.  This, however,
requires passing a lot of data over the air.  It is possible, instead,
to have the foreign agent exchange a key with the home agent, and then
the home agent can send the key to the mobile node using the security
association between the mobile node and the home agent -- just as the
home agent already is specified to do in some other cases.

There are two points about this rearrangement.  First, it becomes
more important for the mobile node to be protected against the
man-in-the-middle attack that can interfere with some Diffie-Hellman
designs.  This can be done by having the foreign agent include a
short digest of its Diffie-Hellman computed value along with the
Agent Advertisement.  That will prevent (with high probability)
any interloper from getting in the way.  Secondly, this method
allows the home agent to know about the key between the mobile
node and the foreign agent.  That is a non-issue, however, for
several reasons:
- This is already true for proposed key establishments initiated by
  the AAA server in the home domain
- The home agent can't reasonably do anything with the key except
  shorten the registration lifetime of the mobile node at that
  foreign agent
- The foreign agent doesn't need to use the key for any other purpose
  except managing a smooth handover.  In other words, the fact that
  the home agent knows this key does not represent any security threat
  to the foreign agent.

Besides this business with D-H, I am making some minor revisions to the
current Registration Keys draft to take into account Pat Calhoun's
recent proposal for having the mobile node supply the registration key
to the new foreign agent.  That method for establishing the key
depends upon a pre-existing security relationship between the
foreign agents, and it will be listed as a subtype of the Generalized
Key Reply extension defined in the Registration Keys draft.

To summarize:
- I propose to make the Diffie-Hellman work by elliptic curve groups
  in the default case
- I propose to have the key established by an exchange between the
  foreign agent and home agent, to relieve computational and bandwidth
  requirements on the mobile node
- I propose a new extension to Agent Advertisements containing a
  32-bit digest for the D-H computed value to be used.
- I propose to add support for the recent proposal for passing opaque
  key data from the mobile node to the new foreign agent.

Comments will be appreciated!

Regards,
Charlie P.

PS. Elliptic curve computations are not as intuitive as exponentiation.
    I will certainly supply references for good reading materials, and
    I will endeavor to supply a self-contained appendix showing how to
    implement the algorithms.  It's not the easiest thing to understand,
    but the effort is worthwhile.

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Mon, 7 Feb 2000 15:42:56 +0900

Hello, Charlie,

 My comment to the 4th method is embedde in the following:

>>   key data from the mobile node to the new foreign agent.

 How about passing opaque key data from the previous FA to the new FA ?

 I agree with you that it's more efficient to pass key data from the MN to
 a new FA.  But, I think, there may be some network operators who resist
 believing MN-supplied key data blindly.
 As another approach, it's possible to pass the key data from the previous
 FA to the new FA, I think.

 This approach works as follows:
 1) All FAs in the same administrative domain advertise the same NAI, as
    someone wrote.
 2) In case of movements within the same administrative domain, an MN sends
    a registration request with a Mobile-Foreign and a Mobile-Home auth
    extensions, instead with a NAI and an MN-AAA auth extensions.  The
    destination IP address of this request becomes the previous FA's address.
 3) The new FA can know the previous FA by the destination address.
 4) By a smooth hand-off and/or a key retrieving mehtod, the new FA can
    receive the key data from the previous FA.

 I'd like to know this approach is acceptable by the keying philosophy or not.

Thanks.
-Yoshi

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 7 Feb 2000 11:15:01 +0200

On Fri, Feb 04, 2000 at 08:29:44AM -0800, Charles E. Perkins wrote:

> any interloper from getting in the way.

Do you propose, that a foreign agent would use the same random
exponent with all the key exchanges or would a new number be generated
for each registration? If the exponent changes, also the computed
value changes and then the digest values would have to be somehow
bound to a correct computed value. It would be at least a bit
difficult to assign a unique digest for each mobile node performing
key exchange with multi/broadcast agent advertisements and there would
be a need for unicast advertisements if each key exchange would be
required to use a different random value. This may not, however, be
necessary, if HA uses different random value for each exchange
(generated session key changes).

Could you please give a bit more detailed description of the proposed
protection against the man-in-the-middle attacks? I'm assuming, that
you are using similar method that we use in Dynamics - HUT Mobile IP
implementation (MN sends the digest value protected with MN-HA
auth. ext. to HA and HA checks whether it matches with the key
req. ext.). I think it is still possible for an attacker to change the
key exchange in a way that the attacker will know the key that the FA
gets, but the HA and the MN get another key (unknown to the attacker).

In which operations is the key going to be used? It is quite difficult
to protect against all the attacks with one pass (reg. req. and
reply). MN could know from the reply, whether the key exchange
succeeded, if another digest value generated by HA would be added
inside the MN-HA ext. auth. protected area of the reply, but I think
that the HA and the FA could not know about all the attacks without
further communication with the MN).

--
Jouni Malinen

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 24 Feb 2000 21:39:03 -0800

Hello Jouni,

I'm catching up on e-mail, sorry for the long delay...

I said:

>
> >           This can be done by having the foreign agent include a

> (generated session key changes).

What I had in mind was for the foreign agent to generate a new
digested value for each registration from the same mobile node.
That should protect both the foreign agent and the mobile node
against interlopers.

> gets, but the HA and the MN get another key (unknown to the attacker).

If the foreign agent advertises the digest, and the mobile node makes it
impossible for an interloper to replace the foreign agent's (expanded)
computed value, how can there be a man-in-the-middle attack?  I am
not aware of the Dynamics method, sorry I haven't read that yet.
I would like to know how an attacker can change anything without
detection, except by making the Registration Key unusable.

> further communication with the MN).

The registration key is designed for use with the Binding Update that
would eventually get sent back to the same foreign agent after the
mobile node moves away (and sends a Previous Foreign Agent
Notification extension).  I don't know whether it is safe to use it
as an encryption key.

Regards,
Charlie P.