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

Re: Mobile IPv6 - IPsec interaction.

Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:

> => can you give more details about what you can find in the policy database
> in your IKE implementation (I can't get enough public documentation)?

The exact contents and format of the SPD is implementation dependent.
There are some minimal requirements required by 2401.  But basically,
you would have something that says:

	mobile-host 11.22.33.44 uses i-d fqdn.mobile.host with rsa-key XXX

> => this (identification+authentication) is known to be not enough for
> the proper authorization.

Why?  identification + authentication is sufficient to lookup the
Policy and provide authorization.  The client (mobile host) doesn't
prove that they are authorized, they prove that they have a particular
ID.  Then the server (home agent) looks up that ID in the database and
can be assured that the (requested) home address actually belongs to
that mobile host.

>    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. 
>    
> => the "then is bound to" is our point: how is it done?

Phase-II is _ALWAYS_ bound to phase-I, because the phase-II
negotiation is completed within the protection of a phase-I SA.  That
gives you the binding between phase-I and phase-II.  The two phases
are _NOT_ independent.  You cannot complete a phase-II without having
a completed (and valid) phase-I.

>    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. 
> 
> => we agree, the issue is an authorization (only!) issue.

Authorization is a function of the server, and is completed by the
following steps:

	1) Client identifies itself
	2) Client authenticates as identity
	3) Server verifies authentication and returns an error if it fails
	4) Client makes a request for a mobile-host binding <-- action
	5) Server looks up identity in policy database
		a) verifies that binding matches policy
		b) if not, return an error
		c) if binding matches policy db, perform the binding

Steps 1, 2, and 3 are already done by IPSec.  Steps 4 and 5 are
somewhat IPSec and somewhat MobileIP.

> Thanks

You're welcome

> Francis.Dupont@enst-bretagne.fr

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available
Follow-Ups: References: