eap Mailing List: Re: Issue 251

[Bernard Aboba (aboba]

> I agree with your assessment. I think we can reject
> #252.

I agree.

> Right. Its not. Here's what Section 2.1 says, with my
> emphasis added:
>
>     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, the peer
>     and authenticator MUST utilize *only one authentication method (Type 4
>     or greater)* within an EAP conversation, after which the authenticator
>     MUST send a Success or Failure packet.

Indeed.  This behavior is *required* in order to enable EAP Network
Discovery to work.  However, the client can put a limit on the total
number of potential Identity round-trips, as should the server (in case
the hint provided in the EAP-Request/Identity is not understood).

> Reading RFC 3748 Section 2 bullets [1] and [4], and
> Section 4.2 first paragraph, the spec seems to say
> that immediate Failure is also forbidden. There
> is strictly speaking no keyword that prohibits it, but
> the text always indicates that you must have a
> method in progress before you can send a Failure.
> See this text from Section 4.2:
>
>    "If the authenticator cannot authenticate the peer
>     (unacceptable Responses to one or more Requests), then
>     after unsuccessful completion of the EAP method in
>     progress, the implementation MUST transmit an EAP
>     packet with the Code field set to 4 (Failure)."
>
> (You could perhaps debate if the part in parenthesis,
> is a part of the normative text and exhaustive.)
>
> I think you are correct.
>
> What do others think?
>
> If this is correct, then it may be that the state machine
> needs some modification. OTOH, when I read -04 peer state
> machine, one of the required conditions to go into the FAILURE
> state is to have reqId == lastId. Since lastId has been initialized
> to NONE, it seems that an immediate Failure is not accepted
> by the current state machine.

I agree with Jari here.  The text of RFC 3748 assumes that an EAP
conversation begins with a Request, which implies that a "canned" Failure
is not allowed.