[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New multi6 draft: WIMP

Hi,

marcelo bagnulo wrote:

If so, wouldn't this imply that an attacker sending INIT messages could
force the responder to gnerate hash chains, sort of DoS attack?



[...]



A short hash chain generation is a quite fast operation compared to
signature calculation.



why do you compare it with the processing required to perform a signature
calculation?

I mean if i were an attacker, i would do the following:

The goal of the DoS attack is to consume the processing power by soliciting
the victim to produce (useless) hash chains.

So, the attacker generates a random number as an ID(I) and also a
challenge(I) and then simply generate a random string which length is the
same than the expected length of the HMAC_INIT. I think the attacker can do
this because the victim (i.e. the responder) cannot verify the HMAC_INIT
since it doesn't know H0(I).

The attacker can generate as much INIT messages as he wants, he just has to
add 1 to the ID(I) values (in order to avoid the duplication of IDs)

So, the attacker can force the responder to generate hash chains based on
the ID(I).

As far as i know (note that i am no security expert nor anything close to
this), the idea to avoid DoS attacks is to impose more workload to the
initiator to the responder.

Now, in this case, in order to generate INIT messages the initiator just has
to perform an addition operation (adding 1 to the ID(I))

However, the responder has to generate a hash chain.

I don't have computation time values but i would say that the responder task
is more time consuming than the attacker task.
Am i missing something?




You are right. DoS is always a difficult problem. There is a trade-off between
DoS resistance and other security features. The current hash chain
generation is designed to support state-loss, and it is dependent of parameters
coming from the initiator.

Basically, the responder could protect the HMAC_CC with a local secret and
generate the hash chain after receiving CCR message. In that case, the responder
could not bind the CC and CONF messages together. The protocol were open for
MitM attack. In other words, an attacker could send CONF message before the
authentic responder.

We have to think more about the DoS situation. However, I would not like to
include any puzzle to the INIT message.



A short description:

Once Responder receives INIT message it protects the received values,
including HMAC_INIT, with HMAC_CC. The responder uses the temporary hash
chain value as a key in HMAC_CC. Finally, the responder receives CCR


message


and recomputes the hash chain. It uses the long term secret to recompute
the chain.
The responder verifies HMAC_CC to see that it already has reveived INIT
message with a specific ID pair. The initiator, in turn, discloses its
anchor value to prove that is was reachable in the specific location.



Well, this is not really a big issue, but i think that the proof that the
initiator is reachable at the specific location is provided by the fact that
the initiator has received the HMAC_CC value (and he is proving it because
he is including it in the CCR packet)



Yes!

Disclosing the anchor value does not prove that he is reachable at the
specific location. Displaying the anchor value proves that the initiator has
generated both the INIT message and the CCR message.



Right.

Now, the responder is stateless and thanks to the anchor values it can
verify that the same initiator has sent both the INIT and the CCR message.

But, as i said, this is really minor.

[...]






perfect, thanks

IMHO you should include this example in the draft, it really makes things so
much clearer (at least for me)



Ok. I'll put it into the draft


I think that WIMP may be susceptible to the following hijacking attack. Let
me know if i am wrong.

Attacker A with address IPA
Server S with IP=IPS and FQDN=www.server.com
Victim V with IP=IPV and FQDN=FQDNV

The attacker will try to impersonate S. Now if you consider that S is
server, usually is V who contacts (think for instance a newspaper web server
where V reads the news every morning). So the attacker will try to establish
some malicious state in V so that when V tries to send packets to S, he will
actually send them to A.

The attacker calculates ID(S)=Hash(www.server.com) and ID(V)=Hash(FQDNV)
The attacker sends a INIT value with ID(I)=ID(S) and ID(R)=ID(V) using its
own IP address

Now the attacker has generated this state in V. It can preserve this state
by simply sending periodical pings or just UDP packets to unused ports
(since WIMP is below UDP, this would be enough to preserve the state at the
wimp layer, right?)

Eventually, V will try to contact S to read the news.

At this point, V will calculate Hash(www.server.com)

Considering that V already has a state with ID(R)=Hash(www.server.com) and
according to the rule 2 described in section 4.1, V will simply use the
available state in the wimp layer.

This means that when V tries to communicate with S, V will be actually
sending packets to the IP address associated to this state, that is IPA, so
V will send packets to the attacker. So the attacker will impersonate the
server.

Would this attack work?



Unfortunately it works :-) thanks! We can fix the problem in a couple of ways.

1) the initiator must verify that the existing context has at least one verified
IP addresses that corresponds the IP addresses in the DNS.

or

2) The initiating party must not re-use a context if it is initiated by other party.
As a consequence, p2p applications will have two contexts. One per direction.

Br, Jukka

Thanks, marcelo




Br, Jukka



Thanks, marcelo











-----Mensaje original-----
De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
nombre de Jukka Ylitalo
Enviado el: jueves, 29 de enero de 2004 10:09
Para: multi6@ops.ietf.org
Asunto: New multi6 draft: WIMP


(uh oh, the previous email was incorrectly aligned)

Hi,

We have submitted a new multi6 draft to I-D directory. The draft
defines a Weak Identifier Multihoming Protocol (WIMP), and we
wrote it in order to see how opportunistic/weak authentication
methods could
be used to solve the multi6 problem.

WIMP is one of those protocols that introduce a new protocol layer
between IP and upper layers. Our approach uses some very basic
cryptograpahic funtions (reverse hash chains and secret splitting) in
order to have light and (hopefully) simple solution. The protocol
is not buller broof from security point of view, however, it intends
to be secure enough and easy to implement.

We hope it will stimulate discussion on various solution to
multi6 problem.

See more details from the draft itself, available in:

http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt

Thanks, Jukka Ylitalo