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

[George Michaelson <[e-mail]>]

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 <[e-mail]> 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.
>
> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>