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

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

On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:
there is no public key in HBA... there is public key in CGA though (and in hybrid CGA/HBA) 

Hybrid being required to support renumbering events, right?
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 

Sure.
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.
Sure, so it proves the packet was constructed correctly, at least the association of the outer locator prefix to the inner ULID. This doesn't prove anything about who sent the packet though, does it?
It seems vulnerable to injection attacks (unless you assume routing is secured in some way, eg RPF everywhere, but that still leaves a an attacker who is on-link or MITM able to inject packets. Further, operational experience shows this to be a dangerous assumption to rely on).
HBA seems a way to detect quite fraudulent packets (invalid binding), it doesn't seem (to me) to be a way to assure a received packet came from where the binding claims it did.
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 

I'm not quite sure that's true:


A-----B D ---E
      | |
     -----
      |
      C
For whatever operational reasons C is able to send packets with the same source prefix as A, it /might/ also able to able to observe the packets sent by E to A.
C can, at a minimum, play havoc with any shim mapping on E relevant to A, if the only security is HBA and the shim protocol is stateless (without having to observe packets obviously). If the shim protocol is not stateless, eg through use of some sequence number, then it can (without observation) possibly deny A from speaking to E by setting up shim6 negotiation in advance of A doing so (A's shim6 control packets then might be rejected, due to wrong state) if E assumes that for a given valid HBA future state will match. With observation, C can likely play further havoc.
Attacks requiring no observation likely would work regardless where C is located..
Obviously, we don't know yet what the shim6 protocol will be. But I don't think it can assume very much about security just because HBA checks out..
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 

I don't see what prevents an attacker constructing the same HBA.
If you rely solely on HBA validation then Shim would be vulnerable to injection attacks. If you add further state to the Shim protocol to defeat blind injection attacks, then you'll be open to same anonymous state DoSes as anonymous IPSec. (In which case you might as well have used IPSec).
right, how do you bind the key used in IPSec with the ULP identifier used in the shim?
Well, why is this required exactly? I don't think it provides that much security (just a modicum of anti-spoofing protection).
how to perform the binding between the ULP identifier and the key used in IPSec
You don't have a secure binding though, unless you assume IPv6 routing is to be completely secured before shim6 deployment and made immune to injection (unlikely). 

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
UFOs are for real: the Air Force doesn't exist.