On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:
Also, for CGA verification, don't we need to send the other side a
challenge to avoid replays?
I don't know if this is necessary...
Ah, ok, so the updates are their own challenge.
What I was thinking about was that the correspondent claims to have
the secret key belonging to the public key, but you don't know that
unless you see some data signed with the secret key that is particular
to the session at hand.
context. In this case, we are in the Context confusion
situation,
and the host MUST NOT use the old context to send any packets.
It
MAY just discard the old context (after all, the peer has
discarded it), or it MAY attempt to re-establish the old
context
by sending a new I1 message and moving its state to I1-SENT.
In
any case, once that this situation is detected, the host MUST
NOT
keep two contexts with overlapping Ls(peer) locator sets and
the
same context tag in ESTABLISHED state, since this would result
in
demultiplexing problems on the peer.
What if an attacker is trying to interfere with legitimate
communication? We must be VERY sure that the new shim messages come
from the same host as the one that created the existing state if
we're going to mess with that existing state.
THe current security level is that we don't provide protection
against on path attackers. If an attacker learns the context tag,
then it can do some nasty stuff, including destroying the established
context. this is the level of security that we have defined for the
protocol. We can discuss whether this security level is approapriate,
but i would like to have a high level discussion on the issue.
I guess you're right. But as an added measure, I'd like to see that
the old context isn't torn down until the new one is set up
completely. This way, an attacker that somehow finds out a context tag
needs to have return routability and do the full 4-way handshake to
destroy a context, which is almost certainly not worth that much
trouble.