Re: FMIPv6 and AAA based handover keys

 I think Suresh is referring to the MUST as being specific
to SEND-keys only
(meaning, the key could only be derived via SEND-keys
only).

We should have the SEND-keys as a companion protocol to go
with rfc4068bis.
Other protocols MAY similarly devise handover keys (as
Suresh is
suggesting), but the BADF MAC computation is uniform across
such protocols.

-Rajeev



On 3/20/07 8:44 AM, "ext James Kempf"
<kempfdocomolabs-usa.com> wrote:

> Suresh,
> 
> Vidya and I discussed this extensively prior to the
paper being approved
> last year for submission as a WG draft. The issue is
that there needs to be
> some way that the AAA key can be verifiably tied back
to the CoA. There are
> a variety of ways this might be done, for example, the
AAA server might be
> involved in the address allocation as well as in the
generation of the
> session key, and the router could verify this when it
grants the shared key.
> A system implementing AAA keys need not use SEND for
this purpose.
> 
> The reason this is a MUST is because if it is not done,
it is possible for
> an attacker to spoof the address of a victim and obtain
a AAA handover key,
> then change the routing for the victim. Therefore, I
don't believe it would
> be wise to change this requirement.
> 
>                 jak
> 
> ----- Original Message -----
> From: "Suresh Krishnan"
<suresh.krishnanericsson.com>
> To: <mipshopietf.org>
> Sent: Tuesday, March 20, 2007 8:28 AM
> Subject: [Mipshop] FMIPv6 and AAA based handover keys
> 
> 
>> Hi Folks,
>>   I was objecting to the AAA based solution because
I believed that the
>> chairs had concluded that the solution described
in
>> draft-ietf-mipshop-handover-key-00.txt would be the
sole solution for fmip
>> authentication. It is reinforced by the following
text in the SecCon of
>> the 4068bis-01 draft.
>> 
>> "The current version of this protocol relies
on a companion protocol [5]
>> to establish such a security association.  Using
the shared handover key
>>  from [5], the Authenticator in BADF option (see
6.4.5) MUST be computed,
>> and the BADF option included in FBU and FBack
messages."
>> 
>> Notice the MUST. I am NOT AGAINST working on a AAA
based solution, but I
>> would like the above text changed to something to
this effect to
>> acknowledge the possibility of non-SEND based
solutions.
>> 
>> "The current version of this protocol relies
on a companion protocol [5]
>> to establish such a security association.
Implementations MAY use
>> alternate methods to establish such a security
association. Using a shared
>> handover key, the Authenticator in BADF option (see
6.4.5) MUST be
>> computed, and the BADF option included in FBU and
FBack messages."
>> 
>> Thanks
>> Suresh
>> 
>> _______________________________________________
>> Mipshop mailing list
>> Mipshopietf.org
>> https:
//www1.ietf.org/mailman/listinfo/mipshop
>> 
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> Mipshopietf.org
> https:
//www1.ietf.org/mailman/listinfo/mipshop


_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop