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.
Return routability should help a bit here but it's not particularly strong... 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.
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) 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).
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.