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

[Jari Arkko <[e-mail]>]

Hi Francis,

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

Fair enough. I think that's a reasonable position (even
if we still disagree about the seriousness of the
disadvantages).

In any case, I think it would be useful if we could develop
some analysis model that would help quantify the effects in
some manner, better than arguing "its good that we prevent
attacks later than the lock-on time" or "its bad that attackers
can grab an address for a long time".

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

That's one possibility. Clearly if you had some pre-arranged
security association you could set the lifetime infinitely long.
I think we agree that in other cases the lifetime should not
be infinitely long.

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

But I'm sure you see the difference here. With RR, the vulnerability
exists ~ the time that the attacker is on path. With OMIPv6, the
vulnerability exists ~ this amount of time + the lifetime of the DH
key. In the assumed scenario, the host is not MIPv6-aware at all,
so it would be unable to establish its own BCE and key. This is
the kind of thing I think the analysis model should somehow take
into account: effects to plain IPv6 nodes, effects to MIPv6 nodes
that did establish the BCE in time, effects to nodes that did not,
etc.

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

Ok.

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

Stable storage can help, yes.

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

Of course.

> => an AAA infrastructure covering the mobile and correspondent nodes
> is a very strong assumption.

Sure. I was just listing other possibilities.

> => someone proposed to add a *delayed* binding complete message to
> OMIPv6. Perhaps this will make you happy... BTW this adds no real
> security too.

I'd have to see the specific proposal. But I suspect that if
we are going to do improved RR mechanisms, we are going to
see a number of proposals, learn their mistakes and propose
better mechanisms in the next round. We've already seen this
in the case of draft-vogt which at the beginning had a problem
which is now being addressed.

I think that the long-term effect of a successful attack in
OMIPv6 is a showstopper. But perhaps there's some modification
of the approach that makes this problem go away?

>    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... (:-)

I'm personally happy as long as we don't introduce additional
amplification. But I agree that people will worry about things,
so that's why its really important to address concerns that come
up, e.g. fixed delay => credit-debit. Other than that, I'm not
sure what else we can do, except see if the proposals stand up
after exposing them to review and thinking for some time. If you
remember the initial RR designs, many of them were eventually
shown to be problematic in one way or the other.

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

Once to be exact...

>    the Kabm even IMHO you should not have to refresh it (by
>    a new D-H exchange signed by the previous Kabm).

Well, I agree that refresh is necessary if a very large number
of uses is needed.

--Jari



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