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

[Ray Hunter <[e-mail]>]

> Hosnieh Rafiee <mailto:[e-mail]>
> 26 November 2013 18:12
> Hi Ray,
>
>  
>
>
>
>
>> Hosnieh Rafiee wrote:
>
>>> Here you go! Sorry for typos or bad organization since I wrote it so
> fast. The
>
>> next versions will be better.
>
>
>>> BTW, as I explained in my previous message, you can bombard me with too
>
>> many emails but please do not expect immediate answer for the next 3
>
>> upcoming days since I will have limited internet access.
>
>
>>> -----------smile----------
>
>>> Hosnieh
>
>
>
>
>>> A new version of I-D, draft-rafiee-6man-cga-attack-00.txt
>
>>> has been successfully submitted by Hosnieh Rafiee and posted to the IETF
>
>> repository.
>
>
>>> Filename:     draft-rafiee-6man-cga-attack
>
>>> Revision:      00
>
>>> Title:                               Possible Attack on
> Cryptographically Generated Addresses
>
>> (CGA)
>
>>> Creation date:            2013-11-25
>
>>> Group:                          Individual Submission
>
>>> Number of pages: 7
>
>>> URL:
> <http://www.ietf.org/internet-drafts/draft-rafiee-6man-cga-attack-00.txt>
> http://www.ietf.org/internet-drafts/draft-rafiee-6man-cga-
>
>  <http://www.ietf.org/internet-drafts/draft-rafiee-6man-cga-attack-00.txt> >
> attack-00.txt
>
>>> Status:
> <http://datatracker.ietf.org/doc/draft-rafiee-6man-cga-attack>
> http://datatracker.ietf.org/doc/draft-rafiee-6man-cga-attack
>
>>> Htmlized:
> <http://tools.ietf.org/html/draft-rafiee-6man-cga-attack-00>
> http://tools.ietf.org/html/draft-rafiee-6man-cga-attack-00
>
>
>
>>> Abstract:
>
>>>    This document describes the new vulnerabilities with the use of
>
>>>    Cryptographically Generated Addresses.
>
>
>> I have read this draft and RFC3972.
>
>
>> I agree the CGA information will match in the case mentioned, and thus it
> is
>
>> possible to make CGA verification succeed for two different hashes for two
>
>> different values of sec (one with lower sec value being easier to generate
>
>> than the other).
>
>
>> But didn't we know that already?
>
>  
>
> NO, as far as I know, up to now everybody thought that it is not possible to
> attack CGA with lower sec value while CGA node uses higher sec value. We
> knew that it is faster to break CGA sec value 0. We also thought that it
> would take 2^59 but this is not true too based on Birthday paradox attack. 
>
>  
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.
>
>> Does this have more to do with how/where CGA is applied or misapplied?
>
>>                                                                           
>
>  
>
> It is the problem of both CGA specification and also its combination with
> NDP specifications
>
>  
>
>> Since the 3 bits of the sec level are copied from the IID, won't any
> mismatch in
>
>> the sec value used to create the hash be picked up by a simple comparison
> of
>
>> the received IID with the machines local IID in the case of DAD?
>
>  
>
> The CGA node retrieve sec value from the source IP address of the attacker
> and not from his own packet and do not get it from his own. The following
> sentence is after step 4 that already the victim node retrieved the source
> IP address from the attacker's packet.
>
>  
>
>    5. Read the security parameter Sec from the three leftmost bits of
>
>       the 64-bit interface identifier of the address.  (Sec is an
>
>       unsigned 3-bit integer.)
>
>  
>
> The novelty of this attack is that the CGA node has different sec value than
> the attacker node so the attacker node always use sec value 0 disregard to
> the sec value of the CGA node. Before I explained that the sec value is
> retrieved from the attacker source IP address and the target and source IP
> are not compared which makes this attack possible. 

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.

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.
> This means, the sec value
> does not help the security of the CGA node. 
Not in isolation of a pure CGA IID, but it does in context where it is
used AFAICS.
> One of student helped us and
> wrote the attacking code, right now it is multicore code but he is going to
> also convert it to GPU code. I will share the code as soon as I arrive to my
> destination and have a chance to upload on the institute's server. (receive
> to my destination) . 
>
>  
So I still don't "get it"
>  
>
> Smile,
>
> Hosnieh
>
>
>

-- 
Regards,
RayH