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

Re: New multi6 draft: WIMP

Hi Marcelo,

Thanks for reading through our draft.

marcelo bagnulo wrote:

Hi Jukka,

I am trying to understand your draft, and i have some questions about some
points that you perhaps can help me with.



You have pointed out several important issues that need clarification. I already
apologize my long email.

1. About the Context establishement exchange (section 3.4)
I fail to see what you mean when you state that the responder remains
stateless.
I mean, the responder has to generate the temrporary hash chain. This hash
chain has to be specific to this particular host pair context, right? (this
is what it is stated in section 3.3 about generating reverse hash chains)
So, this means that when the responder receives an INIT message it has to
generate a new hash chain (or reserve a pre computed hash chain for this
initiated context establishement), would this be correct?. If so, the
responder has to at least store a state that is that this hash chain is
reserved and cannot be used for a future INIT, right?



The responder has one long term secret that is common for different contexts. Basically,
the responder remains stateless, and does not store the temporary hash chain values.
It is still able to safely recompute the hash chain after receiving the CCR message.

Appendix A describes an example how the hash chain can be generated. The responder
generates its hash chain using a long term local secret, IDs and a challenge (i.e.
a nonce). The initiator's ID is a hash of a nonce. The secret, in turn, is never reavealed
to the peers. The responder protects the CC message with its newly generated
hash chain value. It does not create a state.

It is important to notice that the state machine plays an important role. If a responder already has a state for a specific ID pair, it does not reply with CC message. In other words, an attacker cannot pump out the hash chain values of other ID pairs.
The responder cannot generate similar hash chain for a new ID pair during the lifetime of the authentic ID pair. The attacker is not able to use the same ID as the authentic initiator is currently using.

In addition, it does not matter if the attacker creates a context with the responder,
using the authentic inititor's ID and challenge, after the authentic initiator has destroyed its context with the responder. Once the authentic initiator creates a new context-pair
with the responder, it generates a new random ID for itself, and therefore also the hash chain is changed.

Once the responder receives the CCR message, it is able to recompute the hash chain
using the long term secret, IDs and the challenge. The HMACs bind the earlier
exchange messages (INIT and CC) together and quarantee that the hash chain is
bound to the requested ID pair.

[Do not hesitate to ask more questions about this, if I my answer was not clear enough.]

If so, wouldn't this imply that an attacker sending INIT messages could
force the responder to gnerate hash chains, sort of DoS attack? I ask this
because, if i understand correctly, this is what you are trying to prevent,
but i just fail to see how you actually prevent it :-(



A short hash chain generation is a quite fast operation compared to signature
calculation. (If I remember correct, e.g., computing SHA1 five times over a
160bit string takes under 0.5 ms with 2Ghz pentium.) The operation is efficient
and makes it more diffucult for an attacker to cause a DoS situation.

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

I don't really agree with this... I think that the initiator can prove that
he is reachable by inlcuding the HMAC_CC value in the CCR message, and not
by disclosing the anchor value.

I mean, the anchor value would prove that the initiator is the same that the
one who sent the INIT message, but if the RESPONDER is stateless, the
responder has no information about the INIT message received, .
I guess that the important is to inlude the HMAC_CC and since the responder
has the H0_R it can verify that the HMAC__CC was generated by himself (the
responder)

(i am probably missing something here....)



Excellent analysis! Thanks! However, as I pointed out above, the responder
is able to recompute its hash chain without creating a state.

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. In other words, the HMAC_INIT
in INIT message, and the anchor_I value in the CCR message bind the messages
together and implement a kind of return-routability test.

after you mention that:

"The anchor value of the initiator hash chain
  binds the INIT and CCR messages together, and in this way the
  responder is able to verify that messages are coming from the same
  host. "

again if the responder is stateless, he has no knowledge about the INIT
message by the time he receives the CCR message, so what does it means that
it can verify that both messages come from the same host?


See above.

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)

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.

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