Re: EAP Handling in IKEv2

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

Radia Perlman - Boston Center for Networking wrote:
> If it doesn't create a session key you really can't protect
> against man-in-the-middle.

I think you meant "can't protect against mitm *and* still
use the same credentials outside IKEv2".

But surprisingly, even this may not be a real limitation.
The problem is that it isn't clear exactly what it means to
support "legacy authentication". For example, are we
trying to support

   1. "Password authentication" i.e. the use of existing passwords
      in a new context?

   or

   2. Are we trying to support existing methods, e.g.
      MD-Challenge/CHAP?

It seems that the main interest is *not* supporting legacy
authentication methods. I believe that the issue is rather
supporting legacy credentials, such as passwords or token cards.

If so, it may be possible to keep the credentials as they are but
replace the existing method with a modified one when running inside IKEv2.
When running outside IKEv2 or other sort of "EAP tunnels", use the existing
method as-is.

There appears to be key generating variants available for many of the
popular legacy credentials. For instance, the existing passwords for
dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2,
which can generate keys.

So, what does the WG want to do:

   1) Allow the non-kg methods as is. Mitm possible. This is
      the current approach.
   2) Disallow non-kg methods. May limit usability of IKEv2 EAP
      support. (But note that today there exists also a number
      of EAP methods that *do* generate keys; CHAP passwords
      for dial-in might not be possible to reuse but e.g. cell
      phone sim cards could still be.)
   3) Disallow non-kg methods, but provide a set of key generating
      replacement methods for the commonly used non-kg methods.

See also http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20123

--Jari