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

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 29 Nov 2013 01:28:35 +0100

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

---

From: George Michaelson <[email-masked]>
Date: Fri, 29 Nov 2013 10:40:43 +1000

forgive neophyte questions: the attacker, using this hash-collision
mechanism, has effectively gained the right to subvert *one* CGA identified
host, right?

not an entire /56 subnet: one specific host.

and, they still have to achieve path injection, spoofed source, TCP/IP
sequencing &c, in order to exploit this attack, against this one host.
right?

and, the cost of that one host, and its location, is not of the attackers
chosing: they don't know in advance, that they can gain entry to any
specific CGA, so they cannot direct the attack against a known CGA
endpoint: they opportunisitically can attack *SOME* CGA, by virtue of the
hash collision: its not clear if its a high- or a low- value endpoint.

On Fri, Nov 29, 2013 at 10:28 AM, Hosnieh Rafiee <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Nov 2013 03:11:30 +0000

>  forgive neophyte questions: the attacker, using this hash-collision mechanism, has effectively gained the right to subvert *one* CGA identified 
> host, right?

No they did not even achieve that. They found the same random address twice, but they did not find a match for a specific target.

-- Christian Huitema

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 29 Nov 2013 08:31:32 +0100

Yes, true.

Yes, This is actually what I am trying to say and all of this is because of
the combination of NDP with CGA and forgetting some steps in verifications.

chosing: they don't know in advance, that they can gain entry to any
specific CGA, so they cannot direct the attack against a known CGA endpoint:
they opportunisitically can attack *SOME* CGA, by virtue of the hash
collision: its not clear if its a high- or a low- value endpoint.

That is true. You are the attacker, join network and eavesdrop and now want
to forge the identity of the nodes. CGA claimed to make it harder but it is
not as hard as we thought before.

Smile,
Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Fri, 29 Nov 2013 21:59:38 +0100

> Hosnieh Rafiee <mailto:[email-masked]>
> 29 November 2013 01:28

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.
> is where gives an attacker the possibility to forge the identity of the
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.
> explained in CGA-attack, neither the SeND nor CGA could really be any help
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.
> expected and it is dependent to CGA and now CGA also cannot protect the node
I disagree.
>
> Smile,
> Hosnieh
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 29 Nov 2013 22:43:30 +0100

> > Yes, it can. Because actually the problem is in verification steps and
> > not in generation.
> 
created
> a colliding version of Alice's hash, but with a different sec value.

I don't understand what is the problem here. I say this attack is possible.

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

Again we're in a loop... Please please ask you once read the NDP document. I
do not know how to explain to you that target address is checked which is
exactly the victim address but verification is on source address. You can
consider it as a problem of NDP specification. 

> 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".
> 
receiving
> node.

I guess you missed the point and now talking about two different things.
This section is for routers and not the other nodes since it is not
efficient and feasible to register all nodes of the network in a CA
(unnecessary adding  expenses and complexity while the SSAS itself can do
this job without this help). In other words, this step is not require for
nodes as for the nodes it is enough that other nodes know that he is the
owner of this IP address and does not spoof it.  The purpose of CGA or SSAS
is to prove the IP address ownership but they cannot authorize the router.

Secondly, In SSAS, the whole interface ID is compared and considered and no
bits are ignored as CGA verification does so this problem will not happen
with SSAS as any changes in interface ID causes the failure in verification.

Thirdly, why the CGA or SSAS uses the public key in IP address generation is
because if you only sign the message with your public key and your public
key is not associated with your IP address, one can easily spoof it and
generate another public/private key and sign the IP address and start
claiming the ownership of that. What makes it hard is the attacker now need
to prove that this IP address is associated with his own public key. If he
can do this then he can spoof the IP address of this legitimate 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?

Again here you're talking about routers, I never claimed that SSAS can
prevent RA spoofing but I said when SSAS uses the proposed RPKI it can do
that. What SSAS can do is do not let the other nodes to claim his IP
address.  If you only wait 2 more days, I will try to upload the other
document with the name "SeND deployment" and include this RPKI model there.
What you're talking is SeND deployment and not related to what I claimed in
SSAS or the possible attack for CGA.

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

Please check the feasibility of your scenario. Are you willing to register
all your nodes in CA and pay thousands of dollars for them while you see it
is not required and you can have local security for your nodes by applying
SSAS?
Please also read NDP document and check the CGA verification again.

Smile,
Hosnieh