Subject: [eap] Possible Resolution to Issue 52: Identity requery

From: [email-masked] (Bernard Aboba)
Date: Sat, 18 Jan 2003 23:24:05 -0800 (PST)

The following changes are offered as a potential solution to Issue 52:
Identity Requery. The proposed resolution does not state explicitly how
many times the Identity method may be used; this is handled generally in
Section 2.l, which covers Sequences. Similarly, this section also
recommends what is to be done if a Type is "unexpected". Note that the
implication is that an Identity Request could be Nak'd in that situation
(which is why the MUST was weakened to SHOULD in the first paragraph of
Section 5.1).

Change the first paragraph of Section 5.1 to:

"The Identity Type is used to query the identity of the peer.
Generally, the authenticator will issue this as the initial Request.
An optional displayable message MAY be included to prompt the peer in
the case where there expectation of interaction with a user. A
Response of Type 1 (Identity) SHOULD be sent in Response to a Request
with a Type of 1 (Identity)"

Change Section 2.1 to the following:

"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
Section 7.8) or man-in-the-middle attacks (described in Section 7.4).
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 methods, it SHOULD respond 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."

-------------------------------------------------------------------------
Issue 52: Identity requery
Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: 1
Section: 5.1
Rationale/Explanation of issue:

The restriction doesn't appear to be warranted. There's no visible
difference between, for example, an authenticator suddenly deciding to
start authentication over because the current method cannot proceed
(which should be allowed), and sending an Identity message in the
"middle" of a method (which has been proscribed). Since there's no
distinction, the requirements can't be different.

Requested change:

from:

The Identity Type is used to query the identity of the Peer. The
Authenticator will typically issue this as the initial Request;
however, an Identity Request MAY also be sent multiple times within a
sequence of methods. An Identity Request MUST NOT be sent in the
middle of another method conversation.

to:

The Identity Type is used to query the identity of the Peer. The
Authenticator will typically issue this as the initial Request;
however, an Identity Request MAY be sent at any time.