Subject: Re: [MOBILE-IP] authorization to issue a Binding Update for a Home Address

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Jan 2001 09:54:33 -0800

>this is again the authorization problem. I don't understand why
>this is so hard for mobile IPv6 when the problem exists for VPN too
>(a security gateway will give a subnet identity in phase two, this
>should be accepted only if the peer is authorized to be a security
>gateway for this subnet.

My understanding is that most implementations are not able to
validate the subnet identity if provided by a security gateway.

It's worth reflecting on what the IKE exchange provides in the VPN
case, and what it doesn't provide. In the case of shared secret
authentication in MM, typically group secrets are required precisely
because it is hard to tie the source IP address to a shared secret
(the user could be trying to connect from anywhere). Note: In IKE
MM, the shared secret is required prior to obtaining the identity;
this is not the case in aggressive mode.

If certificates are used, life is easier because then the
machine/user identity can be used and validated. In general, we
don't care whether a user is at an authorized IP address, only
that they are authorized for VPN access.

After the IKE negotiation completes, we are able to verify that
each packet came from the same source that negotiated the
key via IKE.

Similarly, it's worth thinking through *exactly* what assurances need
to be provided for MIP:

a) Do you want to know that the binding update is being provided by
the *same* entity with whom you were originally communicating?

Typically, this requires authentication of both the original
conversation and binding update, and tieing between the two.

b) Do you want to know that the source is actually reachable at the
care-of/home address that is indicated?

A three way handshake (e.g. a request-response-request sequence)
can provide this.

c) Do you want to know that the source is authorized to use the
care of address? home address?

This is the hardest level of assurance to provide. If you feel
that you need this, then it's important to make sure that
assurance is required within the conversation itself, not just
the binding update.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 2 Jan 2001 19:47:12 +0100

=> I agree but it is important to know if some are able to validate
identities and even more important how they do that... Today VPN
is a business so I believe the question will get an answer!

=> this is not enough with a layered VPN (ie. with a SG manageing
different VPNs with different security requirements).

=> we are able but we should *not* do this check: the correct check
is to verify the original source is in the subnet (ie. check the inner
source, not the outer source).

=> authorization to use the home address.

=> there is no original conversation in the common case.

=> this is not important.

=> the care-of address is nearly random... The important point is
the authorization to use the home address (this will give previous
points when they apply).

   This is the hardest level of assurance to provide.

=> it is easier than we can believe because the home address is the
phase 2 entity (ie. the SAs are built for the home address) so the
burden is not when the binding update is received: the assurance
is required in the phase two of IKE, ie. we just have to give the
concrete code for "Local policy will dictate whether the proposals
are acceptable for the identities specified".
 My idea is still to post a provicative question about this statement
in the VPN context in the IPsec mailing-list (:-)...

   If you feel

=> see previous point (this is another argument to set the SAs for
the home address). IKE knows mobility is involved because of the
phase two identity (a different address) and if it rejects the
identity (ie. deny the authorization) the binding update will not be
authenticated (and it MUST be authenticated, ie. it will be canceled
when IKE will notify the INVALID-ID-INFORMATION failure).

Thanks (and Happy New Year!)

[email-masked]