Subject: [Mipshop] FMIPv6 Authentication

From: Wassim Haddad <[email-masked]>
Date: Wed, 12 Jul 2006 01:08:08 +0300 (EEST)

Hello Vidya,

Can you please re-clarify your comment(s) on the FMIPv6 Auth draft?

Regards,

Wassim H.

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 11 Jul 2006 16:25:21 -0700

Hi Wassim,
The FMIP signaling (as in any other protocol signaling) needs integrity
protection to ensure that the messages have not been tampered with
between the MN and AR. Imagine the following scenario. 

An MN is accessing a network via an open WLAN system. On the path
between the MN and AR, a node (e.g., the AP) modifies the messages. So,
even though the MN sent a message with the source address created in
accordance with the solution in your draft, there would be no way for
the AR to detect the modification in the message. 

So, there is a need for message authentication (i.e., integrity
protection) that cannot really be provided without a signature or a MAC.

Regards,
Vidya

> -----Original Message-----
> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 3:08 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: FMIPv6 Authentication
> 
> Hello Vidya,
>

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 12 Jul 2006 16:45:57 +0300 (EEST)

Hi Vidya,

> between the MN and AR. Imagine the following scenario.

=> Before you use the "general" approach for integrity as argument, it
would be more interesting to ask what exactly can harm the MN's ongoing
session if a malicious AP can tamper with it and if the AR will accept
the fake message or not. As you probably know, the security consideration
section in the FMIPv6 RFC (and now draft again) mentions only threats
related to IPv6 addresses carried by the FBU message and not a general
but unknown threat.

> accordance with the solution in your draft,

=> NOT just the source address but also the destination address.

> there would be no way for the AR to detect the modification in the
> message.

=> you're again using a general argument. Am aware of your scenario but I
found nothing beyond the two IPv6 addresses in the _context of FMIPv6_
that can be a potential threat to the MN's ongoing session. So please tell
me first which other parameter can cause harm to the MN's ongoing session.

Regards,

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Jul 2006 07:33:42 -0700

Hi Wassim,

> > The FMIP signaling (as in any other protocol signaling) needs 
> > integrity protection to ensure that the messages have not been 
> > tampered with between the MN and AR. Imagine the following scenario.
> 
> => Before you use the "general" approach for integrity as 
> argument, it would be more interesting to ask what exactly 
> can harm the MN's ongoing session if a malicious AP can 
> tamper with it and if the AR will accept the fake message or 
> not. 

If the AP modified an IP address (source or destination) in the message,
the MN will not receive FMIP service (since the AR will drop the packet
or create an error due to an invalid IP address). I'd think that would
be a problem. 

> As you probably know, the security consideration section 
> in the FMIPv6 RFC (and now draft again) mentions only threats 
> related to IPv6 addresses carried by the FBU message and not 
> a general but unknown threat.
> 

I noticed that yesterday too and I believe that must be updated. MIP6
and HMIPv6 rightfully provide integrity protection (using IPsec, for
e.g.) and I don't see any difference in the need for the same for
FMIPv6. 

> > between the MN and AR, a node (e.g., the AP) modifies the messages. 
> > So, even though the MN sent a message with the source 
> address created 
> > in accordance with the solution in your draft,
> 

The above mentioned still holds. 

> => you're again using a general argument. Am aware of your 
> scenario but I found nothing beyond the two IPv6 addresses in 
> the _context of FMIPv6_ that can be a potential threat to the 
> MN's ongoing session. So please tell me first which other 
> parameter can cause harm to the MN's ongoing session.
> 

Please see the explanation above on malicious modification of IP
addresses. That is just one example. Since none of the fields in the FBU
are authenticated, there are a number of other fields that can be
changed to an invalid value, forcing the AR to drop the packet or
generate an error. 

Also, in the FBAck, for e.g., the adversary can modify fields (e.g., a
success code into an error code), confusing the MN and it will go
undetected. 

Also, as I mentioned yesterday, the assumption of the network being
trusted does not make sense to me. That would imply that we don't need
mutual authentication in any protocol - I've never seen that assumption
made for any protocol, even for entities that are further into the
network, much less for the edge entities like the AR. 

May be I'm missing something extremely fundamental here? 

Regards,
Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 12 Jul 2006 17:55:11 +0300 (EEST)

Hi Vidya,

> or create an error due to an invalid IP address). I'd think that would

=> that's why we have the OWHC and the HV to link both addresses. Now if
your argument is a DoS attack then I think you should really re-consider
it!

> e.g.) and I don't see any difference in the need for the same for

=> I think the reason is that the security consideration in FMIPv6 analyzes
(so far!) only the attacks, which make sense and are feasible.

> The above mentioned still holds.

=> Please think about it more!

> changed to an invalid value, forcing the AR to drop the packet or

=> I think you should first take a look to the FBU structure, see what
the fields are, what can be done to do harm and if a possible protection
from the AR is possible or not... before throwing arguments.

> success code into an error code), confusing the MN and it will go

=> What I've mentioned above also apply for the BA message.

> trusted does not make sense to me.

=> well according to your arguments am not surprised! But for me it makes
a lot of sense to be able to trust the infrastructure under certain
assumptions which are present here especially that it provides you
interesting features to epxloit.

> That would imply that we don't need

=> Note that the FBU message is not sent without any protection and note
that you start the protocol with running CGA and sharing a secret parameter
with an entity that belongs to the infrastructure.

Regards,

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Jul 2006 10:24:35 -0700

Hi Suresh,
The whole problem is that a tampered FBU is dropped without an idea that
it was tampered. Same holds for the FBAck as well. Also, replay
protection and integrity protection serve distinctly different purposes.
Further, replay protection actually does not quite work without
integrity protection. It has been proven that in fact, most other
security properties (including encryption for that matter) are of no use
without integrity protection. 

So, I continue to remain puzzled :) 

Vidya 

> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 7:25 AM
> To: Narayanan, Vidya
> Cc: Wassim Haddad; [email-masked]
> Subject: Re: [Mipshop] RE: FMIPv6 Authentication
> 
> Hi Vidya,
>    Let's consider the scenario you are proposing.
> 
> Let's say the MN sends an FBU with the hash chain value V[x] 
> and handoff vector HV1. In this case
> 
> IID(nCoA)=V[x] XOR HV1
> 
> The MCE of the AR will contain the values V[x-1] and HV1 
> since they were the last successfully used values. Once the 
> FBU reaches the AR, it will verify if
> 
> HASH(V[x-1]) XOR HV1 from MCE == IID(nCoA)
> 
> If this is the correct, which will be the case for the 
> legitimate FBU from the MN, the AR will accept the FBU and 
> will update the MCE to contain the values V[x] and HV1. When 
> the AP sends the tampered FBU the AR will receive the FBU and 
> do the above mentioned check again
> 
> since
> HASH(V[x]) XOR HV1 from MCE will not match the  IID(nCoA) the 
> tamperred FBU will be dropped. So the short answer is: No, 
> there is no integrity protection but a tampered FBU will be 
> caught and dropped by way of the replay protection mechanism.
> 
> Cheers
> Suresh
> 
> 
> > in accordance with the solution in your draft, there would 
> be no way 
> > for the AR to detect the modification in the message.
> >

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 12 Jul 2006 20:31:35 +0300 (EEST)

Hi Vidya,

I'll add one comment to this discussion:

the draft considers that in order to deploy SEND successfully then the
links between the ARs and APs are secure. So I don't think you need to
remain puzzled if you add that the ARs won't accept a packet sent by
any AP.

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Jul 2006 10:55:11 -0700

Hi Wassim,
I think we have different ideas about the applicable threat model here.
It appears that we have otherwise understood each other's points, but
continue to have different views because of the differing views on the
threat model. 

At this point, we can defer the discussion until we can have a
discussion on the threat model to see if the WG can agree on that first.

Regards,
Vidya

> Sent: Wednesday, July 12, 2006 7:55 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: RE: FMIPv6 Authentication
> 
> Hi Vidya,
> 
> argument, 
> > > it would be more interesting to ask what exactly can harm 
> the MN's 
> > > ongoing session if a malicious AP can tamper with it and 
> if the AR 
> > > will accept the fake message or not.
> >
> > If the AP modified an IP address (source or destination) in the 
> > message, the MN will not receive FMIP service (since the AR 
> will drop 
> > the packet or create an error due to an invalid IP 
> address). I'd think 
> > that would be a problem.
> 
> => that's why we have the OWHC and the HV to link both 
> addresses. Now if your argument is a DoS attack then I think 
> you should really re-consider it!
> 
> > > As you probably know, the security consideration section in the 
> > > FMIPv6 RFC (and now draft again) mentions only threats related to 
> > > IPv6 addresses carried by the FBU message and not a general but 
> > > unknown threat.
> > >
> >
> => I think the reason is that the security consideration in 
> FMIPv6 analyzes (so far!) only the attacks, which make sense 
> and are feasible.
> 
> > > => you're again using a general argument. Am aware of 
> your scenario 
> > > but I found nothing beyond the two IPv6 addresses in the 
> _context of 
> > > FMIPv6_ that can be a potential threat to the MN's 
> ongoing session. 
> > > So please tell me first which other parameter can cause 
> harm to the 
> > > MN's ongoing session.
> > >
> >
> > addresses. That is just one example. Since none of the 
> fields in the 
> > FBU are authenticated, there are a number of other fields 
> that can be 
> => I think you should first take a look to the FBU structure, 
> see what the fields are, what can be done to do harm and if a 
> possible protection from the AR is possible or not... before 
> throwing arguments.
> 
> => well according to your arguments am not surprised! But for 
> me it makes a lot of sense to be able to trust the 
> infrastructure under certain assumptions which are present 
> here especially that it provides you interesting features to epxloit.
> 
> > mutual authentication in any protocol - I've never seen that 
> > assumption made for any protocol, even for entities that 
> are further 
> > into the network, much less for the edge entities like the AR.
> >
> => Note that the FBU message is not sent without any 
> protection and note that you start the protocol with running 
> CGA and sharing a secret parameter with an entity that 
> belongs to the infrastructure.
> 
> 
> Regards,
> 
> Wassim H.
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 12 Jul 2006 10:25:04 -0400 (EDT)

Hi Vidya,

Let's say the MN sends an FBU with the hash chain value V[x] and handoff 
vector HV1. In this case

IID(nCoA)=V[x] XOR HV1

The MCE of the AR will contain the values V[x-1] and HV1 since they were 
the last successfully used values. Once the FBU reaches the AR, it will 
verify if

If this is the correct, which will be the case for the legitimate FBU from 
the MN, the AR will accept the FBU and will update the MCE to contain the 
values V[x] and HV1. When the AP sends the tampered FBU the AR will 
receive the FBU and do the above mentioned check again

since
HASH(V[x]) XOR HV1 from MCE will not match the  IID(nCoA) the tamperred 
FBU will be dropped. So the short answer is: No, there is no integrity 
protection but a tampered FBU will be caught and dropped by way of the 
replay protection mechanism.

Cheers
Suresh