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

Re: 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.
 > 
Agreed. I did not mean to use the care of address as the identity. 
I meant that one can't use the home address in phase I. If it
could have used the home address, then there is no problem

 > 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.
 > 
You mean to say that during phase II, you link the phase I identity
and the IP address used in the ID payload of phase II and match it
with that is in the certificate.

 > 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.
 > 
So, for every cell phone assume i have such a certificate issued.
Assume i am using this to connect to some web site. As i keep
moving, i keep sending binding updates to the server that
i am connected to. Is it practical to assume that any
arbitrary server that i connect to, will be able to get to
these certificates and do these policy checks ?  How
does the server get to this policy information ?

thanks
-mohan

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