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

From: Patrice Calhoun <[email-masked]>
Date: Mon, 7 Feb 2000 08:32:09 -0800

>Hello, Charlie,
>
> My comment to the 4th method is embedde in the following:
>
>On Fri, 4 Feb 2000 08:29:44 -0800,  Charles E. Perkins wrote:
>>> 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.
>
> 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.

The issue that I have with this approach is that if the FA require that the
MN-FA auth be authenticated prior to forwarding the registration message to the
HA, it would impose additional latency by requiring a round trip between the
FAs to retrieve the keys necessary to authentication the MN-FA. If the MN
can receive encrypted keys from the old FA, this round trip is eliminated,
further reducing the latency involved in the hand-off.

PatC
>Thanks.
>-Yoshi

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Tue, 8 Feb 2000 21:20:32 +0900

Hello, Pat,

 I still cannot abandon another approach of passing key data between FAs.
 Some modifications are attached at the bottom of this email;  I'll appreciate,
 if you give me a punch:

>> further reducing the latency involved in the hand-off.

 To eliminate the round trip between FAs, how about authenticating the first
 registration request and reply by the old FA, instead of the new FA ?

 I think, this could be possible by the followings:
   1) At the first request after an MN moves to a new FA, the MN sends a
      request to the new FA, but the destination IP address is the previous FA.
   2) The new FA records the request, but simply forwards it to the previous
      FA.
   3) The previous FA authenticates the request, and forwards it to the HA.
      The previous FA will find the source address isn't its care-of address,
      but others.
   4) After a while, the previous FA receives a reply from the HA.  By checking
      the destination address, it will find the destination is the new FA, then
      forwards it to the new FA.
   5) When the new FA receives this reply, it will enable a Mobile IP
      communication for the MN.
   6) Between this first request and a second request, the new FA will fetch
      key data from the previous FA by secure communication or by a keying
      protocol.

 This approach will probably need an FA-FA authentication extension, but
 could eliminate the round trip to get key data at the first request.

 Strange to say, I cannot believe all MNs, although I'm a programmer of an MN.
 So, I would hesitate to believe the key data supplied by an MN, even with the
 proposed protecting method.

 Can you give me confidence ? :)

Thanks.
-Yoshi