RE: EAP Handling in IKEv2

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

Granted, if the RADIUS server supports EAP MS-CHAPv2 we can use the legacy
passwords with the new method and everybody's happy.  The problem with
legacy authentication is that it sometimes comes with a legacy
authentication server that may not support EAP at all.

Take a hypothetical administrator who wants to use a mainframe RACF database
as their user directory.  10 years ago they wrote an assembly language
program (the mainframe administrator's favorite language) that mimics a
RADIUS server that supports only PAP.  Their program is simple: it just
receives the name and password, translates them into EBCDIC and runs a
RACHECK macro to verify that the user password is correct and that the user
is allowed to use the resource "VPN".  This was easily integrated with
XAuth.  Should we now force the administrator to rewrite his program so that
it supports MS-CHAPv2?

I would rather have the client just send the password to the VPN gateway and
have the VPN gateway communicate with the authentication server by whatever
means necessary.  In a previous post I suggested using the GTC method which
simply sends the password.  Untunneled GTC, just like PAP, is so insecure
that no client will ever be configured to use it.  GTC will only be used
either through a tunnel or through a secure medium.  Now if there was a
method that passed the password to the gateway and also generated keys, that
would be great, but none of the EAP methods has a published document (draft
or RFC) and does that.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jari Arkko
Sent: Monday, May 12, 2003 9:34 PM
To: Hugo Krawczyk
Cc: Bernard Aboba; IPsec WG
Subject: Re: EAP Handling in IKEv2



Hugo Krawczyk wrote:

> I like the distinction between reusing "legacy credentials" as opposed to
> reusing "legacy methods". However, this means that we are willing to
> *change* the authentication methods traditionally used by the "legacy
> credentials". If this is a practical approach (namely, it can gain
> widespread support in corporate organizations, etc) then the solution is
> very simple and does not require the design of key-generating methods.
> All is needed is that the modified methods authenticate the "context" in
> which they are run. Specifically, when run with ikev2 the authenticated
> information should include a unique "protocol identifier" (such as
> "ikev2", "rfc-xxxx", "port-yyy", etc). This is the simplest and least
> "intrusive" solution to the man in the middle problem while allowing use
> of the same credentials in different contexts.

Yes, this is also one of the proposed approaches for
dealing with MitM.

I agree that it works.

I'm not 100% sure which way is easier, certainly this
would be easier than designing a new kg method. But
it might also be the case that the RADIUS server being
used already supports EAP MS-CHAPv2 (for instance) which
can be used if you have passwords. So switching to an
existing kg method is of course even easier.

> INPORTANT NOTE: Even in this case let's keep in mind that if the
> credential used under an EAP method in ikev2 has low entropy (such as a
> password) and is also used in another method that is vulnerable to
> off-line dictionary attacks then its use in ikev2 becomes insecure too.

Right.

--Jari