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

[Ray Hunter <[e-mail]>]

inline
> Hosnieh Rafiee <mailto:[e-mail]>
> 1 December 2013 23:19
>> 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, 
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
> 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. 
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.


>>>> 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. 
Already read those.

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


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


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

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
> 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.
Define "many". Certainly not my operational experience.

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

Although this is orthogonal to the core discussion.


> Smile,
> Hosnieh
>
>

-- 
Regards,
RayH