[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 19/07/2006, a las 21:59, Iljitsch van Beijnum escribió:

On 19-jul-2006, at 15:39, marcelo bagnulo braun wrote:

Why? If one end has a certificate the communication can be secure.

but you still can provide identifier ownership proof, right?

I mean, in order to avoid future attacks agaisnt the identity we need more than just a secure channel but a secure binding between the identifier and something that canbe used to prove ownership (like a public/private key pair)

so, such scheme would result in the posibilty of identity hijacking attacks

in order to avoid those, you need something else, like client certificates

Right, you'd have the situation where client A connects to server X and X's certificate is used to protect the exchange of A's locator B, but then later X wants to talk to A and uses B but it turned out that A wasn't really A but someone "borrowing" A's address on an insecure link for a moment.


exactly

this one attack (imho the most interesting) but you could also think in attacks in only one direction (not only based in the server establishing connections back to the server)

Return routability should help a bit here but it's not particularly strong...

well, a single RR check was not enough for the mip guys, so they actually imposed periodic RR checks (every 7 minutes) in order to prevent time shifted attacks... of course we cannot do the same approach here, because after a failure, the RR check is no longer feasible...

Same for DNS (X could check whether reverse A -> forward A -> B) but this is pretty weak also, as long as we don't have DNSSEC.

well, in addition is the added cost/latency of the additional DNS query


I guess I could live with either requiring a client certificate (especially as this could be one proxy certificate for a proxy that handles a bunch of clients)

this is one option, yes, but it requires PKI

or that new sessions may only be initiated by the client (server dumps all shim state when it needs to set up a session towards the client).

this would eliminate some of the attacks indeed
we should analyze the impact of remaining attacks
and the limitation is that a server cannot initiate communication towards client ever, right?

besides, this is kind of messy because the shime needs to be able to tell what a ulp session is, so that it is possible to distinguish which packets are part of a new session. In the case of TCP it may be easy, but in the case of unconnected UDP this is much harder...


I expect nearly everyone to implement HBA anyway, but if some people really don't want it at least they have SOMETHING this way. Not having a mandatory security mechanism is possible here, IMO, as this simply means no multihoming benefits.


Not sure i understand this last sentence.... why would anyone want to implement the shim if no multihoming benefits are achieved?

Regards, marcelo