Subject: [eap] Proposed Resolution of Issue 57

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 21:52:35 -0800 (PST)

Issue 51 also deals with the role-reversal issue.
I believe that the fix adopted for that issue also
resolves parts of Issue 57.

The section cited on page 6 requires a complete rewrite,
so the best thing to do is probably to work on that rather
than trying to patch up the current text. Note that RFC 2284bis
deals only with the protocol run between the authenticator and
peer; security between the authenticator and authentication
server is the subject of RFC 2869bis and Diameter EAP.

Here is the proposed text for section 7.8:

Change:

"In EAP there is no requirement that authentication be full duplex or
that the same protocol be used in both directions. It is perfectly
acceptable for different protocols to be used in each direction. This
will, of course, depend on the specific protocols negotiated. However,
in general, completing a single, mutual authentication is preferable to
two one-way authentications, one in each direction."

To:

"In EAP there is no requirement that authentication be full duplex or
that the same protocol be used in both directions. It is perfectly
acceptable for different protocols to be used in each direction. This
will, of course, depend on the specific protocols negotiated. However,
in general, completing a single, mutual authentication is preferable to
two one-way authentications, one in each direction.
This is because separate authentications that are not
bound cryptographically to demonstrate they are part of the
same session are subject to man-in-the-middle attacks."

-----------------------------------------------
Issue 57: Mutual vs. bi-direction authentication
Submitter name: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: January 3, 2003
Document: RFC2284bis-08
Comment type: T
Priority: S
Section: 2, pp. 5
Rationale/Explanation of issue:
Major Issues: Page 5 includes the text:

7. Since EAP is a Peer-to-Peer protocol, after
authentication in one direction is complete, the direction
of authentication MAY reverse, with the endpoint
previously serving as the Authenticator assuming the Peer
role, and the former Peer now taking on the Authenticator
role. As with the original conversation, the reversal is
signaled by the (new) Authenticator sending a Request.
Support for bi-directional authentication requires that
each endpoint implement both the Peer and Authenticator
roles.

and page 31 continues in this theme with

In EAP there is no requirement that authentication be full
duplex or that the same protocol be used in both
directions. It is perfectly acceptable for different
protocols to be used in each direction. This will, of
course, depend on the specific protocols negotiated.
However, in general, completing a single, mutual
authentication is preferable to two one-way
authentications, one in each direction.

These two texts appear to have been written under the misapprehension that
two unrelated unilateral authentications glued together in arbitrary
undefined ways can result in multual authentication. It does not and
cannot; in general the two unilateral authentications remain simply
unilateral authentications. It is in general not feasible to defeat
man-in-the-middle attacks--and hence in general it is not feasible to rely
on the unilateral authentication for any useful assertion--without
relating the two cryptographically in very specific ways. Allowing
reversal of roles is a recipe for disaster unless very great care is taken
to relate the two
authentications, and there is no evidence such a task is even feasible for
all but a few legacy unilateral authentication mechanisms. We have already
seen a variant of this problem with PEAP and TTLS, both of which are much
stronger than the construction this text seems to sanction.

To correct this problems, I suggest adding text at the end of that cited
on
page 5 such as "In environments where man-in-the-middle attacks are
possible, at least one of the two concrete Authentications MUST rely on an
algorithm that performs a mutual authentication. This obviates the need
for
reversing the roles of Authenticator and Peer." To the end of the text
cited
from page 31, as text something like "This is because using separate
authentications that are not bound cryptographically to demonstrate they
are
part of the same session are always subject to man-in-the-middle attacks."
Or better yet, explicitly ban role reversal of the kind indicated here.
That
is simpler, and simplicity almost always leads to better security.

Page 6: There is a sentence that begins

Unless protected by an underlying link layer ciphersuite

In the case where the Authentication Server is not the Authenticator, this
suffers from a similar problem. Relying on a link layer ciphersuite
between
the Authenticator and the Peer to protect messages between the
Authentication Server and the Peer is subject to man-in-the-middle abuses;
if the protections are not applied end-to-end, then they cannot
necessarily be effective. I think what is really intended is that the EAP
messages be
protected by a ciphersuite associated with the concrete authentication
method, and the text should be updated to reflect this.
-- Jesse