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

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



Hi Francis,

sorry for the late reply...


El 23/07/2006, a las 18:20, Francis Dupont escribió:

 In your previous mail you wrote:

Here we are in trouble because the main threat is hard: the best known
defense, mutual strong authentication, is not deployable. So we get
poor mechanisms (like RR) and we try to improve them (like CBA) against
secondary threats when the main one still remains... I really like
to see shim far better than mip!


   but do you think that the security resulting with HBAs and the
   additional mechanisms available in shim are good enough?

=> HBAs are weaker than CGAs

i don't agree with this

DO you know any attack that is easier in HBAs than in CGAs? could you describe it?

imho HBA and CGA are exactly equally strong, since the weakest point in both schemes is determined by the number of hash bits contained in the iid of the IPv6 address. In both schemes, an attacker must perform o(2^59) attempts in order to find an alternative CGA parameter data strucutre (with an alternative PRefix set in the case of HBAs and with an alternative public key in the case of CGA)

moreover, imho CGAs are residually weaker than HBAs, since in CGAs the private key can be compromised while in HBAs there is no secret that can be compromised

 (which provide ownership using the signature),
and than standard strong authentication (using some kind of PKI).

agree that PKI is stronger, since the attacks may require more than o(2^59) attempts

Without the hash extension IMHO they would be too weak, now we have
to take advice from cryptographers to understand if/how to improve them...

i am not sure what do you mean by hash extensions...

but anyway, we can change the hash function in HBA/CGA and we have the Sec parameter... this should be enough for a few decades i heard...

regards, marcelo



Regards

Francis.Dupont@point6.net

PS: BTW my employer when I implemented HBAs was "GET/ENST Bretagne".