[Mip6] comments on draft-haddad-mipv6-omipv6-01.txt

[Jari Arkko <[e-mail]>]

Hi Wassim and others,

I have reviewed this document. I think its excellent that you are
working on optimizations. I think we need them, and there appears to
be at least some level of consensus on that in the group as well. I
also like your approach in the sense that it does not expect to use
any security infrastructure, I think that is the right thing to do.
And I think that you have also managed to avoid potential CPU DoS
issues that are inherent in Diffie-Hellman- based schemes, which is
good.

But you mention that your intent is to provide a more secure signaling
scheme than RR is. However (and perhaps I'm missing something
obvious), it seems that the proposed use of Diffie-Hellman has
security impacts which actually make it less secure than standard
RR. My concerns are listed below; after that there are some suggested
modifications which can make your protocol more secure.

"Kilroy was here first" -attack

   If I have understood correctly, in OMIPv6, any change to the binding
   cache must be authenticated via the derived shared secret. It is
   even not possible to rerun RR and OMIPv6 without proving the
   possession of the shared secret.

   As a result, once a shared secret is established, it is hard for
   other parties to change the binding. This is normally a positive
   thing, however, it becomes negative if it happens that the initial
   DH exchange was compromised and is now in control of the binding.
   It can perhaps be argued that this attack is hard, because the
   attacker would have to be both on the mobile node - correspondent
   node and home agent - correspondent node paths.

   However, there is another attack, much more serious that can be
   executed easily [draft-aura]. More specifically, an attacker can
   initiate an RR and DH exchange all by himself, without compromising
   any ongoing legitimate exchange. If the attacker does this before
   the mobile node in question has established the binding, the mobile
   node can no longer communicate with the correspondent node at
   all. Moreover, all the communications from the correspondent node
   intended to the mobile node go to a location selected by the
   attacker.

   In order to execute this attack, one needs to defeat the RR
   protocol. But this only requires presence on the path from the home
   agent to the correspondent node. It is not an issue in RR, since
   nodes that are on that path can perform equally bad attacks anyway
   and RR limits the vulnerability by requiring that the attack is all
   the time on this path. With OMIPv6, the attacker would no longer
   need to be on the path permanently, only once.

   This attack is particularly dangerous for non-mobile nodes.
   One would normally not assume that hosts without Mobile IPv6
   support are vulnerable to problems in Mobile IPv6. However,
   when the correspondent node supports OMIPv6, an attacker who
   is at least temporarily on the path between the victim and the
   correspondent node can now cause the victim's traffic to
   be permanently redirected (the attacker may have to refresh
   the binding now and then, but he no longer has to be on
   the path). For instance, an attacker who temporarily visits
   an office Wireless LAN could set up an OMIPv6-protected binding
   at www.cnn.com for the office proxy server. As a result, all
   communications between the proxy server and the www server
   would fail.

   This vulnerability is serious, because a temporary problem expands
   into a more permanent problem, and can affect any IPv6 node even
   without Mobile IPv6 support.

"Recovery mechanism" -attack

   Nodes can reboot and forget their state, or get an address that
   someone else was using a while ago. As discussed in [draft-aura], it
   is necessary to have a recovery mechanism. In essence, such recovery
   mechanism should be able to undo an OMIPv6-protected binding.  For
   instance, a persistent ICMP error could lead to the correspondent
   node into believing that the binding is invalid.

   Unfortunately, such recovery mechanisms can be exploited by attackers,
   making it possible to undo a legitimately created OMIPv6-protected
   binding, and create a new one in place (for instance in the method
   discussed in the previous section).

   OMIPv6 is currently missing a recovery mechanism, however.  Perhaps
   it can be designed in a way that there is no attack.

Summary

While the first attack described above is similar to the one that
exists in RR, its results are worse than in OMIPv6. Findings in
[draft-aura] make it hard to see an easy way to fix this; basically a
"leap-of-faith" or PBK like approach does not sound suitable for the
RO problem, even if they can be successfully used in, e.g.,
application layer protocols. The basic problem is that there is no
user confirmation about making the leap of faith, leading to the
possibility of the attacker doing the operation before you.

Then again, I could be missing something. Let me know what.

Possible suggestions on how to improve the security of your
approach:

- In [draft-roe] we proposed a scheme that incorporated Diffie-Hellman
   which did not rely _just_ on the RR as its initial authentication.
   Instead, it used a combination of RR and CGA tests. I don't remember
   if we actually eliminated all but the first home test messages; it
   seems that at least some optimization is possible there even if we
   didn't do in the draft.

   I think we are going to need something like this, maybe not exactly
   the same proposal, but something better than RR if the Kbm is to be
   made more permanent.

- While avoiding security infrastructure and configuration is indeed
   very much desired, I would note that a DH authenticated by a
   pre-configured shared key between the home agent (or mobile node)
   and correspondent node would NOT be vulnerable to issues that I
   described above.

   Similarly, AAA could be used to authenticate the D-H somehow. I
   think this is what [draft-le] did.

- If RR as initial authentication for D-H is deemed sufficient, there
   would be simpler protocols that would accomplish what you want to
   do. As you know, unauthenticated Diffie-Hellman is vulnerable to
   MiTM attacks by active attackers. It seems that this holds true of
   RR itself as well; nothing is gained by attackers who just
   eavesdrop; they have to at least send the Binding Update. So,
   if RR as initial authentication was deemed sufficient, it would
   seem that simply using RR-derived Kbm as the long-term key would
   be sufficient, and no D-H would be needed.

- I won't comment here about skipping care-of address tests as there
   are other threads in this mailing list about that.  But I think
   something along the lines of draft-vogt sounds promising to reduce
   the signaling delays related to care-of address tests.

Some other notes:

 > and a correspondent node (CN). Such mode is efficient, but it
 > raises many security concerns and generates an excessive amount
 > of redundant mobility signaling messages.

As I have said before on the list in other contexts, IMHO it would be
good if people who feel there are significant issues would document
these issues and make it possible for the rest of us to review the
findings. Existing analysis in e.g. draft-nikander and in the old
design team notes points to very similar risks that exist for
on-path attackers anyway.

 > Note that the main objective behind duplicating the second DH
 > message is the potential ability to reveal a possible MiTM
 > attack on the first one (i.e., if the malicious node knows the
 > Kbm). By duplicating the second DH message, a successful MiTM
 > attack will consist on attacking two duplicated messages sent
 > on two different paths at the same time, which will probably
 > make such kind of attack more difficult.

This is correct, but only if you look at attackers who intend
to eavesdrop on your signaling. This is just one class of an
attack, and I would argue that the more interesting class is
where attackers actually spoof the RR or OMIPv6 messages. For
that, as discussed in draft-aura, the two paths do not really
help. The attacker has to be on the home - cn path, but he
can choose the other path freely.

 > long shared secret

Hmm... I think the length is not the issue here. Generally in
cryptography we feel relatively safe after a certain key length.
In base MIPv6, this is 20 octets for the Kbm. I don't think we
need more.

What may be more relevant, however, is *how* you get those
key octets and how much security that procedure offers. For
instance, a CGA-type procedure would enable us to have more
assurance that the mobile node is who he says he is than
the home test procedure.

 > In order to reduce the handover latency, the MN will send the
 > BU on the direct path immediately after receiving a BA message
 > from its HA. Note that the MN MAY duplicate the BU message and
 > send a copy on the path going via its HA. Only one copy is
 > enough to update the CN's binding cache entry. In this case,
 > the BU sent via the HA MUST have the same sequence number than
 > the one sent via the direct path.

I didn't quite get this. If the sequence numbers are the same,
won't the other BU be dropped. Why would then want to send two?
Can you explain?

References

[draft-aura] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt
[draft-roe] http://www.arkko.com/publications/draft-roe-mobileip-updateauth-02.txt
[draft-vogt] http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt
[draft-le] draft-le-mobileip-dh-01.txt, expired



_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6