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

From: Ray Hunter <[email-masked]>
Date: Sun, 01 Dec 2013 10:13:01 +0100

> Hosnieh Rafiee <mailto:[email-masked]>
> 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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 1 Dec 2013 23:19:04 +0100

> I responded that it was not novel, together with the referenced RFC to
show it
> was not novel.

Good!  First, nobody believed on this attack (you can yourself refer to
previous posts of Christian and others) second, SeND cannot prevent it as
well and only possible to prevent for routers but not nodes since you do not
authorize the public key of nodes but the routers. My reason will be at the
end of this message. 

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

I guess you answered yourself...

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

Not true!  Otherwise you register all your public keys in a CA that you
really do not do it in practice and it is only for routers. Even for
routers, the node MUST trust the router during IP configuration so that it
can configure its IP address and then try to connect to internet and check
the validity of the router's certificate. So, the attacker can forge the
routers identity for a short moment before this node can verify this router
from a trusted authority. But again this never happens for nodes in the
network. The reason is operational problems (costs and too much work to
register all nodes in the CA)

> > (unnecessary adding  expenses and complexity while the SSAS itself can
> > do this job without this help).
> 
> You guess wrong.
> 
all
> on-link traffic via the router.

Sorry, you again talking about routers. I keep telling you that the routers
is out of the scope of SSAS otherwise you use other methods to certified the
routers (you need a centralized node). What I claimed in SSAS and repeating
here is that providng the proof of IP address ownership but not authorize
the router. This is what also you cannot expect from CGA or any other
approaches that they generate something themselves!

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

Not all networks support Active directory and probably not all enterprise
would prefer to use active directory.

Please check rfc 6494 and rfc 6495. Actually my RPKI model is/was based on
one of these RFC. 

> SSAS mandates use of RPKI.

Wrong! Who said this. SSAS does its job but for router authorization, you
need to use RPKI. 

Internet.
> backbone: the main purpose of BGP being to enable off-site communication.

You're wrong. The RPKI that I am talking is different than BGP and it is for
SeND. So, I ask you please check the reference RFC. BTW, if you checked the
SeND RFC in html format you could see the update on that RFC by two other
RFCs for RPKI. So I recommend you to check it out. 

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

Your assumption is wrong. SSAS does the same as CGA does with better
performance, less packet size and better security. If you want router
authorization use other approaches along with SSAS that my recommendation is
RPKI model.

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

Not true. Many enterprise does not support AD. So, you cannot based your
work on other services.

Smile,
Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Dec 2013 10:37:12 +0100

inline
> 1 December 2013 23:19
> previous posts of Christian and others) second, 
I think everyone agrees you can spoof CGA by generating a collision with
a different sec value.

Please re read Christian's and others' responses carefully.

I certainly agree you can create a collision when using CGA stand alone,
but since the sec value is different, this is a different address, and
so I conclude that this not a problem in the cases where CGA is
currently deployed.

> SeND cannot prevent it as
I fundamentally disagree with you on this point.

The SEND RFC 3971 does NOT limit the signature option to routers only.
Not at all.

SEND defines how routers can be authenticated through signatures and
certificates.
It leaves end node to end node certification completely open.

quote "Where hosts themselves are certified by a trust anchor, these
   messages MAY also optionally be used between hosts to acquire the
   peer's certification path.  However, the details of such usage are
   beyond the scope of this specification.
"

Also "The Key Hash field MUST indicate the use of a known public key,
      either one learned from a preceding CGA option in the same
      message, or one known by other means."

Note "or one known by other means "

One alternative would be to deploy a centralized certification model, so
that all public keys can be traced back to a trust anchor and are thus
"known".

Another alternative would be by detecting a change of public key in a
newly received SEND message compared to an existing entry in the
neighbor cache associated with a CGA/ SEND + RSA signature option, and
use this as a valid reason to discard any (unsolicited) update (from an
attacker) using a "new" (from the defender's perspective) public key
generated by the attacker, without any need for a centralized
certificate chain.

This is how SSH normally works in practice in a decentralized model
(with cached keys stored on a local keychain, with an initial leap of
faith confirmed by the user). It is also a pretty successful model in
operations.

So to conclude that "SeND _cannot_ prevent it" is completely unproven IMHO.

I also believe that any such extension could be implemented either as
part of an implementation decision, or as an extension to the
application of the RSA Signature option already defined in RFC3971,
without throwing away all of SEND and starting afresh.

> Please check rfc 6494 and rfc 6495. Actually my RPKI model is/was based on
Already read those.

> RFCs for RPKI. So I recommend you to check it out. 

You reference 6494.

6494 contains a definition of RPKI in Section 3

  RPKI                          Resource PKI established in accordance 
with [RFC6480].

So 6494 references 6480

6480 is the definition of RPKI, "An Infrastructure to Support Secure
Internet Routing" => BGP

> Your assumption is wrong. 

Do deny that importing a global trust model into local infrastructure
may have negative consequences on the security of local communications?

I know many enterprises who adopt an onion skin security model, and
importing trust from an external zone to an internal trusted zone is a
definite no-no.

> SSAS does the same as CGA does with better
> performance, less packet size and better security. 

That may be true. I personally doubt it.

My main point is that we already have SEND.

My concern is that this is yet another completely new protocol, so I'd
like to understand why it's needed.

IMHO despite many emails back and forth, we still have not yet established

1) what is novel about your claimed attack.

2) what exactly in SEND is broken and thus needs fixing.

I also believe that the fundamental deployment problem is one of:

a) establishing a trust relationship between 2 end nodes on a link,
Alice and Bob, for conducting on-link communications, whilst excluding
the attacker Eve's ability to disrupt that relationship (via coupling
one or more IPv6 addresses and MAC addresses to the identity of the end
nodes Alice and Bob);

and

b) establishing separate trust relationships between Alice with the
default router(s), and Bob with the default router(s), for conducting
off-link communications, again whilst neutralizing Eve's ability to
either spoof Alice or Bob for off-site communications, or to disrupt
that communication via conducting a DOS attack or attacking the trust
relationship.

That's a tough problem, and I don't see how your proposal advances our
ability to solve that problem.

Others may disagree.

> If you want router
Define "many". Certainly not my operational experience.

If you don't like "AD", replace with "Kerberos".

Although this is orthogonal to the core discussion.

-- 
Regards,
RayH