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

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Jan 2003 10:56:06 +0100

Overall, the main findings are as follows:
   
      o  When IKE is being used, the new style simplifies the
         configuration considerably. This too is positive.
   
=> this has to be proved... IMHO it is hard to get simple
authorization without security holes.

           Question: Could we base our SPD rules on home network prefixes?
   
=> yes but it makes the home network prefixes specialized (i.e., they
should be used only for MNs and MNs should be always in visit).

         - 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.)
   
=> this is explicitely what we don't want.
   
   7.3.  Dynamic Keying
   
=> I have no interest in manual 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.

=> no, the SAs created by IKE won't get wildcard addresses (and
a destination wildcard is still forbidden by RFC 2401).
I believe we should not try to use wildcards because it will never work
with a SA pair.

          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.
   
=> I am afraid that if we punch a hole in the IKE authorization we'll
get some security problems too (i.e., the hole can be misused).

           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
   
=> usually SPD can't specify the identity to use (and explain how this
could work for the IKE responder :-).

   NOTE: We create an additional configuration table for the home agent
          to list the relationship of IKE Phase 1 identities to home
          addresses.

=> this must be done with or without authz.

          Mobile IPv6 module will check this using an API for all MH packets.
   
=> I'd like to see a concrete example of this API.

           home agent MIP ID TABLE:
             - user_1 has home_address_1
   
   7.3.2.  Return Routability Signaling
   
           mobile node SPD OUT:
             - IF interface = any tunnel to home_agent_1 &

=> so now the tunnel is an interface (good idea but with a lot of
consequences, for instance they are link-local addresses :-).

                  source = any & destination = any & proto = MH
               THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                          local phase 1 identity = user_1
   
   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.
   
=> this is a total disaster.

           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)
   
=> if the "gateway" is the outer address there is no way to create
an ESP tunnel with another address, so I don't understand to comment.
BTW, this address is the destination address (if we consider the
HA can be the initiator) ?

           home agent SPD IN:
             - IF source = any & destination = any & proto = MH
               THEN CREATE ESP TUNNEL SA: gateway = care-of address
   
Regards

[email-masked]

PS: I can't see a real advantage to this scheme, perhaps Mike can
explain again his idea?

---

From: Michael Thomas <[email-masked]>
Date: Fri, 10 Jan 2003 09:55:02 -0800 (PST)

Finally...

Jari Arkko writes:
 >    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.)
 > 

I don't understand this restriction. The _base_
requirement is that there are SPD entires which
require the _port(s)_ used by MIP be protected by
a valid SA on the HA. While it's certainly
possible to write the rule such that it covers all
ports on the HA, for example, it need not be that
restrictive. Also: it seems to me that the SPD
rules don't necessarily need to be symmetric: the
HA may only have a SPD rule for *only* the MIP BU
port, but a MN (wanting a VPN-like service too,
say) might have a SDP rule which says that _all_
traffic to the HA must use, say, an ESP tunnel.

 >         movement. (See 7.3.2 below.)

This is really an IKE issue, I think and is pretty
orthogonal to MIP since multihoming has pretty
much the same problem. Also: I think it's true
regardless of tunnel/transport. This should be
brought up with IPsec WG, I think (in fact, I
think it has already). I don't see this as a make
or break issue as it's really a question of
optimizing the Main Mode runs. Indeed, KINK
doesn't have a Main Mode so this isn't even a
problem.

 >         Question: Does it help if we keep the modify-the-tunnel-gw
 >         API as well?

I don't understand this question. Are you saying
that we should have a method to move the tunnel
endpoint address for IPsec SA's?? This may be
reasonable, but I think it would be better to
describe this in a separate ID which also allow
IPsec tunnels to be used instead of IP-IP tunnels
for MN/HA traffic (isn't Gopal part of a group
looking at this?)

 >       - Address spoofing of HOTIs can't be checked (but this isn't
 >         considered very dangerous given that HOTs are routed correctly).

Yes, I've never quite understood how this made it
from nice-to-have to a requirement. RPF checking
here is probably sufficient, and shouldn't rise to
anything more than a SHOULD, IMO (this is already
covered by a BCP anyway).

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

Right. The minimum requirement for MIP is that MIP 
traffic be protected. Selectors which allow for
other traffic is fine though.

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

Correct.

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

Correct.

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

Nit: I'd avoid "Phase 1", etc. What is needed is a
correlation of SPI to authorized home
address. This binding can be done on a first come
first serve basis, encoded somehow in the
credential, fished out of a AAA database, etc. The
MIP requirement is *only* that this binding take
place *somehow* (likely as a setsockopt from IKE
to the MIP kernel module, but that's just an API
issue).

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

See the above notes about minimum requirement
being a selector based off of port numbers. I
don't see us as needing anything address specific
in the SPD.

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

Right, hence the desire for RPF... but we want RPF
anyway...

I'll get to the examples in a bit...

	 Mike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Jan 2003 18:18:23 +0200

> traffic to the HA must use, say, an ESP tunnel.

Ah yes, but the problem is that the same "ports" (they
are protocols in fact) are used both by home agents
and correspondent nodes. So only the addresses can be
used to distinguish these. But as I noted in a later
e-mail, it appears to be possible to use the network
prefix as a distinguishing feature.

Jari