Re: EAP Handling in IKEv2

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

Charlie_Kaufman@notesdev.ibm.com wrote:

> Uhhh... have I missed something? Where is this proposal? Since IKE does a
> Diffie-Hellman exchange, it will have keying material whether EAP generates
> a key or not. Using the EAP key protects against MITM attacks. If there is
> no EAP key, then I believe there can be no protection for MITM attacks (as
> Radia noted). So what did you have in mind?

We are quite happy with the IKEv2 specification as far as the key-generating
EAP methods are used. Then everything is fine.

The discussion is about what to do with non-key-generating methods.
The approach chosen in current IKEv2 draft is that such methods are
allowed. As is generally known, this results in a MitM attack
vulnerability.

We do agree that for non-kg methods there can be no MitM attack
protection. However, we question a bit the need to support such
*methods*. We do see a need to support the *credentials* that are
currently used by non-kg methods, such as CHAP in PPP or EAP-MD5 in EAP.
That is, the legacy support we see as necessary is keeping the
currently deployed credentials.

However, this does not imply that we have to use the deployed
methods. The same credentials could be used by newer, updated
methods that do generate keys as well. So, we see two potential
approaches here:

1. Allow non-kg methods.
2. Disallow non-kg methods, but use the same credentials
    with existing or new methods that do produce keys.

Either way, the corporate network manager with a RADIUS database
for dial-in can use the same database for IKEv2. And publication
of IKEv2 can be done in about the same time either way. Both
approaches require implementation work in clients and VPN gateways,
because IKEv2 is new. However, the approaches differ in the
following respects:

- Approach 1 has a MitM vulnerability.
- Approach 2 may require work to develop kg EAP methods to
   correspond to existing non-kg methods. This does not
   need to be done within IKEv2 document, however.
   And a number of such methods appear to exist already,
   so its not clear to me how much new work, if any is
   needed. Bernard, did you have a list of old => new methods?
- In approach 2, the final home RADIUS server needs to
   support the kg methods. (Like in the case of the
   method development, they may already do this.)

In conclusion this appears to be a choice where we can
in any case reuse existing corporate investments and
require no new effort for credential deployment, and
publish IKEv2 document timely. The differences are
security vs. possibly some work in finding or developing
kg methods.

Does this clarify the issue? How do you see the tradeoffs
and what do you want to do?

--Jari