Subject: [eap] RE: Proposed resolution to Issue 129: More NITs

From: [email-masked] ([email-masked])
Date: Tue, 13 May 2003 10:05:07 +0300

Bernard Aboba wrote:

> Change the text in Section 3.4 from:
>=20
> "Lower layer failure indications provided to EAP by the lower layer
> MUST be processed and will cause an EAP exchange in progress to be
> aborted. However, lower layer success indications MUST NOT affect EAP
> message processing so that an EAP implementation MUST NOT conclude
> that authentication has succeeded based on those indications."
>=20
> To:
>=20
> "Lower layer failure indications provided to EAP by the lower layer
> MUST be processed and will cause an EAP exchange in progress to be
> aborted. However, lower layer success indications MUST NOT affect EAP
> message processing so that an EAP implementation cannot conclude
> that authentication has succeeded based on those indications."

Well, actually lower layer success indications could (or even
should) be processed in some circumstances (when the peer would
be willing to accept an EAP Success message).

How about this?

   "If a peer receives a lower layer success indication when it
   would be willing to accept an EAP Success message, it MAY
   conclude that the Success message was lost, and behave as it
   had received a Success message. In all other circumstances,
   lower layer success indications MUST NOT affect EAP message
   processing."

(Or should that MAY be a SHOULD?)

> Change the text in Section 7.14 from:
>=20
> "[a] On the peer, all EAP packets MUST be silently discarded, except
> for those with Code=3D1 (Request) and Type=3DMethod-Type. This
> implies that methods supporting "strict interpretation" do not
> utilize Notification, but instead support their own
> method-specific error messages."
>=20
> To:
>=20
> "[a] On the peer, all EAP packets MUST be silently discarded, except
> for those with Code=3D1 (Request) and Type=3DMethod-Type. This
> implies that methods supporting "strict interpretation" do not
> send or expect to receive Notification-Requests but instead=20
> support their
> own method-specific error messages."

Actually, I think we don't need Section 7.14 anymore. The
"strict interpretation" was very useful when it was possible
to switch from one method to another (and it was possible that
successful authorization result would require more than one
successful EAP method).

Now sequences are forbidden, and the "usual" ("non-strict")
processing rules specify the same behavior. E.g. 2.1 says that
the peer must silently discard requests for other types, and 4.2
deals with Success/Failure.

The only thing left is Notifications. I think this could be
dealt in Section 5.2 by adding the following after the first
paragraph.

   "An EAP method MAY indicate within its specification that
   Notification messages must not be sent during that method.=20
   In this case, the peer MUST silently discard Notification
   Requests from the point where an initial Request for=20
   that Type is answered with a Response of the same Type."

(and by removing 7.14)

Best regards,
Pasi