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

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

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

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. 

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

I guess you answered yourself...

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

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)

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

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!

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

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. 

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

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.

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

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

Smile,
Hosnieh