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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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