[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mobile IPv6 - IPsec interaction.



Mohan Parthasarathy writes:
> 1) In Main Mode, it uses the Care of Address as the source address (
>     it can't use the Home Address yet as the other end either has
>     a stale binding or no bindings and hence we can't get the reply
>     back) and uses an appropriate authentication mechanism
>     to establish the Phase I SA.

It cannot use care of address as its identity in phase I. The care of
address does not have any meaning to the home agent. It needs to use
something in the phase I that will identify the mobile node to the
home agent.

This could be username@host.name (user@fqdn),
fixed.domain.name.at.home (fqdn) or distinguished name. Using of those
also rules out using of main mode with pre-shared keys, thus the best
would be using certificates (signatures).

Another possibility would be aggressive mode (either with signatures
or with pre-shared keys).

> 2) In Quick Mode, we want the IPsec SA to be bound to the mobile node's
>     Home Address. This is acheived by using the Identification payload
>     with Home Address in it. (All selector checks will happen
>     against the home address)
> 
> In step (2), there is nothing that prevents a mobile node from using
> the home address of some other mobile node. How does the other
> end (the home agent or the correspondent node) verify that the
> mobile node is using the right home address ?

It verifies that the identity sent in the phase I matches its policy
database.

Example:

My laptop (kaakeli.ssh.fi) has a home address of 11.22.33.44. I also
have certificate that is bound to this machine having names DN =
"C=Fi, O=SSH Communications Security, CN=Tero Kivinen",
user@fqdn = "kivinen@ssh.fi", fqdn = "kaakeli.ssh.fi" and ip =
"11.22.33.44" in it.

When my laptop moves out from the local network and needs to send
binding update, it connects to the home agent at 11.22.1.1 from its
care of address 4.5.6.7.

In the phase I can use any of the names inside the certificate as my
identity and the home agent can then know that only my laptop is able
to create that IKE SA. Thus after phase I succeeds it knows that it is
my laptop at the other end of that IKE SA.

Using my home address (11.22.33.44) as an identity of the phase I is a
bad idea, because some implementations check that IKE src address
matches the phase I id. Thus it would be better using either user@fqdn
or fqdn instead.

In the phase II my laptop will create tunnel between 11.22.33.44 and
the home agent, and now the home agent knows that this IKE SA
connection is bound to my laptop which then is bound to home address
of 11.22.33.44, thus this operation can succeed. 

You have to remeber that authentication of the remote end happens in
the Phase I, and after that you know who is on the other end of that
IKE SA. 
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


Follow-Ups: References: