Subject: Re: EAP Handling in IKEv2

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 7 May 2003 23:17:16 -0400

If it doesn't create a session key you really can't protect
against man-in-the-middle.

Radia

"Hannes Tschofenig" <[email-masked]> wrote:
>Dear all,
>
>
>
>in Section 2.16 you mention the mechanism for protecting against
>man-in-the-middle attacks:
>
>" For EAP methods that create a shared key as a side effect of
>
>authentication, that shared key MUST be used by both the Initiator
>
>and Responder to generate an AUTH payload using the syntax for shared
>
>secrets specified in section 2.15. This shared key MUST NOT be used
>
>for any other purpose.
>
>"
>
>This covers the case where the EAP method establishes a session key.
>
>Which procedure do you suggest for cases where EAP methods do not create a
>session key such as the One-Time Password (OTP)?
>
>
>
>Ciao
>
>Hannes
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 May 2003 08:12:27 +0300

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 May 2003 22:45:29 -0700 (PDT)

> supporting legacy credentials, such as passwords or token cards.

Exactly. Since virtually every RADIUS server (including FreeRADIUS)
already supports EAP, the issue is support for legacy credentials
rather than legacy algorithms -- since EAP support allows
algorithms to be easily changed.

I'd also note that in both the "password" and "token card" categories, key
generating methods exist -- although there are some token cards that do
not support key generation.

> When running outside IKEv2 or other sort of "EAP tunnels", use the existing

Yes, this "modified method" approach is one of the proposals for dealing
with non-key generating methods.

---

From: [email-masked]
Date: Sat, 10 May 2003 18:41:24 -0400

> dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2,

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

---

From: [email-masked]
Date: Sat, 10 May 2003 18:46:57 -0400

> with non-key generating methods.

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?

      --Charlie

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 11 May 2003 09:41:11 +0200

Several legacy authentication schemes involve some secret (or password)
shared between the user and a backend authentication server, such as RADIUS.
The "authenticator" or PPP server or access concentrator or LNS or whatever
it's called acts as a passthrough for the authentication, and does not ever
see the password.
While this is very attractive from a security POV, this has the limitation
that the authentication algorithm must be shared between the client and the
backend.  This is not always practical, because we're talking about old
authentication backends that may not support EAP.  In fact, there are plenty
of RADIUS servers out there that do not support EAP.

IMO there are two EAP algorithms that should be recommended:
  6 - Generic Token Card
 29 - EAP-MSCHAP-V2

The former simply passes to the user a string such as "What is your
password?" and receives the password in the "clear".  This allows the AC to
support any legacy backend server that we wish, since the AC has the real
password and can do whatever hashing is required.
The latter also works for user/password schemes and has the advantage of
generating a session key.  It does require the backend server to support
EAP-MSCHAP-V2, but I suppose this support is coming.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 11 May 2003 10:32:33 +0300

> 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

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 11 May 2003 11:11:24 +0200

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.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jari Arkko
Sent: Sunday, May 11, 2003 9:33 AM
To: [email-masked]
Cc: Bernard Aboba; [email-masked];
[email-masked]; [email-masked]
Subject: Re: EAP Handling in IKEv2

1. Allow non-kg methods.

--Jari

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 11 May 2003 14:48:28 +0200

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:[email-masked]]
Sent: Sunday, May 11, 2003 1:22 PM
To: Yoav Nir
Cc: [email-masked]; [email-masked]
Subject: Re: EAP Handling in IKEv2

> be recommended over non-kg methods, but disallowing them will lead to

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 11 May 2003 14:21:38 +0300

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 11 May 2003 05:27:52 -0700 (PDT)

>    Bernard, did you have a list of old => new methods?

Here's a small list:

     EAP MD5 => EAP MS-CHAP-V2 or EAP-ARCHIE
     GTC => EAP SECURID

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 11 May 2003 16:56:57 +0200

I must have missed something here.  How does EAP SECURID generage keys?

Has it been developed since
http://www.drizzle.com/~aboba/IEEE/draft-josefsson-eap-securid-01.txt ?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bernard Aboba
Sent: Sunday, May 11, 2003 2:28 PM
To: Jari Arkko
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: EAP Handling in IKEv2

Here's a small list:

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 12 May 2003 22:01:13 +0300 (IDT)

> with non-key generating methods.

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.

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.

Hugo

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 12:22:24 -0700 (PDT)

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

I'd like to see this included in the EAP WG MiTM document :(

Hugo -- can we  prevail upon you to do a review of
draft-puthenkulam-eap-binding-02.txt and post this and other relevant
comments to the EAP WG mailing list?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 May 2003 22:33:54 +0300

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.

> off-line dictionary attacks then its use in ikev2 becomes insecure too.

Right.

--Jari

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 13 May 2003 10:56:33 +0200

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: [email-masked]
[mailto:[email-masked]]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

I agree that it works.

Right.

--Jari