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

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 25 Nov 2013 23:52:23 +0100

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
Status:          http://datatracker.ietf.org/doc/draft-rafiee-6man-cga-attack
Htmlized:        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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ray Hunter <[email-masked]>
Date: Tue, 26 Nov 2013 17:22:31 +0100

>    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?

Does this have more to do with how/where CGA is applied or misapplied?

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?

i.e. if the attacker sets sec=0 (to allow them to perform a simple fast
search to attack machines using sec =1 ) and the target machine has used
sec =1, the CGA check will pass to step 7, but the source IPv6 address
and the local interface address are different, so the machine knows not
to "waive his rights" to it's own address as you put it, even if the
address was still marked as tentative. If DAD had already completed, I
don't see that this would have any effect.

And the other way on, if the attacker sets sec=1 and the target machine
has sec = 0, the CGA will pass, but finding a collision with sec =1
should be a harder problem to solve, and again the addresses will not match.

So I have to say that I do not understand the novelty of the attack,
unless this is an implementation specific issue, rather than a standards
issue.

-- 
Regards,
RayH

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 26 Nov 2013 18:12:47 +0100

Hi Ray,

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

> > has been successfully submitted by Hosnieh Rafiee and posted to the IETF

> repository.

> > Title:                               Possible Attack on
Cryptographically Generated Addresses

> (CGA)

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

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

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. This means, the sec value
does not help the security of the CGA node. 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) . 

Smile,

Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Tue, 26 Nov 2013 18:51:13 +0100

> Hosnieh Rafiee <mailto:[email-masked]>
> 26 November 2013 18:12
> Hi Ray,
>
>  
>
>
>
>
>> Hosnieh Rafiee wrote:
>
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.
> 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
So I still don't "get it"

-- 
Regards,
RayH

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Nov 2013 02:20:13 +0000

>> I agree the CGA information will match in the case mentioned, and thus it is
> 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. 

The CGA mechanism protects an IPv6 address. All the identifier bits are part of the IPv6 address. If an attacker uses a different SEC value, it is not attacking the protected IPv6 address, but a different one. 

> We also thought that it would take 2^59 but this is not true too based on Birthday paradox attack. 

This is a serious misunderstanding of the birthday paradox. The paradox states that if a number can take N values, it takes about sqrt(N) random trials for having 50% chance to find the same number twice. But the number found is a random number.

The birthday paradox does not apply in the scenario where you try to find a specific value. If a number can take N values, it takes about N/2 trials before having 50% chance to find the target number. 

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

So what? The attacker ends up using an IPv6 address that has many bits in common as the target address, but it different. There is no masquerading. The attack that you are describing just does not work.

Hosnieh, your draft also mentions a duplicate address attack. That attack is already described in RFC 3971 (SEND), with a proposed mitigation:

   9.2.3.  Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [22].  SEND counters
   this attack by requiring that the Neighbor Advertisements sent as
   responses to DAD include an RSA Signature option and proof of
   authorization to use the interface identifier in the address being
   tested.  If these prerequisites are not met, the node performing DAD
   discards the responses.

Do you have a novel way to break these mitigations?

-- Christian Huitema