Subject: [eap] Issue 104: Sequence prohibition

From: [email-masked] (Bernard Aboba)
Date: Mon, 14 Apr 2003 10:45:50 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 14th, 2003
Reference:
Document: EAP-01
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

At IETF 56, it was proposed that sequences of EAP methods MUST NOT be
supported (with an exception for tunneled EAP methods). The following text
changes support that proposal.

Change Section 2.1 from:

" 2.1 Support for sequences

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 4.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."

To:

"2.1 Support for sequences

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 a peer
MUST utilize only one authentication method (Type 4 or greater)
within an EAP conversation.

Once a peer has sent a Response of the same Type as the initial
Request, an authenticator MUST NOT send a Request of a different Type
prior to completion of the final round of a given method, and
MUST NOT send a Request for an additional methods of any Type
after completion of the initial authentication method.

Supporting multiple authentication
methods within an EAP conversation would add complexity
to the EAP protocol, would enable man-in-the-middle attacks
(see Section 7.4), and would result in interoperablity problems,
since existing EAP implementations typically do not support
sequences.

If an additional authentication method is requested by the
authenticator, or if the authenticator sends a Request of
a different Type prior to completion of the final round of
a given method, the peer SHOULD silently discard the
Request. As an alternative, the peer MAY
respond with a Nak, indicating no acceptable alternative,
as described in Section 5.3. Since spoofed EAP
Request packets may be sent by an attacker, an
an authenticator receiving an unexpected Nak SHOULD log the
event.

The case where a single EAP authentication method is
utilized, but other methods are run inside it, does not
qualify as a sequence of EAP methods as defined here. Such
"tunneled" methods appear to the EAP state machine as a single
method. Backward compatibility can be provided, since a peer
not supporting a "tunneled" method can reply to the initial
EAP-Request with a Nak. To avoid adding man-in-the-middle
vulnerabilities, "tunneled" methods MUST support protection
against these attacks.

Within or associated with each EAP server, it is not anticipated
that a particular named pper will support a choice of methods.
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). 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. "

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 17 Apr 2003 14:44:48 -0400

I think this is fine. I would suggest dropping the last paragraph or adding 
it to a security appendix.

--On Monday, April 14, 2003 10:45 AM -0700 Bernard Aboba 
<[email-masked]> wrote:

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap