RE: EAP Handling in IKEv2

["Yoav Nir" <ynir@CheckPoint.com>]

As far as possible, we'd like to have simple clients - we don't want to have
an IKE client that supports every conceivable EAP method.  The smarts should
be at the server.  Ideally, the client would pass all credentials to the VPN
server.  The server would then be able to work with whatever authentication
method the backend server supports.  The problem with all the kg methods
that I know of (such as TLS or MS-CHAPv2) is that the gateway is oblivious
to the credentials passed, so the client has to be able to work with the
method.

MS-CHAPv2 is a good method for all user/password methods including token
cards, one-time passwords and lots of others, but it requires all backend
servers to  support this protocol.  This is not the case at this time.
We've been asked to support everything from private fields in LDAP servers,
Unix and NT  passwords to RACF databases, VM/ESA directories and various TOD
based algorithms.  It is naive to expect all these things to support
MS-CHAPv2.  Unfortunately, I don't know of any EAP method that generates a
key, but gives the password to the authenticator.  If there was, then this
would be the recommended EAP method IMO.

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
Sent: Sunday, May 11, 2003 1:22 PM
To: Yoav Nir
Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com
Subject: Re: EAP Handling in IKEv2



Yoav Nir wrote:

> While there seems to be a consensus that kg methods are preferrable, I
don't
> believe that we can disallow non-kg methods.  There simply are too many
> authentication schemes and servers out there for us to mandate throwing
them
> all away.  The MitM vulnerability should be mentioned and kg methods
should
> be recommended over non-kg methods, but disallowing them will lead to
> non-adoption of IKEv2.

Well, I think we have discussed in the past throwing out old legacy
methods, and found that it was clearly not possible.

However, the input we're trying to give now is that there may be
a significant difference with respect to throwing out credentials,
and throwing out methods. I agree that credentials should not be
thrown away.

The replacement of non-kg methods with kg-methods appears easier
though for the following reasons:

    - Existing credentials can be used.

    - All EAP intermediaries (such as AAA proxies or maybe
      the VPN gateway) need no modifications.

    - Clients have to be modified anyway for the introduction
      of IKEv2, so an update of a new auth method code at
      the same time does not appear to be technically infeasible.

    - There already exists methods for this purpose,
      e.g. MS-CHAP can be replaced with EAP MS-CHAPv2
      which does generate keys.

We do need the final AAA server to support the kg method,
and we for every non-kg method we need a corresponding
kg method. I wish I could say something definite about the
likelihood of the availability of this. But I don't agree
that this means throwing out authentication servers. EAP
support on a server seems a fairly reasonable requirement
these days (for wireless LANs etc), so in the worst case
the server needs an update to support a new method. Perhaps
we should also develop a list of common authentication
methods, to see how large fraction of them has corresponding
kg methods. Does anyone who "owns" a particular method
want to step out and say that they don't have or can't
produce a kg variant?

--Jari