Subject: [eap] Proposed Resolution of Issue 61: Support for Sequences

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 07:23:07 -0800 (PST)

Issue 61, enclosed below, requests clarification of sequence support
within EAP. Comments from implementors disclosed issues with supporting
sequences, as well as concerns over whether language in RFC 2284 was being
weakened. As a result, the proposed resolution is to restore the RFC 2284
language, with clarifications, in a new section 2.1:

"2.1.  Support for sequences

An authenticator MAY authenticate the peer using a sequence of methods.
A common example of this is an Identity request followed by an EAP
authentication method such as an MD5-Challenge. If additional authenti-
cation methods are required, the authenticator MAY send a Request packet
for a subsequent authentication method, or it MAY send another Identity
request.

However, within or associated with each EAP server, it is not antici-
pated that a particular named peer would be authenticated by multiple
methods, 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.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 the peer does not support additional authentication methods, after
completing the last supported authentication method, it SHOULD respond
to a subsequent Request with a Nak, indicating no acceptable alterna-
tive, as described in Section 5.3.  However, peer implementations MAY
not respond at all, in which case a timeout will result and authentica-
tion 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."

-------------------------------------------------------------------
Issue 61: Support for EAP Sequences
Submitter name: Hao Zhou
Submitter email address: [email-masked]
Date first submitted: January 7, 2003
Document: RFC2284bis-08
Reference: http://mail.frascone.com/pipermail/eap/2003-January/000494.html
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue:

The current 2284bis doesn't distinguish FAILURE and SUCCESS from
individual method and the final one from Authenticator, which makes it
hard to support sequence of EAP methods.

I assume it is preferred that the existing EAP methods will require no
change to be supported for sequences. They currently send out EAP-SUCCESS
and EAP-FAILURE by themselves. On the other end, authenticator sometimes
send out "canned " SUCCESS and FAILURE messages after receiving
Accept/Reject from the server [IEEE8021X]. Obviously, we need to
distinguish those two types of success and failure to continue the
sequence.

I wonder if extending the EAP-SUCCESS and EAP-FAILURE message to include a
EAP method type would solve this.

There would be two types of EAP-SUCCESS and FAILURE:
1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final
success and failure;
2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type
to indicate individual eap method success and failure. Without requiring
changes in the existing individual methods to be used in the sequence,
they would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP
layer would append the EAP type to the success and failure packets if the
individual methods are chained. Otherwise, send the message out without
modifying it, which indicates final success and failure.

In addition to above, an acknowledgment of receiving the success and
failure message might be needed to support sequence. For example, after
EAP method 1 received EAP-SUCCESS, it sends out acknowledge to the backend
server, so backend server can start EAP method 2. This is due to
unreliable transmission of lower layer, success or failure message might
not reach the client. Server should not start method 2 until peer
acknowledges that it finishes with method 1.