Subject: [eap] Proposed resolution to Issue 95

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 16:31:16 -0800 (PST)

Issue 95, given below, is really a duplicate of Issue 87. However, the
current WG sentiment seems to be running toward *strengthening* the
language against sequences, rather than weakening it. So this looks like a
potential Reject to me. Any comments?

----------------------------------------------------------------------
Issue 95: Sequences
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: March 4, 2003
Document: EAP-01
Comment type: Technical
Priority: S
Section: 2.1
Rationale/Explanation of issue:

Description implies that sequences are not
supported. The rationale for this is security indications, and should be
in the security section.

Requested change:

change:
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.

to:

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

and rewrite the following and add to security section:
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.

---

From: [email-masked] (Jari Arkko)
Date: Fri, 07 Mar 2003 08:04:12 +0200

> potential Reject to me. Any comments?

I think so too.

Jari