Subject: RE: [mobile-ip] Mipv6 issue #192: Authz in SPD or in MIPv6?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 3 Jan 2003 10:44:57 -0800

Jari,

A couple of questions.

> This is an attempt to see what it would mean to do all authorization
> tasks in Mobile IPv6 code, as suggested by Michael Thomas. I like this
> approach for several reasons but we haven't had a detailed description
> of how it would work. For this reason I set out to make an example
> configuration for this new style. I have modified the SPD and SAD
> entries from sections 7.2 and 7.3 of the MN-HA IPsec draft to the new
> style below.
> 
> There are NOTEs within the text to explain differences to the current
> style.
> 
> Overall, the main findings are as follows:
> 
>    o  When manual keying is used, we can reduce the number of SAs
>       from Nx6 to Nx4 (or even Nx2 if we are willing accept some
>       additional headers). The number of SAD entries is reduced
>       similarly. The number of SPD entries is constant and does
>       not depend on the number of home addresses. These are
>       positive findings.
> 
>    o  When IKE is being used, the new style simplifies the
>       configuration considerably. This too is positive.
> 
>    o  However, at the same time we are forced into the 
> following changes:
> 
>       - All MH traffic to and from the HA must be protected 
> with IPsec,
>         making it hard, for instance, for my home server to 
> be simultaenously
>         both a home agent and a public web server. (See 7.3.1 below.)
> 
>         Question: Could we base our SPD rules on home network 
> prefixes?
> 
>       - If we want to avoid mobile node -specific policy 
> entries (which was
>         one of the goals), we have to create tunnel mode SAs 
> bound to the
>         care-of addresses. This implies a new IKE run is 
> needed on every
>         movement. (See 7.3.2 below.)
> 
>         Question: Does it help if we keep the modify-the-tunnel-gw
>         API as well?
> 
All these looks okay to me.

>       - Address spoofing of HOTIs can't be checked (but this isn't
>         considered very dangerous given that HOTs are routed 
> correctly).
> 
Could you elaborate this a bit more ? I am not sure which address spoofing
you are talking about here.

> My conclusion from the above is that while there are extremely big
> advantages, there still seems to be also some significant open
> questions. Perhaps Mike or others have suggestions on how to overcome
> these issues and to answer the questions? Otherwise, I think we should
> go with the current (tested) approach and do some more long-term work
> as an add-on.
> 
> OVERVIEW OF OPERATIONS
> ======================
> 
> In this new style, we leave IPsec to do the authentication work, and
> deal with the authorization issues as much as we can in Mobile IPv6
> module. That is, IPsec ensures that for the "significant traffic",
> only packets coming from authenticated peers get through. In this
> context, "authentication" means, for instance, any node belonging to
> the corporate intranet.
> 
> Security issues in Mobile IPv6 go beyond authentication, however. We
> need to ensure that mobile node A does not send a Binding Update for
> mobile node B, for instance, even if both are authenticated.  The
> purpose of the authorization step is to make sure this does not
> happen. The authorization step is performed in the Mobile IPv6 module
> in this new style.
> 
> The overall approach at the IPsec layer is to require authentication
> but leave as much of address and protocol information freely expressed
> as possible. Then we require an API to exist between the IPsec layer
> and the Mobile IPv6 module to communicate the "identity" used in the
> successful authentication to Mobile IPv6. Mobile IPv6 will then
> compare this identity and the claimed home address to the information
> it has in configuration table about authorizated nodes and their
> addresses. Alternatively, such configuration table may also be
> accessed through an AAA lookup.
> 
> The details of the required API are not relevant at this stage.  What
> is needed is a way to associate a given packet to some "credentials",
> either Phase 1 identities from IKE or some manual SA identifier. This
> can happen per-packet or through some form of properties assigned to a
> socket or security associations.
> 
> Note that we may not always be successful in avoiding addresses and
> protocol information in the IPsec policy entries and SAs. It is still
> necessary for us to specify when IPsec is to be applied and when not.
> This may have to be done in part using addresses from the packets.
> 
> Note also that the authorization checks can only be performed when
> some message actually comes to the Mobile IPv6 module. This is the
> case for MH packets terminated to the home agent, for instance. But it
> is not the case for traffic tunneled through the home agent.
> 
The last point is a bit confusing. This should not require any changes
to the IPsec implemenation itself. It happens as a result of the SPD
configuration. Is that correct ?

<snip>
> 
> 7.3.  Dynamic Keying
> 
> 7.3.1.  Binding Updates and Acknowledgements
> 
> NOTE: Mobile node SPD ignores home address, and now applies 
> even to care-of
>        addresses. This is fine from the point of view of the 
> mobile node.
> 
>        IKE is run on care-of addresses, but the created SAs 
> are allowed to
>        use *any* home address. This avoids the need to rerun 
> IKE on every
>        movement. In any case the Mobile IPv6 code will check the used
>        credentials vs. the specified home address.
> 
>         mobile node SPD OUT:
>           - IF source = any & destination = home_agent_1 & proto = MH
>             THEN CREATE ESP TRANSPORT SA: local phase 1 
> identity = user_1
> 
>         mobile node SPD IN:
>           - IF source = home_agent_1 & destination = any & proto = MH
>             THEN CREATE ESP TRANSPORT SA: local phase 1 
> identity = user_1
> 
> NOTE: Home agent SPD ignores home address i.e. the peer's address
>        completely. The general rule becomes then SO general that it
>        precludes cleartext MH. For instance, the same node 
> can't act as
>        a home agent for you and as a web-server with route 
> optimization
>        for someone else.
> 
>         home agent SPD OUT:
>           - IF source = home_agent_1 & destination = any & proto = MH
>             THEN CREATE ESP TRANSPORT SA
> 
>         home agent SPD IN:
>           - IF source = any & destination = home_agent_1 & proto = MH
>             THEN CREATE ESP TRANSPORT SA
> 
> NOTE: We create an additional configuration table for the home agent
>        to list the relationship of IKE Phase 1 identities to home
>        addresses. Mobile IPv6 module will check this using an API for
>        all MH packets.
> 
>         home agent MIP ID TABLE:
>           - user_1 has home_address_1
> 
Is the same check done during Phase II exchange also ? I saw this mentioned in
the draft. If so, it implies that a change is required in IKE. Or the check is
done only much later when MH packets are received by MIPv6 module.

-mohan

> 
> 7.3.2.  Return Routability Signaling
> 
> NOTE: Mobile node SPD roughly same as before, but home address not
>        tested, and neither is the specific tunnel. Applies even for
>        multiple home addresses.
> 
>         mobile node SPD OUT:
>           - IF interface = any tunnel to home_agent_1 &
>                source = any & destination = any & proto = MH
>             THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
>                                        local phase 1 identity = user_1
> 
>         mobile node SPD IN:
>           - IF interface = any tunnel from home_agent_1 &
>                source = any & destination = any & proto = MH
>             THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
>                                        local phase 1 identity = user_1
> 
> NOTE: The home agent policy entries have been radically simplified.
>        Remember that earlier entries already forced us to 
> require IPsec
>        for every MH message, making the use of the home agent as a
>        general correspondent node hard. We use this fact to write the
>        entries in a very simple way, all MH packets from anywhere to
>        anywhere must be tunneled with IPsec (the BU entries from 7.3.1
>        take precendence however).
> 
> NOTE: Since we run IKE on top of care-of addresses and don't want to
>        have mobile node specific policy entries, the tunnels will be
>        established to care-of address, requiring them to be redone on
>        every movement.
> 
> NOTE: The home agent will not be performing any home address spoofing
>        checks for the HOTI messages. This is seen as unnecessary,
>        however, given that HOTs will always be routed to the right
>        mobile node.
> 
>         home agent SPD OUT:
>           - IF source = any & destination = any & proto = MH
>             THEN CREATE ESP TUNNEL SA: gateway = care-of address
> 	   (there is no IKE attribute to set the gateway
> 	   differently from IKE transport addresses)
> 
>         home agent SPD IN:
>           - IF source = any & destination = any & proto = MH
>             THEN CREATE ESP TUNNEL SA: gateway = care-of address
> 
> 7.3.3.  Prefix Discovery
> 
> NOTE: The mobile node SPD entries now ignore the home address. Note
>        that since the rules still keep the home agent's global unicast
>        address, these rules will not match ND traffic which uses
>        link-local addresses.  This is good as chicken-and-egg problems
>        in securing ND with IKE can be avoided.
> 
>         mobile node SPD OUT:
>           - IF source = any & destination = home_agent_1 & 
> proto = ICMPv6
>             THEN CREATE ESP TRANSPORT SA: local phase 1 
> identity = user_1
> 
>         mobile node SPD IN:
>           - IF source = home_agent_1 & destination = any & 
> proto = ICMPv6
>             THEN CREATE ESP TRANSPORT SA: local phase 1 
> identity = user_1
> 
> NOTE: As above.
> 
>         home agent SPD OUT:
>           - IF source = home_agent_1 & destination = any & 
> proto = ICMPv6
>             THEN CREATE ESP TRANSPORT SA
> 
>         home agent SPD IN:
>           - IF source = any & destination = home_agent_1 & 
> proto = ICMPv6
>             THEN CREATE ESP TRANSPORT SA
> 
> 7.3.4.  Payload Packets
> 
> NOTE: I didn't do this exercise and decided that we could 
> even live without
>        this protection if necessary.
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Jan 2003 01:02:07 +0200

> you are talking about here.

Spoofing of home addresses. A malicious MN, MN 1, sends a tunneled HOTI
to the home agent using its own SA but MN 2's home address. If the tunnel
decapsulation at the home agent is done without any check of the IP addresses,
then there is no way we can prevent this.

Note that the difference between the two solutions is that in the
current solution we deal with the IP address checks in the SPD.
In Mike's solution this is left for the application. However, the
"application" is easily available when we process MH packets but
not when we are doing IP forwarding or generic tunnel decapsulation.
That's why in Mike's solution we need to skip the tunnel authz
check, or do it in some other manner.

> configuration. Is that correct ?

Yes, if we do things in the SPD then its fine. But if we do not,
then something else has to do it. For MH reception such checks
can be easily added. For tunnel decapsulation it is harder.

This may not matter, however, since spoofing HOTIs does not
help the attacker much.

> done only much later when MH packets are received by MIPv6 module.

In the current solution, this check is done in Phase II only. This may
or may not require changes to your IKE implementation; RFC 2409 is pretty
vague on the authorization step. A good implementation should let you
do this already, but your mileage varies.

In Mike's solution you'd basically leave the IPsec/IKE free to do whatever
it wants, and then check the authz step in MH processing. So instead of
a Phase II check you'd have a check in MH processing.

Jari