[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006




El 21/07/2006, a las 19:13, Francis Dupont escribió:

 In your previous mail you wrote:

=> I strongly disagree about the first point (the main threat of mip
is the remote redirection, time shifted attacks and similar things are
second order issues),

   i agree that the main threat is redirection attacks and this is
reflected in 4218, but my point was that the most dificult attacks to
   prevent are the time-shifted attacks and this is why we end up with
   things like _periodic_ RR in mip and HBA/CGA in shim.

=> IMHO the periodic RR in mip is more to get the attacker staying
on the path than to defend against the steal of future addresses...

i guess that we have a terminology issue here... as i understand, requiring the attaack to stay in the path is prevent time-shifting attacks...

from RFC4225 section 2.2.  Timing

   Without proper
   protection, an attacker could attach itself between the home agent
   and a correspondent node for a while, create a BCE at the
   correspondent node, leave the position, and continuously update the
   correspondent node about the mobile node's whereabouts.

But the real issue here is about the method: in security one has to
provide a defense against main threats, *then* secondary threats, etc.

well, the other option is to find a tools that prevents both primary and secondary and so on...

As perfect security is impossible one has to accept some remaining
vulnerabilities...

agree

Here we are in trouble because the main threat is hard: the best known
defense, mutual strong authentication, is not deployable. So we get
poor mechanisms (like RR) and we try to improve them (like CBA) against
secondary threats when the main one still remains... I really like
to see shim far better than mip!


but do you think that the security resulting with HBAs and the additional mechanisms available in shim are good enough?

   If time shifted
attacks were not an issue, we could have used cookies for instance or
   hash chains to protect the shim in conjuction the already existent
routing based security (meaning the asumption that the routing system
   delivers packets to the rightful "owners" of the addresses)

=> again IMHO you miss the real issue...

So, the hypothesis of 4218 and of mip security is of course as you say that the fundamental threat is redirection attacks, but also that time
   shifted attacks need to be prevented... agree with this?

=> no: I really prefer to get time shifted attacks as a remaining
vulnerability than redirection.

of course... i mean time shifted attacks are a flavor of redirection attack... i am assuming that a solution that does not provide protection from the most basic forms of redirection attacks are simply non starters...

among those security mechanisms that provide security to some form of redirection attacks, i am advocating for those that also cover the most diffult forms i.e. time shifted attacks...

I mean do you agree that we should deal with the threats described in 4218?


 Of course it should be better to
have none but it is enough hard to choose between acceptable level
of security and deployable solutions to be at least as possible
disturbed by secondary threats.

i think HBA mechansim provides protection against most forms of redirection attacks, including tiem shifted attacks


 and I don't fully agree with the second because
the only issue is the global PKI (ie., issuing client certificates is
again second order).

global PKI is a big obstacle for deployment but imho the generation of client certificates it is also. I mean imagine having to create client certificate for every host in the internet. Imagine that for those, you need to verify the rightful ownership of the IP address included in the
   certificate. Technically this may be simple, but logistically, this
   requires a lot of effort imho

=> by a global PKI I mean global certification *and* registration
authorities. The problem is not technical at all even I don't believe
we know how to do it in a reasonable timeframe at this scale today.

i guess we fully agree here

regards, marcelo



Regards

Francis.Dupont@point6.net