Re: [IPsec] draft-yamaya-ipsecme-mpsa-00

[Paul Wouters <[e-mail]>]

Regarding draft-yamaya-ipsecme-mpsa-00

The draft claims to be about "auto discovery and configuration
function". However, I don't actually see any of that in the draft. I
have no idea how nodes find out about other nodes they can talk IPsec
to.

What I do see in the draft is a mechanism for a gateway to relay keying
material (nonces!!) for a shared IPsec SA to other nodes
after authenticating such nodes.

That raises a few questions for me:

If we want to accomplish a gateway allowing authenticated parties into a
collection of IPsec nodes, why not negotiate separate SA's? There is no
real reason to use a single shared IPsec SA session key, and it vastly
reduced the security.  One conpromised node would reveal the IPsec SA
keying material, and with that an attacker could decrypt all the traffic
between all the nodes. Plus an attacker could just add a new node to
the system (depending on the discovery/permission model that I don't
fully understand)

Why not distribute some kind of token or PSK between gateway and
endpoints, so that two endpoints can then use that to setup the parent
SA and do a proper setup of any child SAs with a unique keying material
for those nodes? As a bonus, that will keep to a much closer deployment to
the existing method. A compromised node might be able to attach itself
to the group, but it won't allow the direct compromise of any other
node-to-node traffic in the collection. Also this allows each node to
reject any proposals for IP address ranges it is unwilling to relay to
a particular node.

Furthermore, I see no discovery method in the draft that tells a node
which other nodes are available via this shared MPSA. How does a node
know it can do the MPSA to another node? It seems the draft has no
method for asking the gateway about this. Without such a discovery,
administrators will still end up having to hardcode node configuration,
which is exactly what we are trying to avoid.

While the diagrams display there can be gateway-endnode and endnode-endnode
traffic using the MPSA, I see no way how the endnode could know this. As
a node, I have traffic destined for 192.0.2.1. Should I use an MPSA?

I see no correlation between SRC / DST IP addresses and the MPSA. Does this
mean any endnode can connect to any other endnode within the group and just
make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very
weak trust model. Additionally, what if I want my node to be in more then
one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting
to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between
nodes? Or will they just start sending me encrypted ESP for the MPSA? What if
someone replays some MPSA encrypted traffic appearing from one node, will my
node suddenly stop talking cleartext to it? That seems a weak authentication
model.

I find the terminology for "rollover time1" (ROLL1) and "rollover time2"
(ROLL2)  confusing, as it seems to actually be more representative of an
"expiration date" and an "activation date". It seems to also overlap with
"lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related
to the start of ROLL2. So we know when to roll, but we still need to connect
to the gateway to get the keying material? So why not just limit everything
to an expiration time for when the nodes have to contact the gateway again
for the new MPSA keying material?

The gateway is supopsed to rekey, but that can be difficult with clients
behind NAT. Since the gateway informed the clients about the lifetimes,
why not let the clients reconnect?

So in short:

- Distribute authentication information/permission, not encryption material
   (IKE SA's and traffic selectors are needed)
- Devise a mechanism to obtain a list of active nodes or a method
   to ask the gateway if a certain node is avaialble via MPSA or not.
- Reduce the information sent to the minimum required.
- Agree on some kind of scope of IP addresses for the MPSA

As it stands, I don't really see myself implementing this. There are
too many unanswered security concerns, and it does not have enough
discovery features in it for my needs.

Paul