Subject: [eap] non-keygen methods & binding problem draft

From: [email-masked] (Jari Arkko)
Date: Wed, 23 Apr 2003 15:39:53 +0300

Bernard and I were discussing potential solutions for the binding
problem with the "worst case" legacy EAP methods. These methods are
such which don't generate session keys. During this discussion, it
became apparent that draft-puthenkulam-eap-binding-02.txt could perhaps
be improved by adding more details about this case.

Specifically, Section 3.2 rule S2 states the following:

      Guarantee that the same peer credential is never usable inside and
      outside a tunnel using server and client policy. This prevents
      condition CC-A.

      This solution actually works for all methods, but is sometimes hard
      to deploy, due to legacy deployments, and since clients and servers
      need to be synchronized for proper policy enforcement. An
      additional problem with this solution is the manageability issues
      due to the multiple credentials that have to be managed by the same
      client and server.

and then later:

      S2 is realizable just using policy techniques on the client and server
      ends.

In Section 3.3 the non-key generating method issue is expanded a bit:

     [1] Providing separate credentials for a user identity supported inside
         and outside tunnels.

         ...

     [2] Enforce client and server policy to always use authentication
         methods inside tunnels.

     ...

     For non-key deriving methods, if they are modifiable, then using a
     signal to indicate when they are running inside a tunnel would
     also prevent the attack. This works because the server is able to
     distinguish between an attacker diverting a method into a tunnel
     versus a client method intentionally initiated inside a
     tunnel. However such signals need protection from spoofing.

The case of non-key deriving methods is an important one. Both PIC and
IKEv2 have large user groups interested in running existing
password-based methods.

Our concern is that the above description does not fully describe the
possibilities available for these users. Namely, the problem is that
there has been some confusion about 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. CHAP?

It seems that the main interest is *not* supporting legacy
authentication methods, since today EAP support is available on
virtually all shipping servers, including FreeRADIUS. Therefore, all
devices will be able to support EAP, and intermediate devices will be
able to support any method.

We 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 a
tunnel (or within EAP). When running outside 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. The choice between the variant is easy
as long as both the authentication method and the tunnel endpoints
are in the same nodes, because then both nodes know whether a tunnel
is being used.

Similarly, the same credentials could be used inside the tunnel even
without key generation if the authentication method is changed
slightly. For instance, using "password" as the password outside the
tunnel and SHA1("password") as the password inside the tunnel. This
would appear to prevent the man-in-the-middle attack.

These types of solutions may be necessary in order to deal with legacy
credentials that currently don't generate keys, and with tunneling
protocols that can't be changed easily. As an example of the latter,
changing HTTP/TLS to take in account compound keys may be hard but the
"password"/SHA("password") trick may be easier to do within HTTP Digest
running inside HTTP/TLS.

Does this make sense?

If yes, perhaps some of the aspects from the above should be discussed
in the draft.

--Jari