eap Mailing List: Re: [Issue 248] Comments on EAP state machine v4

[Nick Petroni (npetroni]

> >>Comment #12 - Technical
> >>
> >>This one is stupid but what happens, according to Figure 4, when the
> >>standalone authenticator fails directly, i.e. starts by INITIALIZE,
> >>transitions to SELECT_ACTION where Policy.getDecision replies FAILURE
> >>and thus transitions to FAILURE - in the FAILURE state, I bet there is
> >>some problem with eapReqData = buildFailure(currentId) since currentId=NONE
> >>
> >>
> >This is a problem with Canned Success/Failure in general since only
> >Requests modify the Identifier field. IEEE 802-1X-REV states the following
> >in 8.2.4.1.3:
> >  txCannedFail. An EAPOL frame of type EAP-Packet, containing an EAP
> >                Failure packet constructed by the Authenticator, is
> >                transmitted to the Supplicant. In the case that
> >                no EAP communication was taking place on the port, then
> >                any value of Id may be used in the identifier field of the
> >                EAP frame. In the case that there was an EAP communication
> >                taking place on the port, then the value of the Identifier
> >                field in the EAP packet is set to a value that is different
> >                from the last delivered EAPOL frame of type EAP-Packet.
> >
> >We could add similar text if you like.
> >
> It is not stricto sensu a canned success/failure IMO.
It's not? I definitely do not understand then. I define canned failure as
without any previous packets the authenticator decids failure will be sent
and sends it without any other EAP conversation.

> It's just that although RFC 3748 prevents IMHO a stupid server to
> directly start an authentication by sending a failure (not very
> explicitly, perhaps see the beginning of section 2 of RFC 3748 but it
> doesn't sound very normative or section 4.2 of RFC 3748), figure 4
> relies on the policy (policy.getdecision) to avoid this behavior... and
> I think this is worse stating that the authenticator's policy must
> comply to this!
I don't see the RFC as denying the use of immediate failure. The behavior
is valid IMHO.

> I have problems to understand the .1X text: does it authorize a valid
> authenticator to send directly a failure message ("in the case that no
> EAP communication was taking place on the port, then any value of Id may
> be used in the identifier field of the EAP frame") could you please
> clarify it for my poor brain?
The Failure or Success messages in EAP use the last valid Identifier value
from the EAP conversation. However, this text is referring to the case
where no EAP conversation took place, you are just sending a Failure. This
is termed a canned failure, and I think this is the case you were
describing. The 802.1X-REV document states that ANY Identifier is valid
for Failure in that case (and similarly for canned success). Perhaps you
can distinguish your case from the "canned" case for a slow person like
myself? Sorry I'm not getting it yet.

Regards,
nick