[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.