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

Re: addition of TLV to locator ID or locator ID set




El 02/10/2005, a las 17:59, Paul Jakma escribió:

On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:

IMHO, what would be not so hard to support would be that source address prefixes get rewritten by the exit routers as long as the the security stuff remains end to end i.e. the hosts are the ones that define the HBA/CGA sets and perform the security validation. That is basically offloading the source address selection to the router, but the remining parts of the shim are still in the hosts.

That depends I guess on whether the HBA stuff tries to use more than the 64bits of lower-order address space reserved for the host. If it confined itself to that, it could work. If HBA wants to affect the higher order 64 bits, that would have implications for how to assign such addresses.

The HBA draft seems to suggest it confines itself to the 'interface identifier' though. (In which case, you just need a way to make the available-prefixes known to the hosts, to allow them to construct the HBA identifier).


exactly

The problem here is how do you bind the key that is used in IPSec with the identifier used.

If you don't provide a security binding, then an atacker can provide its own key and bind it to the victim's identifier, so no good.

The options to provide a secure binding are:
- a third trusted party i.e. PKI
- create the identifer so that it intrinsically contains key information i.e. CGA/HBA

because of the deployment issues, the second option seems more attractive

But you still have the issue of distributing the HBA public key, no?

there is no public key in HBA...
there is public key in CGA though (and in hybrid CGA/HBA)

However there is no security issues with CGA public key distribution because the CGA is intrinsically bound to the public key, so it is extrmely hard to find a different public key that is bound to a given CGA

Otherwise the only thing HBA can prove is that the /first/ host which communicated with you using some HBA address does not have its addresses subverted, right?

I think no

the HBA addresses are intrinsically bound to the prefix set, so there is no leap of faith involved in the usage of HBA (nor in CGA) as opposed to opportunistic IPSec

HBA addresses are bound to a given prefix set i.e. the addresses of a given HBA set are bound together and this cannot be easily forged. In the same way, the CGA is bound to a public key and cannot be easily forged.



Further, you will have to put a limit on how long a host remembers state (or, on the number of remote HBA hosts it may keep state for). Once that state goes, so the window opens up for the HBA concerned to be redirected, surely?

There's no difference between that and anonymous IPSec, is there?


As i mentioned above, there is no leap of faith in HBA/CGA security, while it does exists in oportunistic IPSec. Actually, the nice thing about CGA/HBA is that they do provide a quite continuos protection and don't need to trust in the information exchanged during the initial contact, preventing the so-called future or time shifted attacks


IPSec however was designed to be able to be extensible and cope with lots of different algorithms and key exchange schemas. You'd have to reinvent all that to make HBA cope, plus you're limited to 128 bits of information, if you want to use only the IPv6 address as the identifier. (what about replay attacks? :) ).


The problem is not key exchange, is the binding between the identifier and the key. for example you could use the key of the CGA in IPSec, (actually, HIP is basically what it does) and we could use AH and ESP formats here for securing the shim protocol, no problem with that. The point is how do we make sure that the key used in IPSec corresponds to the identifier we are using and not to an attacker

Way I see it, as long as Shim state changes can not be effected with ordinary shimmed packets, as long as state changes (eg, addition/removal of locators) can only be signaled via some side-band Shim protocol[1] then you only need to secure that side-band. IPSec (the standardised, deployed and agreed on IETF security protocol for IP..) will do fine for that and provide security ranging from anonymous to more trustworthy schemes.


right, how do you bind the key used in IPSec with the ULP identifier used in the shim?

Mind you, I still don't really fully grok HBA - what critical detail am i missing?


how to perform the binding between the ULP identifier and the key used in IPSec

Regards, marcelo


regards, marcelo

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Goda's Truism:
	By the time you get to the point where you can make ends meet,
	somebody moves the ends.