Subject: [eap] issue 139 (Response to duplicate requests)

From: [email-masked] (Jari Arkko)
Date: Wed, 28 May 2003 16:57:46 +0300

Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20139

I agree that there's some confusion in the documents regarding this.

The bad thing we wish to prevent from happening is a retransmission
causing the user input to be asked for the second time. Or a
cryptographic calculation (e.g. random generation) be run
with different results.

Currently, 2284bis says that if you get a request while you
are processing the old one, ignore the new request. The state
machine simply processes the request again, and sends a copy
of the previous input. The basic reason for this is that the
when we are in some state, we do not suddenly jump to process
the next input request just because one arrived.

This leads me to think that 2284 might be best fixed by
replacing the following text:

   If a peer receives a valid duplicate Request for which it has
   already sent a Response, it MUST resend its original Response.  If
   a peer receives a duplicate Request before it has sent a Response,
   but after it has determined the initial Request to be valid (i.e.,
   it is waiting for user input), it MUST silently discard the
   duplicate Request.  An EAP message may be found invalid for a
   variety of reasons: failed lower layer CRC or checksum, malformed
   EAP packet, EAP method MIC failure, etc.

with this:

   If a peer receives a valid duplicate Request for which it has
   already sent a Response, it MUST resend its original Response.
   Received Requests SHOULD NOT be processed before the previously
   received Request has been processed.

(And perhaps the reasons for invalid EAP messages can find some
other location in the document? If they are necessary, that is.)

Note that the proposed text above ignores possibility that
a lengthy operation, such as user input or smart card communication,
could be interrupted by something coming from the authenticator.
Do we have anything that could do this? Failure? Would it be
important to handle that? If we make the state machine handle
events from both sides (network and user/smart card) it would
become complicated. So I would like to avoid that if possible.

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 28 May 2003 06:50:03 -0700 (PDT)

>    received Request has been processed.

Perhaps we need to clarify the first sentence by adding "without
additional user interaction".  In the second sentence, are we saying that
packets are processed in the order that they are received? I think so.

> other location in the document? If they are necessary, that is.)

I think at some point we need to state what checks are made by what
entities. But perhaps that is a separate issue.

> important to handle that?

We've said that we don't send Failure as the result of a timeout. It is
certainly possible that the user could take so long that the authenticator
might have given up -- but that wouldn't constitute an interruption. So I
think it is fine to process packets in the order they are received, with
no interrupts.

> If we make the state machine handle

I agree.

---

From: [email-masked] (Jari Arkko)
Date: Wed, 28 May 2003 23:14:03 +0300

> packets are processed in the order that they are received? I think so.

IMHO the first sentence is enough without an addition, but
if you want to add one, maybe "without re-processing the request"?
As to the second sentence, yes, this implies also that requests
are processed in order. (The main point was though to prevent
"interrupting" the current request, no matter what.)
Will this be a problem? I don't think so...

> think it is fine to process packets in the order they are received, with

Good, this makes things simple.

--Jari