RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt

["Hosnieh Rafiee" <[e-mail]>]

> >
> http://tools.ietf.org/html/rfc4982#page-4 Section 4.1
> 
> talks about using an alternative (simpler hash function) to create
collisions.
> Sec = 0 to me equates to a simpler hash function than sec = 1.
> 
> quote:
>    In other words, the downgrading attack would work as follows: suppose
>    that Alice generates a CGA CGA_A using the strong hash function
>    HashStrong and using a CGA Parameter Data Structure CGA_PDS_A.  The
>    selected hash function HashStrong is encoded as an extension field in
>    the CGA_PDS_A.  Suppose that by using a brute force attack, an
>    attacker X finds an alternative CGA Parameter Data Structure
>    CGA_PDS_X whose hash value, by using a weaker hash function, is
>    CGA_A.  At this point, the attacker can pretend to be the owner of
>    CGA_A and the stronger hash function has not provided additional
>    protection.

Yes, it can. Because actually the problem is in verification steps and not
in generation.

 
> Yes. The sec value is not protected in any way by the CGA IID itself.
> 
> The attacker is free to choose any sec value: either the same as the
defender
> or higher or lower.
> 
> If CGA IID's existed in a vacuum that might be a problem.
> 
> But if CGA is being used in combination with DAD, that will create a
different
> IPv6 address.
> If the sec value is 0, the addresses won't match with the local node's
tentative
> address. If the sec value is 1, the hashes won't match.

As far as I know, the problem again here is there is no checking between the
source address and target address. The verification is on source address and
the control of the victim node source address is with target address. This
is where gives an attacker the possibility to forge the identity of the
victim CGA node.

> 
> Or equally the sec value can itself be explicitly protected by a
signature, as in
> SEND RFC 3971 signature option, where the full IPv6 address (and thus the
sec
> value) is also protected.

Well, the attacker has his own public/private key. He generates his own
signature. No node knows the value of the signature. This is why SSAS or CGA
needs to use the interface ID as a part of preventing the spoofing. When the
attacker generates the CGA value similar to the victim node (different in
lonely first 3 bits) then he can sign the message with his own private key
and SeND verification is also successful. In the attack scenario that I
explained in CGA-attack, neither the SeND nor CGA could really be any help
to the victim node. 

As I explained before, SeND without CGA cannot protect the node as it is
expected and it is dependent to CGA and now CGA also cannot protect the node
as it claimed.


Smile,
Hosnieh