Time shifitng/future redirection attacks (was RE: Identifiers

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> Correct. That is how the Internet works. Multi6 doesn't have to fix that.
> We have to make sure that *if* the host we contact using IPA subsequently
> asserts that it can also be contacted using IPZ, that assertion is true.

If i understand what you are saying correctly, this approach wouldn't really
prevent the attacks presented in section 4.1.2 Premiditated redirection of
draft-nordmark-multi6-threats-00.txt, right?

Or in more general terms, this would allow time shifting attacks as
presented in section 2.2. Timing in draft-nikander-mobileip-v6-ro-sec-02.
Note that MIP design especially limited BCE entries lifetime to a few
minutes to deal with this type of attacks.


>
> The analogy with TLS is very strong - whoever we started talking to,
> we continue to talk to. If we start talking to a bogus host, we continue
> talking to the same bogus host when multihoming occurs.

Yes, but now, the attacker must be on the path to achieve the attack while
multihoming may allow the attacker to move from the path and continue to
perform the attack
So, allowing this type of attack adds vulnerabilities to the current
internet, AFAICS

Clearly, if the addition of these vulnerabilities is acceptable, the
solutions would be much simpler, indeed.
I just want to make sure that we agree that we are adding vulnerabilities
here, so we can make a choice then.

But i am not a security expert and i may be missing something, it would be
nice to have an experts opinion to clarify

Regards, marcelo


>
>    Brian
> > but Host B knows that Host A can receive
> > packets addressed to IPA. That is they way it works for fixed
> hosts and that
> > is the level of security we should preserve i guess.
> >
> > Now the problem how do we translate this requirement to a multihomed
> > environment.
> >
> > Suppose the same scenario where HostA initiates a communication
> with HostB
> > using IPA and IPB respectively. They exchange some packets, so
> Host B knows
> > that Host A is reachable at IPA.
> >
> > Moreover, HostB is using as a ULP identifier IPA.
> >
> > Now, using some kind of multihoming mechanism, Host A tells
> HostB that he is
> > also reachable at IPC. Moreover, Host A can strongly prove that
> he is the
> > same that initiated the communication using IPA (i.e. that the
> same entity
> > who was at IPA is also at IPC)
> >
> > Finally, HostA start using IPC as source address in its
> packets, so HostB
> > starts preferring IPC over IPA to use as destination address to
> reach HostA
> > (instead of changing the IP address an alternative signaling
> mechanisms can
> > be used to switch addresses)
> >
> > So my question now is: do you think that HostB, once that is
> sending packets
> > only to IPC and knowing that it is same entity that initiated the
> > communication using IPA, should still believe that he is
> communicating with
> > IPA?
> >
> > Regards, marcelo
> >
> >  And this is why I liked NOID.  You want
> > > strong security?  The claim is that it will work with DNSSEC for
> > > verification.
> > >
> > > Beyond that, if you have an existing line of communication between you
> > > and a host, wouldn't PBKs provide a secure means by which one could
> > > privately pass additional information?  If it does, it provides some
> > > really nice generality for the above.  For instance, if you use some
> > > very secure mechanism to establish connectivity then PBKs
> could provide
> > > continued assurance.  And if you were out in the open, PBKs
> provide less
> > > assurance (e.g., you still end up with potential MITM attacks).
> > >
> > > Regards,
> > >
> > > Eliot
> > >
> > >
> > >
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
>