Hi Manhee,
during the initial home and care-of address tests, described
first in
section 5.3, the MN receives from the CN home and care-of
keygen tokens.
These tokens are guaranteed to originate with the CN, or
with a node
that sits on the path between the MN and the
"real" CN, because the
cookies included in the exchanged messages allow the MN to
match a
response from the CN with one of its own requests.
[There is a vulnerability to on-path attackers that
impersonate the CN.
This could be mitigated if the CN used its own CGA, but the
document
currently does not specify this.]
The Authenticator within the BAD option of the Binding
Update message
and the Binding Acknowledgment message is, in turn,
calculated based on
the exchanged tokens. So the MN knows that the Binding
Acknowledgment
message originates with the CN (or with a node that sits on
the path
between the MN and the "real" CN).
Hope this helps,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet
Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
Manhee Jo wrote:
> Dear all,
>
> I have a question regarding the MN's verification of
SKey received from
> the CN.
> In Step 4 of Initial Binding Update, how can the MN
verify that the SKey
> in BA is sent from the real CN not from an attacker?
>
> If the Kbmperm is made by means of a method that only
the CN knows,
> an attacker could also generate a random number to
claim to be a Kbmperm.
> The attacker-made Kbmperm could also be encrypted with
the MN's public key
> as is the case of the CN-made Kbmperm.
> If the attacker-made Kbmperm arrives at the MN before
the Kbmperm from
> the CN arrives,
> the MN will have the attacker-made Kbmperm which is not
what the actual
> CN has.
> Then, I think, it would not be able to send Binding
Update to the CN
> afterwards.
> Am I missing something?
>
>
> Regards,
> Manhee
_______________________________________________
Mipshop mailing list
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|