Subject: RE: [Mipshop] FMIPv6 and AAA based handover keys

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 4 Apr 2007 12:26:00 -0700

Hi James,
Sorry, I was off on vacation after the IETF and didn't get a chance to
catch up with email until now. I don't have an issue with the text you
wrote itself. Even in the AAA draft, we say that it is not attempting to
solve the issues with NDP and that SeND should be used for that purpose.
So, that sounds fine to me. 

Regards,
Vidya 

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 11:26 AM
> To: Narayanan, Vidya; Suresh Krishnan; [email-masked]
> Subject: Re: [Mipshop] FMIPv6 and AAA based handover keys
> 
> The issue is that in the 3 party AAA model, there is no trust 
> between the MN and AR. The trust relationship extends between 
> the AR and the AAA server and the AAA server and the MN.
> 
> If there is no trust between the AR and MN, then an attacker 
> can disrupt an attempt by the AR to ascertain that a 
> particular CoA belongs to a particular MN. The attacker can 
> simply send a NA to the AR indicating that it owns the CoA 
> rather than the victim MN. The router will change the 
> victim's Neighbor Cache entry, and the address now belongs to 
> the attacker. If the attacker is authorized, it will have a 
> trust relationship with the AAA server, and therefore it can 
> set up an AAA key with the router, which it can use to send 
> an FBU redirecting the victim MN's traffic. This is the basic 
> attack that SEND deters.
> 
> So I don't see how, short of additional protocol between the 
> AR and the MN, the involvement of the AAA server can be 
> avoided if SEND is not used to establish a trust relationship 
> between the MN and AR, cryptographically tying the binding  
> between the CoA and the MN's MAC address. But I don't think 
> the AAA keys document needs to really go into detail about 
> this, and the text I proposed doesn't.
> 
> Do you have any objections to the text?
> 
>                 jak
> 
> ----- Original Message -----
> From: "Narayanan, Vidya" <[email-masked]>
> To: "James Kempf" <[email-masked]>; "Suresh Krishnan" 
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, March 20, 2007 11:43 PM
> Subject: RE: [Mipshop] FMIPv6 and AAA based handover keys
> 
> 
> There is no need for the AAA server to tie the key to the CoA - the AR
> must be able to tie the key to the CoA. And, to ensure that no
> redirection attacks are possible, it is sufficient that the AR ensures
> that there is no other node using that address. CGAs, of 
> course, go one
> step further. But, there are no security properties lost, as 
> long as the
> MN doesn't claim any other address that is in use by some other node,
> even if the MN is using a false address. Well, put another way, if the
> MN is an attacker, there is no value (for itself) in just claiming a
> wrong address - it needs to claim one of an actual victim. If there is
> no victim, then, the MN is just creating state the AR in an attempt to
> cause DoS, which could be done to worse levels using SeND.
> 
> I think James and I talked about the above too quite a bit. As long as
> the AR checks to ensure that no other node is using the address (using
> NDP and checking the BCE) and disassociates the key with the CoA when
> the BCE/NCE expires, that is all that is needed.
> 
> Vidya
> 
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2007 8:44 AM
> > To: Suresh Krishnan; [email-masked]
> > Subject: Re: [Mipshop] FMIPv6 and AAA based handover keys
> >
> > 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" <[email-masked]>
> > To: <[email-masked]>
> > 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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mipshop
> > >
> >
> >
> >
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> >
> 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop