Subject: [eap] Re: Issue 104: Sequence prohibition

From: [email-masked] ([email-masked])
Date: Tue, 15 Apr 2003 21:50:29 +0300

Hi,

Was this the consensus at IETF 56? The minutes aren't
completely clear on this topic: issue 87 really refers=20
only to starting another method before the first one is=20
completed. Was the decision that not only type change=20
during one method is forbidden, but all sequences=20
(of methods >=3D4) are forbidden?

(I'm not an fan of sequences myself, but we've been=20
working on the state machine diagrams with John, Nick
and Yoshihiro, and the current versions are in rather
good shape, and do support sequences. We can change
them to forbid sequences if the consensus is
that they must not be allowed.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: Monday, April 14, 2003 8:46 PM
> To: [email-masked]
> Subject: [eap] Issue 104: Sequence prohibition
>=20
>=20
> 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:
>=20
> At IETF 56, it was proposed that sequences of EAP methods MUST NOT be
> supported (with an exception for tunneled EAP methods). The=20
> following text
> changes support that proposal.
>=20
> Change Section 2.1 from:
>=20
> " 2.1 Support for sequences
>=20
> 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.
>=20
> 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.
>=20
> 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."
>=20
> To:
>=20
> "2.1 Support for sequences
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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: Tue, 15 Apr 2003 21:22:38 -0400

I believe the discussion was that sequences would not be allowed except 
within a protected method.  I think the requirement here is that 
"protected" variable be set that then allows sequences.

We should add this to the state machine.

John

--On Tuesday, April 15, 2003 9:50 PM +0300 [email-masked] wrote:

> completely clear on this topic: issue 87 really refers
> only to starting another method before the first one is
> completed. Was the decision that not only type change
> during one method is forbidden, but all sequences
> (of methods >=4) are forbidden?
>
> (I'm not an fan of sequences myself, but we've been
> > supported (with an exception for tunneled EAP methods). The
> > following text
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap