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

["Hosnieh Rafiee" <[e-mail]>]

Hi Jean,

Please find my responses as below:


>o No comparison of source address with target address
>This argument is not valid because, when SEND is used the "Target Address
in Neighbor Advertisement is required to be equal to the source address of
the packet" (cf. RFC 3971, Section 7.4) 

The section you discussed about is " SeND limitations" and nothing about the
comparison of source address with the target address. I guess you pointed me
to somewhere that does not talk about what you argued. I could not find
anything regarding what you said in SeND RFC.  What is important in SeND RFC
is proceeding rules for receiver. Because, I, as a sender can follow my own
rule! But if the receiver checks this conditions then I might fail which
unfortunately does not happen in SeND RFC. Check here "5.1.2. Processing
Rules for Receivers".


>o Ignoring Sec Value during DAD
>I agree with Christian: the check is done over the complete target address
(i.e., including Prefix, Sec value, u/g bits)
>Indeed, DAD fails, when receiving a NA message, "if the target address is
tentative", meaning "the tentative address is not unique" (cf. RFC 4862,
Section 5.4.4).

I do not agree with Christian since he also does not accept the case that is
clearly said in CGA RFC itself (as Ray pointed out). However, what I said
here is that CGA ALONE is vulnerable and dependent to SeND. SeND also can
only authorize the routers and prevent the attack about sec value only for
routers. The reason is that, it is not operationally ideal  to have
certification for every single nodes in the network. This makes the SeND
deployment so complicated. I refer you to other draft I wrote about "local
security".  So, the purpose of SeND in other nodes (rather than routers) is
that to help CGA to prevent replay attack by including nonce and timestamp
to the packets. This is because again CGA, ALONE, cannot also prevent replay
attack. 
Now about DAD attack. Since CGA is considered now 59 bits, we can consider
the attacks over these bits regardless of CGA sec value. CGA node in that
case has a temporary source address but not the attacker node. It is the CGA
node who wants to check whether or not anybody else has the same IP address.
If anybody can claim and the verification is successful, then the CGA node
gives up and not the attacker. The CGA node checks the target address and
verify the source address. But in nowhere in processing, either SeND nor
NDP, I could find that target address is compared to source address (please
point me to that section in RFC if I missed it). What I can remember, when I
myself implemented SeND for windows, I just included this condition to avoid
some attacks but , at that time, I still did not think that CGA sec value
can be of no use because of verification steps. 
In SeND there is processing for sender but does it help?? No! because for
verifier node, the "receiver processing is important". But I am attacker, I
do not need to follow the SeND specification for sender if the receiver does
not check it. My receiver even does not checks this situation!! In this case
as I explained the situation, the verification is successful and I can
prevent the CGA  node from IP address configuration. Sec value also could
not help to complicate this process because of the problem in SeND and CGA
specifications. 

Now, for another attack, update all neighboring cache. Since the
verification is the same process, I guess the attacker has no problem to
update the caches or claim to be the victim CGA node in the network and
start any communications with other nodes on behalf (forge the identity).
This attack does not need to be done immediately(the attacker can do it
offline) and start it whenever he wants.. 


>o Collision vs. Pre-image attack
>IMHO, you assume that attack is a real-time one: when a victim node
generates a CGA (in fact, an IID), with your attack, the malicious node
wants to generate the same _given_ CGA (in fact, the same IID).
>So, I agree with Marcelo: this is a pre-image attack ...or a second
pre-image attack (as the malicious node knows the CGA parameters).

We are actually providing this attack. I am also in email contact with some
crypto expert professors and waiting for their opinions about one of my
ideas then I share it here. The important case is that, SHA1 divides the
messages to block of 512 bits and work on each blocks. We all know that
finding a collision for a certain value might be hard when the attacker does
not know the plain text. This is not the case for CGA attacker. All the
plain text (modifier, etc) is sent with the packet. What the attacker needs
to do is use the same values except the public key. If the public key is
2046 bits, since 26 bytes are already the same, the attacker can use the RSA
shorter key size (512 or less) and only play with the endings. Until the
match happens. Since we have to consider the blocks of 512 bits, I am just
trying to have some experiments to find a number that fill the correct value
of the first block. One possibility is to use a part of public key of the
real node and find a private key, It can be any number but since it is only
a part of public key or a part of a prime number, then with sieve prime
approach, I guess it is possible to find a faster match so that this attack
can be really applicable during DAD process.



>o RSA private/public keys

>One point I don't understand in your attack is that, even if you find a
collision, meaning you "find" a potential value for the public key, how did
you get the associated private key needed to generate the RSA Signature
option and providing the CGA's proof of ownership?

The attacker generates the public/private key itself. Either it plays with
modifier or it uses a short key size public key, as I explained in last
paragraph and tries to generate the same value. This means the attacker can
sign the message with his own private key and not depends on the private key
of the CGA node. This is only not possible when the router is authorized.
Since this authorization in SeND is only for routers and not operationally
ideal for all nodes, the attacker would not encounter any problem. 
As you know, in CGA every node, itself, generates his own public/private
keys and start CGA process and generates his own packets. CPS and CPA is
only for routers. So, the attacker does this the same but only tries to have
the values for public key that generates the same collision. He is free to
either use the same modifier and other values that the legitimate CGA used
or use his own. But I guess if he uses the same values and just change the
last blocks of SHA1, then it is easier for him to generate the same values
faster but you can also wait for the email from those professors and also
our experimental results. I would share the code here
http://ipv6ssl.hpi.uni-potsdam.de/ 




Smile,
Hosnieh