Subject: [eap] Re: Issue 94: Is EAP a lock-step protocol?

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Mar 2003 05:44:03 -0800 (PST)

Is there a proposed change to the text of EAP-01 or RFC 2869bis in order
to address this issue?

---------------------------------------------------------------------------
Issue 94: EAP a lockstep protocol?
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: March 4, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html
Document: EAP-01
Comment type: Technical
Priority: 1
I know this issue has been discussed before (e.g. James Carlson's
email on January 6th [1]), but since it has come up in PANA again (and
might cause extra complexity there), I would like to see the issue
explictly clarified in 2284bis and/or 2869bis.

So, the question is: Is the Authenticator/EAP Server allowed to send a
new Request (with different Identifier and contents) before it has
received a Response to the previous outstanding Request? (that is,
is EAP "lock-step" protocol or not?)

At least it seems that 2869bis does not support this kind of behavior
(since the authentication server can send an Accept-Challenge only in
response to an Access-Request). So, even if we allow "non-lock-step
behavior" in 2284bis, perhaps it should be explicitly forbidden in
2869bis? (I don't think this is a problem, since 2869bis does not
support all EAP features anyway, like role reversal).

I don't have a strong opinion on this one: allowing such behavior
might increase complexity, but as James said, there was no such
restriction in RFC2284 (or at least so it seems).
If we get some kind of consensus on which option should be chosen
(allow non-lock-step behavior in 2284bis but prohibit it in 2869bis,
or prohibit it in both), I can try to propose some text. (Or, it
might be that the specs already say this, but I can't find it :-)

(BTW, there are some parts in 2284bis which assume lock-step behavior
and need changing if non-lock-step is allowed. For example,
Section 4.1: "In order to avoid confusion between new Requests
and retransmissions, the Identifier value chosen for each new Request
need only be different from the previous Request, but need not be
unique within the conversation.")

Best regards,
Pasi