Re: The remaining IKEv2 issues

[Jari Arkko <jari.arkko@kolumbus.fi>]

Theodore Ts'o wrote:

> On the other hand, in order to be realistic, we should at least take a
> moment to recognize that there is going to be a very strong market
> demand for this support, given the assumption by many corporations
> that everything behind the firewire is goodness and light and is fully
> secure.  In those environments, if the only use of EAP outside of the
> firewall is in protected tunnels (such as IKEv2) used to gain access
> to the protected intravent via a VPN solution, then this is in fact no
> worse than making the original assumption that everything behind the
> firewall is safe.  (After all, if the attacker has access to
> unprotected EAP transactions happening behind the firewall, then s/he
> has no need to try to use this to break a VPN solution trying to gain
> access behind the firewall.)

I'm not sure compound authentication has the same kind of situation
as the protected "hard outside, soft inside" intranets have.

If the inside was safe, why would there be authentication?
I'd say its very likely that the same credentials are primarily
used for coming in to the intranet from the outside, using dial-in
or something like that. Or used for on-site WLAN access using
802.1X. Either way, its possible to that outsiders can see the
authentication message sequence, or act as MITMs and grab the
packets somewhere else.

> So given this, I propose that we open a 48-hour discussion on this
> issue.  Should we (a) say nothing about non-kg types, thus implicitly
> allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP
> types, or (c) specify that vendors MUST NOT use non-kg EAP types?

I'd prefer very much (c), but can live with (b).

I think (c) is the best match to IKEv2's secure design.
We know the MITM problem exists, and we know how to avoid
it. According to the Bernard's method and RADIUS server
information, we don't appear to have to suffer too much
from choosing the secure approach...

--Jari