Subject: [eap] Re: Issue 251

From: Bernard Aboba <[email-masked]>
Date: Sat, 24 Jul 2004 17:13:58 -0700 (PDT)

> 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.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 27 Jul 2004 10:58:41 -0400 (EDT)

> > by the current state machine.
I'll take a closer look at the SM and make sure this is not allowed then.

> conversation begins with a Request, which implies that a "canned" Failure
Can I ask what category 802.1X canned messages fall into? I guess they
are just the use of EAP messages outside of the protocol? Or perhaps I
misunderstand when they can occur.

nick

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Jul 2004 08:04:35 -0700 (PDT)

> misunderstand when they can occur.

802.1X "canned" messages are encapsulated EAP packets.  So an 802.1X
packet containing an EAP Success is expressly forbidden under RFC 3748,
even though I think it is still mentioned in IEEE 802.1X-2004.  Similarly,
our discussion of whether "canned" EAP Failure is illegal also applies to
"canned" 802.1X packets.

---

From: Nick Petroni <[email-masked]>
Date: Tue, 27 Jul 2004 11:13:29 -0400 (EDT)

> our discussion of whether "canned" EAP Failure is illegal also applies to
Ok, this was the source of my confusion. I guess I assumed that since they
were in another standard they were going to be allowed for backwards
compatibility or some other legacy argument. They are, indeed, still in
the latest version, which was another source of my confusion. They are in
the 802.1X SM diagrams, not just the text.

Thanks,
nick