Re: EAP Handling in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

Jari Arkko <jari.arkko@kolumbus.fi> wrote:
> 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.

I'm confused.

I did not mean to imply that if EAP is used with IKE then the same EAP
credentials could not be used with other protocols. That would be nice
from a security perspective, but would be impossible to enforce and not
practical. What the text says is that if the EAP method generates a
shared session key as a side effect of authentication, then that session
key for that authentication must not be used outside the context of
IKE. This seems much less restrictive. I'm assuming (perhaps naively)
that if EAP produces a shared session key as a side effect of
authentication, then it will produce a different one on each run of the
protocol.

For interoperability, it would be good to specify recommended EAP
algorithms, probably in the algorithms document. Do people know what
algorithms we're expecting to see?

      --Charlie Kaufman