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

[Ray Hunter <[e-mail]>]

> Hosnieh Rafiee <mailto:[e-mail]>
> 29 November 2013 22:43
>>> 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.
>
This portion of the thread started because you claimed in your mail of
26/11 18:12 that the attack was novel.
I responded that it was not novel, together with the referenced RFC to
show it was not novel.

We now seem to agree that the attack is possible but not novel.

>> 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. 
I am really unsure what your novel claim now is.

That standard NDP RFC 4861 + CGA RFC3972 (without SEND or some other
certificate based validation) is partially vulnerable to on-link
spoofing due to existence of hash collisions with a different sec value?

Of course it is.

It even says so in Section 7.1 of RFC 3972

" For each valid CGA Parameters data structure, there are 4*(Sec+1)
   different CGAs that match the value.  This is because decrementing
   the Sec value in the three leftmost bits of the interface identifier
   does not invalidate the address, and the verifier ignores the values
   of the "u" and "g" bits.  In SEND, this does not have any security or
   implementation implications."

Note the last sentence: CGA (when used in combination with SEND) does
not have any security or implementation implications.

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

You guess wrong.

If you want to certify two end nodes to each other on a LAN, you need a
common trust anchor.

AFAICS One way of doing that is for them both to trust the router.
They can do that with SEND today + router certification and communicate
all on-link traffic via the router.

Another method (not defined in an RFC) is to leverage some other trust
anchor such as AD.

SEND allows the deployer to specify the appropriate trust anchor. It may
use RPKI. (not specified in the SEND RFC)
SEND allows end nodes to verify each other using the RSA signature
option (although the exact mechanism is not specified in the RFC)

SSAS mandates use of RPKI.

RPKI assumes off site connectivity to global servers on the public
Internet.

Off site connectivity may not be available.

RPKI seems entirely appropriate for securing BGP on the global Internet
backbone: the main purpose of BGP being to enable off-site communication.

But because you are now making your ability to conduct local
communication dependent on a global RPKI infrastructure, you might
actually be introducing a new off-site triggered attack on local
communications. I know plenty of people who want their local
communications to survive even in an extended period of external
connectivity being down.

It's a question of your threat model and risk tolerance which trust
anchor is appropriate.

I'd rather not see the trust anchor mandated in the protocol itself.

> 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. 
>
SEND also allows this.
>
>> 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 mentioned router. You are putting words in my mouth. I mentioned
a signature option.
>  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?
An assumption that is not specified in any RFC.

RFC3971 "The deployment model for trust anchors can be either a globally
   rooted public key infrastructure or a more local, decentralized
   deployment model similar to that currently used for TLS in Web
   servers."

FYI Many enterprises already have deployed a machine certificate per end
node (Active Directory) (that could also be leveraged for use with SEND
once a connection to the domain controller has been established) but in
any case I don't agree with your point of this being an arduous burden.
> Please also read NDP document and check the CGA verification again.
Please provide references. I read the RFC's that I consider relevant,
and still do not understand how your attack scenario is novel or
effective in practice.
>
> Smile,
> Hosnieh
>
>
>

-- 
Regards,
RayH