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

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

Hi Suresh,


On 3/20/07 8:28 AM, "ext Suresh Krishnan"
<suresh.krishnanericsson.com>
wrote:

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

This is fine with me.
Thanks for the suggestion.

-Rajeev




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

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


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

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" <suresh.krishnanericsson.com>
To: "James Kempf" <kempfdocomolabs-usa.com>
Cc: <mipshopietf.org>
Sent: Tuesday, March 20, 2007 9:16 AM
Subject: Re: [Mipshop] FMIPv6 and AAA based handover keys


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



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

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:kempfdocomolabs-usa.com] 
> Sent: Tuesday, March 20, 2007 8:44 AM
> To: Suresh Krishnan; mipshopietf.org
> 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"
<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

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" <vidyanqualcomm.com>
To: "James Kempf" <kempfdocomolabs-usa.com>;
"Suresh Krishnan" 
<suresh.krishnanericsson.com>; <mipshopietf.org>
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:kempfdocomolabs-usa.com]
> Sent: Tuesday, March 20, 2007 8:44 AM
> To: Suresh Krishnan; mipshopietf.org
> 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"
<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

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:kempfdocomolabs-usa.com] 
> Sent: Wednesday, March 21, 2007 11:26 AM
> To: Narayanan, Vidya; Suresh Krishnan; mipshopietf.org
> 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" <vidyanqualcomm.com>
> To: "James Kempf" <kempfdocomolabs-usa.com>; "Suresh Krishnan" 
> <suresh.krishnanericsson.com>;
<mipshopietf.org>
> 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:kempfdocomolabs-usa.com]
> > Sent: Tuesday, March 20, 2007 8:44 AM
> > To: Suresh Krishnan; mipshopietf.org
> > 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"
<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