Subject: [eap] Possible solution to Issue 52: Identity Requery

From: [email-masked] (Bernard Aboba)
Date: Tue, 14 Jan 2003 07:57:45 -0800 (PST)

It strikes me that the "unexpected method" case is actually a subset of
the sequence problem, and therefore that the approach taken there
applies:

a. Sequences are "not anticipated". Similarly, the text could say that
switching in mid-stream is discouraged.

b. The correct response is a Nak. As James pointed out, a Response is
required, so as in a sequence, the Nak is the correct Response, if the
Type is not desired. On the authenticator side, I'd argue that a Nak
including a Type that was already sent should be logged (evidence of a
potential attack), but otherwise ignored.

c. Some implementations may silently discard. So switching methods in
mid-stream may not result in a response.

Here is some proposed text for Section 2.1:

An EAP conversation MAY utilize a sequence of methods.  A common example
of this is an Identity request followed by a single EAP authentication
method such as an MD5-Challenge.  However, within or associated with
each EAP server, it is not anticipated that a particular named peer will
utilize multiple authentication methods (Type 4 or greater), either by
supporting a choice of methods or by using multiple methods in sequence.
This would make the peer vulnerable to attacks that negotiate the least
secure method from among a set (negotiation attacks, described in Sec-
tion 7.9) or man-in-the-middle attacks (described in Section 7.5).
Instead, for each named peer there SHOULD be an indication of exactly
one method used to authenticate that peer name.  If a peer needs to make
use of different authentication methods under different circumstances,
then distinct identities SHOULD be employed, each of which identifies
exactly one authentication method.

If additional authentication methods are required beyond the initial
one, the authenticator MAY send a Request packet for a subsequent
authentication method, or it MAY send another Identity request.  If the
peer does not support additional authentication methods, after complet-
ing the last supported authentication method, it SHOULD respond to a
subsequent Request with a Nak, indicating no acceptable alternative, as
described in Section 5.3.  However, peer implementations MAY not respond
at all, in which case a timeout will result and authentication will
fail. Since the authenticator presumably requires successful completion
of the sequence in order to grant access, authentication failure is the
correct result. Therefore, it is not necessary for the authenticator to
determine that the peer supports sequences prior to sending a Request
for a subsequent authentication method.

The above prescription also applies in the situation where an
authenticator sends a message of a different Type prior to completion of the final round
of a given method. If the peer wishes to continue authenticating
with the method in progress, it SHOULD send a Nak in response to such a
Request, indicating the Type in progress as the alternative.
Otherwise it MAY send a Response with the same Type as the Request.
Since an EAP packet with a different Type may be sent by
an attacker, an authenticator receiving a Nak including a
preference for the Type in progress SHOULD log the event, but
otherwise not take any action.

Once a peer has sent a Response of the same Type as a Request,
some existing peer implementations might expect the method to
run to completion. As a result, these implementations silently
discard EAP Requests of a Type different from the method in progress,
despite the requirement for a Response in section 2.2.1. For this reason,
EAP authenticators that must interoperate with these peers are discouraged from
switching methods before the final round of a given method has
completed.