Subject: [eap] Proposed Resolution to Issue 62: Accept

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

Here is the proposed text for resolution of Issue 62: Protected
success/failure.

Insert a definition of a protected and unprotected indications in Section
4.2.1:

"Within EAP, success and failure indications consist of the
EAP Success and Failure messages, as well as method-specific
result indications. These indications may be protected or
unprotected.

Where a lower layer ciphersuite is in use that
provides per-packet integrity and authentication protection,
or where the lower layer is considered physically secure,
EAP may be considered secure from tampering, and
EAP Success and Failure packets may qualify as protected
indications.

Otherwise, EAP Success and Failure packets
are considered unprotected indications which may be
spoofed, since they contain no embedded message integrity check.
Note that Where EAP itself is used to provide the keys
for use with a lower layer ciphersuite, protection may
not be enabled until key derivation is complete so that
only a portion of the EAP conversation may be protected.
If the lower layer ciphersuite is not enabled when the
EAP Success or Failure packet is sent, then these indications
are considered unprotected."

Change:

"Where a protected success/failure indication has been
received at the EAP layer by an EAP Peer, it MUST accept
and process the protected indication."

To:

"[a] Processing of protected success and failure indications.
Where a protected success/failure indication has been
received, the  implementation MUST validate the EAP method-specific
or lower layer MIC, with a MIC failure handled via silent
discard, as specified in Section 4.1."

=============================================================
Issue 62: Protected success/failure
Submitter name: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: January 3, 2003
Document: RFC2284bis-08
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Page 6: "Protected success/failure" is never defined.

Page 6: There is a sentence which says:

Where a protected success/failure indication has been
received at the EAP layer by an EAP Peer, it MUST accept
and process the protected indication.

This is a vacuous requirement, because there is no definition of what it
means to "process" the "protected indication". At the very least this
should indicate that "to process" means something like (a) apply all the
protections of whatever ciphersuite that one believes to have been applied
to the message to (b) extract a success/failure message, which is then
handled according to the normal rules for EAP success/failure messages,
and
(c) received EAP success/failure messages that arrive unprotected are
silently discarded if protection is expected.