Subject: [eap] Issue 2: Alternative indications not well defined

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 08:30:40 -0700 (PDT)

Issue 2: Alternative indications not well defined
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 25, 2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority: S
Section: 3.2.1, 3.3.1, 3.3.2, 4.2
Rationale/Explanation of issue:

The EAP Implementation Survey results disclose that alternative
indications are not being implemented. In addition, alternative
indications are not described in enough detail to be interoperable. What
is an alternative indication, exactly? It would appear that alternative
indications are not available on every media, and also that they increase
the ability of an attacker to spoof packets.

[BA] Question - are method-specific success and failure indications
"alternative indications" in this context? If so, how do existing
implementations process them?

Resolution

Changes:

Delete sections 3.2.1, 3.3.1 and 3.3.2. Change the following text in
section 4.2 from:

"Implementation Note: Because the Success and Failure packets are
not acknowledged, they may be potentially lost. A peer SHOULD
allow for this circumstance, by taking alternate indications of
Success and Failure into account. The alternate indications are
media-specific, and are described in section 3."

To:

"Implementation Note: Because the Success and Failure packets are
not acknowledged, they may be potentially lost."