RE: additional attack for multi6 threat draft?

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> > but in other cases, you may not even need to be a MiTM
> > For instance if you don't do any type of verification of the identity.
>
> An invalid example.
>
> On the Internet, RR based verification is MUST,

Why?
because there are some threats that have to be avoided. This one is just one
of them. Others are presented in the treats draft. IMHO we have to be aware
of all the threats so that we can design a proper solution. this is the goal
of the threats draft,i guess. (so that if someone comes up with an invalid
solution like the one i have used in the example, you can just point to the
threats document and simply say that the solution doesn't prevent threat
described in section 7.8 and you don't have to explain the problem all over
again, it becomes the author's responsability to show how his solution
prevents the threats described)

Besides, do you think that RR is a must for verifying locators or
identifiers o both?
I may agree with RR as a locator verification mechanisms, but i am not so
sure about its application as an identifier validation mechanism


> which has nothing to do with M6,

Is this a general comment or just specific to the threat i am descibing? i
mean do you think that all threats described in the threat draft are not M6
specific?


> which is why I said you need security threat draft on the plain Internet
today.

Well, the threats draft attempts to do soemthing similar to this... have you
checked section 3 of the draft?
Perhaps you could point what additional attacks are possible in the current
internet that are not considered there?

just to understand your position:
do you think we need a threat analysis draft?

>
> > OTOH, i really don't see how a MiTM can steal an identity when
> you are using
> > SIM, for instance. I mean, the identity is the hash of the
> public key, so
> > the only way to fake the identity would be to be capable of
> generating the
> > private key... so i don't see how the MiTM could ever do this?
>
> I assume you know well about marrige theory or birthday attack. So,
> if you are serious on security, hash should be 128 bit long of MD5,
> at least, though some people insist that MD5 is insecure and it
> should be 160 bit long of SHA.
>
> So, let's assume that the hash is 128 bit long.
>
> Note that the hashed value is psuedo random.
>
> The direct conclusion is that no one can memorize or type a psuedo
> random 32 hexadicimal value.
>
> That is, no human being identify hosts by 128 bit or longer hash
> value.
>
> So, what are you saying "the only way to fake the identity"?
>
> Can't you just say "DNS"?
>

No, because tcp don't use dns names to identify an endpoint involved in a
connection, it uses 128 bit long string. This 128 bit long string is the
identity of the other endpoint. So if you want to prevent the impersonation
of this identity, it seems a good idea to use the (hash) of the public key
as the identity.

OTOH i see your point. People don't use 128 bit long strings direclty, so
the weak point will be the mapping from the DNS to the strong identity. Well
this is choice we will have to make, i guess.
We can build a strong identity that may become a piece of a more secure
architecture (such as sim) or we can just try to find a solution that is
just as secure as today internet (like the noid approach) and wait for
security improvements in other areas, like in DNS security.

> Note also that, on the public Internet, please don't assume that
> you locally have all the hash values of public keys of hosts
> you want to communicate. Or, you can assume that you locally
> have all the public or shared keys of all the hosts. With the
> shared keys, just use IPsec or something like that.
>
> >>As a MITM, an attacker can, for example, contaminate DNS cache for
> >>persistent effect.
>
> > Well, there is a little difference here...
> >
> > As i mention, in the case that i am considering is the attacker the ones
> > that decides when the state is generated in the victim, so the
> attacker can
> > choose the moment that it is easier for him to do this.
> > In the DNS case, the attacker has to wait for the DNS query and
> intercept
> > it. So the attacker doesn't select the moment of the attack, it
> has to wait
> > the right moment
>
> An attacker can control when state is generated in a victim, if
> the attacker initiate communication with the victim and if the
> state is not already cached.
>
> In the DNS case, state is generated in a victim as a result of
> DNS query. The DNS is queried when communication is initiated.
>
> In the DNS case, an attacker can control when state is generated
> in a victim, if the attacker initiate communication with the
> victim and if the state is not already cached. The attacker does
> select the moment of the attack.
>

I fail to see this...
The dns query is performed by the initator if the communication.
The responding end of the communications does not perform a DNS query (in
general), it just sends back packets to the source address and it is not
even aware of the name of the initator.
So since the attacker is the one initiating the communication, the attacker
is the one that performs the dns query. The victim does not perform a DNS
query, so how comes that the victims DNS cache is attacked?

Regards, marcelo

> 							Masataka Ohta
>
>
>