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

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 21 Dec 2000 12:48:43 -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. The text in RFC 2409 is (near) clear about this:
>
>    The identities of the SAs negotiated in Quick Mode are implicitly
>    assumed to be the IP addresses of the ISAKMP peers, without any
>    implied constraints on the protocol or port numbers allowed, unless
>    client identifiers are specified in Quick Mode.  If ISAKMP is acting
>    as a client negotiator on behalf of another party, the identities of
>    the parties MUST be passed as IDci and then IDcr.  Local policy will
>    dictate whether the proposals are acceptable for the identities
>    specified.  If the client identities are not acceptable to the Quick
>    Mode responder (due to policy or other reasons), a Notify payload
>    with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.
>
> Then if the IDci or IDcr are not the address identities of the peers
> then local policy must authorize or not authorize them.)
> I can't see a real difference between mobility (different address) and
> VPNs (subnet), both need authorization. BTW I'd like to know how
> this is implemented in current IKEs (ask IPsec people?)
>
At least the trust model is different here. If you trust SG's identity
in Phase I, you trust its Phase II identity also. I have
heard that some people just use wildcards and accept any phase
II identity. In the mobile IP case, it is very different.

-mohan

>    >    2) Phase II SA should use client identifiers to specify the HOME
>    address.
>    >       This would establish a Phase II IPsec SA to use HOME address as the
>    >       source selector.
>    >
>
>    If you do this, you need a way of binding the home address to the identity
>    used in IKE MM.
>
> => I believe we need a bit more than a binding: an authorization.
> The good thing here is that we have a higher level identity and the
> static well-known address (ie. it will be far harder to "bind" the
> identity with a random care-of address).
>
>    >But the question is how does one prevent the MN from using somebody
>    >else's home address during the phase II SA ? I agree that this
>    >is a difficult problem but it would be good to mention this somewhere.
>
>    I think you need to think this through now. It's not as simple as you
>    might think. There are a number of security vulnerabilities that have
>    resulted in the need to sanity check the source IP address, not just use
>    the SPI and destination IP address.
>
> => I agree, IPsec specifies the protected traffic MUST be between the
> negociated (in phase two) entities and mandates a check for the source
> address (which one and when to do the check is unfortunately implementation
> dependent, most implementations are compliant, many are not interoperable).
>
>    To my mind, the proposal isn't really complete -- IPSEC doesn't provide
>    the necessary bindings by itself, and you haven't specified how
>    they are accomplished.
>
> => I agree. IPsec provides only the strong authentication, not the
> authorization itself. What are the IETF WGs in charge of the authorization?
> AAA can do it but AAA is for users, not nodes, and we wouldn't like
> to restrict mobility to mono-user nodes only, even this case is very common.
>
>    For example, think about the following issues:
>
>    a) How is the FQDN/User_FQDN securely bound to the home address? Merely
>    convincing someone that I'm fred.bigco.com doesn't tell them anything about
>    what home address I'm allowed to use. Are we going to require DNSSEC to
>    provide the binding? And is it possible to bind [email-masked] to a
>    home address? Here DNSSEC won't even necessarily help you.
>
> => DNSSEC and AAA are two obvious answers but none is a complete answer,
> ie. they can work in some (important) cases but not in all cases.
> They are not deployed/usable today too... (but you can answer mobility
> will be a good reason to deploy them quicky :-).
>
>    b) If you can't accomplish this binding, what use is using the home
>    address as the identifier in QM? Any user able to authentication in MM
>    can then send in a bogus binding update for another authenticated user.
>
> => we already agree about the need to add authorization.
>
>    c) How do the IPSEC correspondents sanity check the source IP addresses?
>
> => the mobile node source address is the care-of address and is nearly
> random. The only available sanity checks are trivial (for instance the
> mobile node should not use one of my addresses, should use an address
> with the proper scope, ...).
>
>    To be able to do this it seems that you'd need to be able to validate
>    the binding between FQDN/USER_FQDN and home address. By the way, if you
>    can do this, I don't see the difference between AH and ESP in terms of
>    security.
>
> => you need to protect both the care-of and the home addresses. If you do
> that with an ESP it is more expensive (you have to repeat the care-of in
> an alternate care-of suboption) and the source address check will fail
> if you have not hacked your implementation in order to support this
> particular case.
> There is a common situation where you'd like to use an ESP: you already
> have an ESP tunnel between the mobile node and the correspondent.
> I am writing a draft with Richard Draves about this important case.
>
>    If you can't, then neither is really secure. Can someone provide
>    a counter example of an attack that could succeed against one and not the
>    other?
>
> => the choice between AH and ESP was not done according to security
> requirements (both can provide authentication, integrity check and
> anti-replay for the critical elements) but because AH is simpler
> (just because it was designed for this kind of applications :-)
> and has no known issue with compliant IPsec implementations.
>
>    d) How is "authorization" performed?
>
>    I think that this is a code name for FQDN/User_FQDN - home agent binding,
>    but I'm not sure.
>
> => this is a bit more, in (poor) English this is something like
> "a node with this (proved) identity can use mobility with this home address".
> Of course the authorization between the mobile node and its home agent
> is critical (and easier to do, a (unscalable) static configuration works,
> DNSSEC or AAA or ... are simpler to setup too in this case).
>
> Thanks
>
> [email-masked]
>
> PS: if nobody explains how to provide authorization before the end of the year
> I'll put a message about the issu in the IPsec mailing list. VPN is an
> enough important market to get a detailed answer, isn't it?
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Dec 2000 12:27:08 +0100

At least the trust model is different here. If you trust SG's identity
   in Phase I, you trust its Phase II identity also.

=> this can be true only if all peers provide the same security service
(same level, same domain). In other cases (different levels and/or
different domains) a peer can get some priviledges dedicated to another
peer (ie. there is a big hole in security).

   I have heard that some people just use wildcards and accept any phase
   II identity.

=> I believe they don't accept any peer, ie. they give the same security
to a well known (and small) set of peers, and reject other peers.

   In the mobile IP case, it is very different.

=> you can configure the same kind of policy, ie. accept a small set
of mobile nodes without protection between them (ie. one can impersonate
another one). This can be acceptable on the home agent (this is what I
use in tests) but this doesn't scale for correspondents (ie. routing
optimizations will be lost).

I believe VPN people have (better) solutions...

Regards

PS: please move to IPsec mailing list.

---

From: Gao Lan <[email-masked]>
Date: Sun, 24 Dec 2000 22:37:04 +0800

unsubscribe