Subject: additional attack for multi6 threat draft?

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 5 Dec 2003 11:56:52 +0100

Hi,

Perhaps there is an additional attack that should be included in the threat
draft

The attack would be something like this

an attacker X wants to impersonate another host B in future communications
initiated by A to B

(i will use mip notation to simplify)

X sends to A a sort of BU binding X as the CoA and B as the HoA (in order to
do this X may need to be on the path between A and B, but if this is only
for a short period of time that attack can be successful)
If the attacker has a mean to maintain the binding in host A (for instance
sending periodic pings to it or other packets that will end up being
discarded by the ULP), then when eventually A wants to communicate with B, A
will send packets to X

Do you think this is a real threat?
IMHO, this is the real attack that can be prevented by limiting BCE in mip6.

I think this threat is not considered in the threat draft...
IMHO this is related to the attacks included in the 4.1.2 section about
premeditated redirection but i don't think that it is inlcuded there.

the example considered in the threat draft is that  A and B will comunicate,
so X sends a BU to B containing A as a HoA and X as a CoA
then the described attack continues considering that A tries to communicate
with B and the problems that arise

The attack described above is about the case when B initiates the
communication. IMHO this is potentially more dangerous, because probably X
will be able to impersonate A, and B will actually believe that it is
communicating with A when he is actually communicating with X

So if you think this is important enough to be included, i can try to write
a paragraph about it if you want.

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Dec 2003 20:35:37 +0900

marcelo;

> for a short period of time that attack can be successful)

MITM can do almost anything, of course.

> Do you think this is a real threat?

No, of course.

> the example considered in the threat draft is that  A and B will comunicate,

ALl you need is a threat draft with plain IP.

> (i will use mip notation to simplify)

Just FYI, MIPv6 or any mobility protocol with triangular
elimination can be a cause of new type of threat, even
though no MITM is involed.

However, triangular emilination is an important feature of MIPv6
and it has nothing to do with multi6.

						Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 5 Dec 2003 17:38:12 +0100

> MITM can do almost anything, of course.

Well, this is not striclty related with MiTM attack, but with redirection
for future usage, let me try to explain.

some multihoming support mechanism send a message from one node to its
correspondent node on a communication that basically contians the following
information:
I am A, i.e. my identifier is A
and
I am located at B, i.e. my locator is B

in sum this means that A can be reached at location B

The receiver of such message has to verify both the identity and the
location

If the location is not verified, flooding attacks are possible

If the identity is not verified, identity can be hijacked

Direct impersonation attacks are those where the attacker is the one that
attempts to establish the communication pretending to be another node (which
are already considered in the draft IMHO)

The attack that i am considering is about hijacking identitity but not in a
direct form, as above but in a reverse form. In this case hte attacker
creates some false state in the victim, so that in the future, when the
victim attempts to communicate with a given server, it will direct its
packets to the attacker,(who will be able to impersonate the server)

Now, there are different proposals to verify the identity, depending on the
type of identifier that it is being used.

If ip addresses are used as identifiers (as in the case of mip), return
routability can be used to verify the identity.
the problem in this case, is that the attacker can play as a MITM for a
*limited* period of time and manage to beat the verification mechanism as
long as the acquired authorization information is valid.

This implies that return routability cannot be used to protect from this
attacks, since this allows transient MITM to achieve the same effect of
permanent MITM, which IMHO is bad.

So, the proposed attack is not really related with MITM, but is more generic
However, transient MITM can manage to launch this attack when some specific
solution (such as return routability) are used (during the lifetime of the
verification information in the attacked node)

> and it has nothing to do with multi6.

I was just using mip terminology in order to make an example, but i guess
this was not a good choice, sorry for the confusion that this may have
caused.

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Dec 2003 08:27:45 +0900

marcelo;

> for future usage, let me try to explain.

X on the same shared link as A is a specific form of MITM.

> long as the acquired authorization information is valid.

Yes, it is a MITM.

As a MITM, an attacker can, for example, contaminate DNS cache for
persistent effect.

> permanent MITM, which IMHO is bad.

It is merely that RR can not be a protection against MITM.

That is a generic statement.

> So, the proposed attack is not really related with MITM, but is more generic

The attack is a specific, not generic, form of MITM attack.

> verification information in the attacked node)

DoS is so easy.

DoS by MITM is totally destructive that almost no security
mechanism works.

If you don't assume PKI, MITM will invalidate both cookies and
public key cryptographic technologies including but not limited
to DH.

If you assume PKI, compromised CAs are virtually MITM that there
is no real added security. ISPs are as realiable as CAs that there
is no point on relying on PKI instead of RR. It should also be noted
that, lacking cook protection, DoS effect of computationally
expensive public key cryptography is fatal.

In either case, attack by transient MITM at the time of initial
cryptographic computation (with DH or PKI) will be effective
for the lifetime.

The only meaningful protection is by having common secret in advance
and althenticate all the packets, though the approach does not scale.

So far, nothing is mult6 specific.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 7 Dec 2003 11:30:30 +0100

> > long as the acquired authorization information is valid.

in THIS case, is MiTM for a limited period of time. (Please note the
difference between an attack that requires MiTM during the complete attack
and an attack that only requires MiTM during a short period of time and
allowing that the attack to go on after the attacker is no longer a MiTM)

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. In
this case you don't even have to intercept packets. this would apply for
instance to the delayed set-up. for instance, suppose that we are using the
delayed setup model. I send my id and my locator without any verification
and i end up the communication before the verification is performed. then
what happens to the state binding the identifier and the locator? if this
state is preserved, the correspondent node may use it when establishing
communication with the identifier previously used (but not verified). So in
order to prevent this, the state should not be used for other
communications.

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?

> As a MITM, an attacker can, for example, contaminate DNS cache for

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

regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Dec 2003 17:20:00 +0900

marcelo;

> in THIS case, is MiTM for a limited period of time.

In this case and in other cases, yes.

> 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, which has nothing
to do with M6, which is why I said you need security threat draft
on the plain Internet today.

> 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"?

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.

> it. So the attacker doesn't select the moment of the attack, it has to wait

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.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 8 Dec 2003 11:50:53 +0100

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

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

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Dec 2003 21:03:14 +0900

marcelo;

Why?

Can you name some protocol that does not do this?

If you can't, guess "why?".

						Masataka Ohta

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Dec 2003 06:26:45 -0600

OK, this is not a helpful response.

If RR based verification really is a MUST, shouldn't that be written
down somewhere (more authoritative than the multi6 mailing list),
along with at least a basic explanation of why?

Can anyone provide a pointer to such a requirement, preferably in an
archival document that is at least BCP (and preferably
standards-track)?

FWIW, the biggest impediment for moving past "the IESG must review and
approve all specifications" is the view that working groups don't
understand requirements like this one. Having WG participants "guess
why" isn't likely to help improve understanding.

Spencer

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Dec 2003 22:15:45 +0900

Spencer Dawkins;

> along with at least a basic explanation of why?

That's what I said necessary several posts ago.

> why" isn't likely to help improve understanding.

As IESG is ignorant on producing such a document, don't expect me
to overrule it.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 8 Dec 2003 14:48:51 +0100

> Can you name some protocol that does not do this?

Take mip and remove the rr check.
You are supposedly talking to the HoA but you are sending packets to the
CoA, so you don't have a RR check of the address that you are supposed to be
talking to i.e. the HoA

Again, RR is fine to verify locators but it is not so great to verify
identifiers.

In multi6 where we may need redirection, you cannot assume that RR will be
available to verify identities

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 8 Dec 2003 14:48:53 +0100

Hi Spencer,

My interpretation of Masataka comment is the following

When you communicate with another host, you exchange packets with it, so
basically you are performing RR check since you are able to actually
exchange packets. Is this what you meant Masataka?

The problem in multi6 is that since we may need to change the locator during
the lifetime of an established asociation, we may still think that we are
communication with the initial locator while in reallity packets are being
diverted to a new alternative address. In this case, the implicit RR check
is being performed to new locator and not to the initial locator that the
initiating entities think they are communicating to.

So IMHO RR is good to verify locators but not so good to verify identities

Hope this makes some sense

regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Spencer Dawkins
> Enviado el: lunes, 08 de diciembre de 2003 13:27
> Para: [email-masked]
> Asunto: Re: additional attack for multi6 threat draft?
>
>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 05:13:25 +0900

marcelo;

> CoA, so you don't have a RR check of the address that you are supposed to be

You are talking about triangle elimination, which, as I mentioned, is
a cause of new form of redirection attack.

However, it is purely a mobility issue having nothing to do with
multihoming.

A CN and a MN can use all the complex security mechanism to locate
and identify each other. However, it does not prevent MN redirection
of traffic of CN to a DOS victim. The victim can be protected from
DoS, if 8+8 is used, though the network around the victim still suffer.

> Again, RR is fine to verify locators but it is not so great to verify

RR check involves cookie exchange, which is to verify the identity.
 
> available to verify identities

Cookie is our friend.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 10:40:22 +0100

Gentlemen, I think this thread has reached the end of its
useful life. When Erik updates the threats draft, I am sure he
will know whether to add this point to it.

Thanks
  Brian
  co-chair hat on

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 19:06:37 +0900

Brian;

> will know whether to add this point to it.

Erik?

Huh?

I, not Erik, find the thread is still useful to write a threats
draft.

>   co-chair hat on

Are you sure?

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 15:00:01 +0100

Erik Nordmark is the editor of the threats draft.
draft-nordmark-multi6-threats-00.txt

Yes, I am sure I am co-chair of this WG.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 00:22:50 +0900

Brian;

> draft-nordmark-multi6-threats-00.txt

Erik is an editor of a threets draft.

That is, Erik may write his own draft and I or someon else
may write another, which is the agreement of the last
meeting.

> Yes, I am sure I am co-chair of this WG.

I am not.

Or, are you sure that draft-nordmark-multi6-threats-00.txt is a WG
draft?

						Masataka Ohta

---

From: Kurtis Lindqvist <[email-masked]>
Date: Tue, 9 Dec 2003 17:50:34 +0200 (EET)

> > Yes, I am sure I am co-chair of this WG.

I can confirm. Brian is my co-chair of this WG.

> Or, are you sure that draft-nordmark-multi6-threats-00.txt is a WG

It is not an official working-group draft, but it is a draft that is the
result of discussions in here among other places.

I don't think this discussion is leading us further so I think we can drop
it here.

- kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 06:52:54 +0900

Kurtis;

> I can confirm. Brian is my co-chair of this WG.

Then, who are you?

> result of discussions in here among other places.

And, the result is that it was not chosen as the WG document.

> I don't think this discussion is leading us further so I think we can drop

If either of you were acting as a chair, you have better things to
do other than confusing terminologies and interrupting an active
thread

							Masataka Ohta

---

From: Kurtis Lindqvist <[email-masked]>
Date: Wed, 10 Dec 2003 09:22:56 +0200 (EET)

Ohta-san,

> And, the result is that it was not chosen as the WG document.

This question has never been asked. It probably will be, but it hasn't.
And as a matter of fact, you are the only one I see disagreeing. You do
not make up this WG.

> do other than confusing terminologies and interrupting an active

An active thread is not the same as a constructive or contributing thread.
If you want to continue the thread, post comments and details on the
proposals.

- kurtis -

---

From: Kurtis Lindqvist <[email-masked]>
Date: Wed, 10 Dec 2003 10:04:20 +0200 (EET)

On Wed, 10 Dec 2003, Kurtis Lindqvist wrote:

[snip]

> If you want to continue the thread, post comments and details on the

WG-chair hat on

- kurtis -