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

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

> > Yes, it can. Because actually the problem is in verification steps and
> > not in generation.
> 
> 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.

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. 


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


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