[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New multi6 draft: WIMP
Hi Jukka,
thanks for this detailed explanation, more below...
[...]
> [Do not hesitate to ask more questions about this, if I my answer was
> not clear enough.]
I think i understand that part, i see now why it is stateless.
>
> >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?
[...]
> >The you state that:
> >"The initiator replies to the CC message with a context check reply
> > message (CCR) and proves that it was reachable at the specific
> > location by disclosing the anchor value."
[...]
> Excellent analysis! Thanks! However, as I pointed out above, the responder
> is able to recompute its hash chain without creating a state.
>
i understand the stateless part, buti a have a minor observation. see
below...
> 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)
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.
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.
[...]
> >2. Re-addressing exchange
> >
> >First, a simple question: the re-addressing exchange can be
> initiated by the
> >responder? (i think so, but i couldn't find it stated clearly in
> the draft)
> >
> >
> >
> Yes, the responder of the context establishment exchange is an initiator
> if it starts the re-addressing exchange. The initiator of an context
> establishment or re-addressing exchange is called the initiator.
> See below:
>
> Section 7:
> "The initiator of the context establishment exchange is called the
> initiator. Once the host-pair contexts are established, this initial
> distinction is lost. The sender of the REA message is called the
> initiator of the re-addressing exchange. In a case of state loss, the
> sender of the RESYNCH message becomes a responder."
>
> >Second, i am really having a hard time to understand how the key
> masks and
> >the key pieces work and how you can verify which of the locators are
> >reachable. I guess that part of the reasons is because my own
> comprehension
> >problems, but the fact that part of the explanation is contained
> in section
> >3.5 and that the rest is contained in section 6.12, where the
> packet format
> >is explained, is not helping me much :-(
> >Could you provide me a simpel example, with for instance a REA message
> >conatining 3 new locators, and detail which would be the AC1, AC2 and AC3
> >messages, how they are generated and which would be the ACR
> message (and its
> >generation)?
> >Sorry to ask this, but i am really stuck here...
> >
> >
> >
> You are right. That part needs more clarification in the draft. Thanks for
> commenting that. I have included a short example:
>
> REA:
>
> IP header: Addr-R, Addr-I1
> WIMP: IDs, Addr-I1, Addr-I2, Addr-I3, H1(I), H0_new(I), challenge, HMAC
>
> Secret splitting:
>
> I refer here the "2nd edition of Applied Cryptography by Bruce
> Schneier", page 70.
>
> Hash chain value H1(R) = 160 bit string
> A = 160 bit random string
> B = 160 bit random string
>
> Responder computes: H1(R) xor A xor B = C,
> where A, B and C are final key pieces.
>
> Initiator computes: C xor B xor A = H1(R),
> where H1(R) is the combined key.
>
> AC1:
>
> IP header: Addr-I1, Addr-R
> WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=001, Key_piece=A
>
> AC2:
>
> IP header: Addr-I2, Addr-R
> WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=010, Key_piece=B
>
> AC1:
>
> IP header: Addr-I3, Addr-R
> WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=100, Key_piece=C
>
> If the initiator receives all of the keys. ACR:
>
> IP header: Addr-R, Addr-I1
> WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=111, combined_key=H1(R), H2(I)
>
> If the initiator receives only AC2 and AC3. ACR:
>
> IP header: Addr-R, Addr-I2
> WIMP: IDs, AC_ID=1, Key_count=2, Key_mask=110,
> combined_key=(B xor C), H2(I)
>
perfect, thanks
IMHO you should include this example in the draft, it really makes things so
much clearer (at least for me)
> >3. After that a REA message is received, and some of the locators are
> >verified, which locator is used for following packets?
> >Do you use the address contained in the source address field of last
> >received packets?
> >
> >
> >
> The draft does not define an address selection policy. I think
> the WG should define a separate draft that defines the address selection
> policy
> for all different multi6 protocols. However, your prososal
> sounds good for
> default address selection.
>
> I hope my comments clarify the draft and give answers to your questions.
>
Yes, thanks.
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?
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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>