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

From: Patrice Calhoun <[email-masked]>
Date: Tue, 8 Feb 2000 05:16:07 -0800

>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:
>
>On Mon, 7 Feb 2000 08:32:09 -0800,  Patrice Calhoun wrote:
>>>
>>> >On Fri, 4 Feb 2000 08:29:44 -0800,  Charles E. Perkins wrote:
>>> >>> 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
>
> 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.

Interesting. A hierarchical approach, without being hierarchical.

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

hmmm... if you really don't want to trust the Mobile, then I would prefer to
see the keying information be passed in the binding update, as defined in
the route opt. draft.

Perhaps I don't see your problem here, but why do you need to trust the mobile?
The draft in question requires that the keying material be encrypted by
symmetric or assymetric keys only known to the FAs. The resulting key will
look like a bunch of opaque bits to the Mobile. If the encryption key
used by the Foreign Agent is sufficiently strong, I don't see a problem.

A possible problem would be for the Mobile to simply send junk, wasting the
Foreign Agent's cycles by decrypting a blob that will result in an invalid
key.

>
> Can you give me confidence ? :)

Was that enough?

PatC

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Thu, 10 Feb 2000 15:40:24 +0900

Hello, Pat,

 Thanks for your email.  Probably, my last comment to this thread is attached
 at the bottom of this email:

>> > Can you give me confidence ? :)

 OK, now enough.  I'll persuade myself, after reading the new keying draft
 and the Diffie-Hellman work by elliptic curve groups.

 There may be another related problem; in case of wireless access networks,
 packets may drop due to corruption.  I'd like to expect some considerations
 about packet losses in receiving or sending key data by an MN.  Especially,
 I don't think an MN can send or request key data, as many times as it wants,
 in order to distinguish true operations from the above junk attacks.

Thanks.
-Yoshi