Subject: [Mipshop] FMIPv6 and AAA based handover keys

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Mar 2007 11:28:38 -0400

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Mar 2007 08:44:20 -0700

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

> 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.
>
>  from [5], the Authenticator in BADF option (see 6.4.5) MUST be computed, 
> and the BADF option included in FBU and FBack messages."
>
> alternate methods to establish such a security association. Using a shared 
> handover key, the Authenticator in BADF option (see 6.4.5) MUST be

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 20 Mar 2007 08:47:32 -0700

Hi Suresh,

> be computed, and the BADF option included in FBU and FBack messages."

This is fine with me.
Thanks for the suggestion.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 20 Mar 2007 08:53:14 -0700

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Mar 2007 12:16:27 -0400

James Kempf wrote:
> 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.

This is exactly what I am suggesting as well. The current text in the 
draft implies something different. That is why I suggested new text for 
the SecCon. Can you please let me know if there is any discrepancy 
between the suggested text and your perception.

Cheers
Suresh

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Mar 2007 09:24:21 -0700

How about:

"The use of SEND [5] in this document to establish such a secuirty 
association is only one possible alternative for establishing such a 
security association in an interoperable way, and should not be interpreted 
as a normative dependence of this protocol on SEND. Other alternatives are 
possible, but implementations MUST use some method to establish such a 
security association. For interoperability, such a method SHOULD be 
standardized. 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."

Also, if [5] is currently in the Normative references section, it should be 
moved to Informative (I'm presuming here [5] is RFC 3971, I don't have the 
draft in front of me).

            jak

----- Original Message ----- 
From: "Suresh Krishnan" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 20, 2007 9:16 AM
Subject: Re: [Mipshop] FMIPv6 and AAA based handover keys

> the SecCon. Can you please let me know if there is any discrepancy between 
> the suggested text and your perception.
>
> Cheers
> Suresh
>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Mar 2007 23:43:26 -0700

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Mar 2007 11:26:09 -0700

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

Vidya