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

[Ray Hunter <[e-mail]>]

> Hosnieh Rafiee <mailto:[e-mail]>
> 29 November 2013 01:28
>> 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.

No. This is exactly what you've described in your draft. Attacker X has
created a colliding version of Alice's hash, but with a different sec value.
>  
>> 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.
No.

Because every node performing DAD defends its own local tentative
address. If the Sec value is different on the attack packet. it will NOT
match the tentative address of the defending interface, and the node
won't even contemplate triggering DAD.
>> 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. 
No.

You have exactly the same problem in CGA and SSAS, no matter how the
address is "verified", you have to establish a trust anchor relationship.

This is covered by the phrase in RFC 3971

"If the use of a trust anchor has been configured, a valid
      certification path (see Section 6.3) between the receiver's trust
      anchor and the sender's public key MUST be known."

Just because the signed address can be verified against the public key
(of the sender / attacker, and which public key has been potentially
transported in the very same packet as the spoofed hash) does not mean
that the contents are immediately "trusted".

The public key of the sender also has to be somehow verified by the
receiving node.

That is the real implementation problem here: Given end nodes A and B
and a router R and an spoofed router SR, which combination of
modes/partnerships is truly trusted, and who is an attacker and how can
you know, without a pre-established trust-anchor?

That trust anchor bootstrap has got nothing to do with the signing
mechanism itself.
> 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.
I disagree.
>
> Smile,
> Hosnieh
>
> ------------------------------------------------------------------------


-- 
Regards,
RayH