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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   But you mention that your intent is to provide a more secure signaling
   scheme than RR is.

=> in fact OMIPv6 is not more or less secure than the initial mechanism,
RR today or any replacement in the future. OMIPv6 plays with the PBK
trade-off, i.e., narrower window of vulnerability and longer impact
of successful attack. But OMIPv6 is really optimized, i.e., it gives
better performance (a RTT per renew or movement).

   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.

=> I disagree: the security level is the same (i.e., it is poor but
this another issue :-).

   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.
   
=> this is required because if an RR can be rerun at any time
an attacker who missed the vulnerability window has just to restart
the whole stuff from the beginning. (more about recovery after)

      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,

=> this is and RR should have this: without this you can't even speak
about a vulnerability *window*...

      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.
   
=> this is the trade-off and as a trade-off it has advantages and
disadvantages.

      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.
   
=> this is the counter part to be immune to the fake RR attack at
any time, i.e., with current RR when an attacker wants to mess
communications between a mobile node and a correspondent it can
initiate a new RR and redirect the traffic to the hell. The only
defense for the mobile node, in the case it understands what's happen,
is to enter in a race with the attacker.

      In order to execute this attack, one needs to defeat the RR
      protocol.

=> if your hidden argument is that OMIPv6 is more interesting with
a stronger mechanism than RR I agree...

      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 is *again* the trade-off... And if you'd like to use
shorter lifetime for OMIPv6 you'll get more vulnerability
windows. Perhaps you'd like to adapt the OMIPv6 lifetime
to the strength of the initial mechanism?

      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.

=> so one should bann RR which has this unfortunate property.

      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

=> s/permanently/for a longer time/

      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.
   
=> the attack is harder but has when it successful a longer impact...

      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.
   
=> I agree for the first statement (with something weaker than permanent)
but not for the second which already stands for RR.

   "Recovery mechanism" -attack
   
      Nodes can reboot and forget their state,

=> IMHO the best is to use stable storage because I don't want to
require longer reboot delays (:-). Note that there are some protocols
to solve this problem, even with very weak assumptions as in RR.

      or get an address that someone else was using a while ago.

=> mobile nodes are supposed to delete previous bindings so
there is another condition for this case which is already
so unlikely that IMHO it should happen only during attacks.

      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.
   
=> the example is just to give a very poor mechanism, isn't it? (:-)

      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).
   
=> so any weak recovery mechanism should be associated with an hold-down,
i.e., the correspondent must forbid the creation of a new binding
via a restart of the whole stuff during a reasonable delay.
There is no hold-down in Mobile IPv6, perhaps we should add this
in order to mitigate some attacks?

      OMIPv6 is currently missing a recovery mechanism, however.  Perhaps
      it can be designed in a way that there is no attack.
   
=> I propose stable storage when it is possible for the mobile node
side and hold-down  against restarts when a binding is detected as
being broken for the correspondent node side.

   Summary
   
   While the first attack described above is similar to the one that
   exists in RR, its results are worse than in OMIPv6.

=> worse results/harder attacks

   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.

=> please note that PBKs were introduced in the RO context so
this is your personal opinion only.

   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.
   
=> and the basic advantage is the attacker has to be 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.

=> OMIPv6 doesn't rely just on RR, it just uses what is available
which is RR today.

      Instead, it used a combination of RR and CGA tests. I don't remember

=> please either give a free license for CGAs to everybody or
avoid to use them.

      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.
   
=> this is well known that stronger mechanisms than RR exist but:
 - some of them already provide long term protection
 - none is standardized for RO.

      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.
   
=> see before. And with the stronger proposed mechanism, IPsec, the
lifetime can be unbound (still less than 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.
   
=> with a pre-configured shared secret between the mobile node and
the correspondent node there is no reason not to jump to IPsec.
About the home agent I'd like to see a reason to trust it more
than somebody else...

      Similarly, AAA could be used to authenticate the D-H somehow. I
      think this is what [draft-le] did.
   
=> an AAA infrastructure covering the mobile and correspondent nodes
is a very strong assumption. And in this case you can again jump
to IPsec...

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

=> this is why OMIPv6 is using another mechanism to provide authentication.
Today it is RR so OMIPv6 is as good/poor as RR.

      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.

=> yes, RR is not so poor! (:-)

      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.
   
=> (assuming you are not joking) D-H has stronger security properties,
for instance the shared secret can't be computed from messages so
you have PFS and even more...

   - 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.
   
=> someone proposed to add a *delayed* binding complete message to
OMIPv6. Perhaps this will make you happy... BTW this adds no real
security too.

   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.
   
=> direct reflection attacks are easier than (mis)using mobile IPv6 RO
and there are still some people which are afraid when you'd like to
remove/delayed/etc the care-of test... (:-)

    > 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.
   
=> there are two reasons to be long:
 - long enough to be immune to the brute force attack
 - each time you use a secret you reveal something about it, i.e.,
   you consume its entropy. The 20 octets of the Kbm are used
   in a very small number of times, this is not the case for
   the Kabm even IMHO you should not have to refresh it (by
   a new D-H exchange signed by the previous Kabm).

   What may be more relevant, however, is *how* you get those
   key octets

=> I don't believe there can be an issue about this.

   and how much security that procedure offers.

=> this is the point. As I explain at the beginning IMHO the
security of the initial mechanism (RR currently) and OMIPv6
are exactly the same from the authentication point of view.

    > 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?
   
=> two paths are available, the same BU is sent over both paths,
one should win the race and update the binding, the other one should
arrive after and will be dropped as it is recognized as a dupplicate.
There are two advantages:
 - resulting delay is the min of both path delays
 - there is a lower chance that both BUs are lost (maths show
   that the lost probability for both is between the min and
   the product of individual lost probabilities).
My rationale is one should use all the possible paths when they are
in a reasonable number and likely to be reasonably independent.

   References
   
=> A URL to an "all I-D" repository (like watersprings) and the "expired"
mention are enough.

   [draft-le] draft-le-mobileip-dh-01.txt, expired
   
=> I can send it to you (I keep Frank's draft because he was a
student of my school :-).

Regards

[e-mail]

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