Subject: [eap] rfc2284bis issue

From: [email-masked] (John Vollbrecht)
Date: Tue, 04 Mar 2003 18:28:12 -0500

Description of issue
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: 3/4/03
Document: Document Requiring change RFC2284bis
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:Peer Continuing after NAK to unexpected REQ
Length description of problem
As described in the current draft, the Authenticator can send a Request for 
a new method type before completing the current method.  As described, the 
peer would then NAK the Request with the data field containing the current 
type.

while I thought this might work at one time, I am now convinced that this 
would be a bad idea for the following reasons:
1. sending a new REQ in the middle of a method seems like it would be an 
attempt to "negotiate" after seeing how the method is going - seems like 
bad security practice.
2. if the peer and authenticator don't understand how to do a method in the 
same way, then probably this should just fail.  It is badly implemented or 
badly designed.
3. if the intent is to avoid a DOS attack the better way would be to have 
the peer silently discard the unexpected Req rather than NAK it.  The 
unexpected Request is treated as an invalid message, which it is.  this is 
the way the current state machine treats it.
4. if the intent is to allow parallel methods to operate, this doesn't do 
it.

Requested change:
Proposal

change:
   If the
   authenticator sends a message of a different Type prior to completion
   of the final round of a given method the peer SHOULD silently discard
   such a Request.  Otherwise it MAY send a Response with the same Type as
   the Request.  Since an EAP packet with a different Type may be sent
   by an attacker, an authenticator receiving a Nak including a
   preference for the Type in progress SHOULD log the event, but
   otherwise not take any action.

to:

   If the authenticator sends a message of a different Type prior to
   completion of the final round of a given method the peer SHOULD silently
   discard the Request.  Since an EAP packet with a different Type may be
   sent by an attacker, this behaviour will allow the peer to continue if
   the authenticator sends additional Request for the current type.  If it
   does not receive a request for the current type it will time out and the
   EAP conversation will fail.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 06:42:02 -0800 (PST)

> This would create a very simple state machine (MUCH simpler than
> the current one, which has to work with multiple methods).
> The client state machine could look something like this (ignoring
> retransmissions):

This sounds interesting. Why don't you go ahead and write it up. Do you
want time on the IETF 56 agenda to talk about this?

---

From: [email-masked] ([email-masked])
Date: Wed, 12 Mar 2003 21:06:52 +0200

(Yes, I know that replying to my own message is not=20
a good habit :-)

Pasi Eronen wrote:

> The semantic issue is the following: In UML you can put
> procedures inside states or in transitions (I used only the
> latter), but they have different semantics. Procedures in
> transitions are called "actions", and they are completed before
> the transition has completely happened and next event is
> processed. Procedures inside states are called "activities":
> they start executing when the state is entered, but it is
> possible that new events arrive while the activity is
> running. If this results in leaving the state, the activity=20
> is aborted.
>=20
> Quite obviously, the state machine will be much simpler to
> understand if we use only actions, and indeed, the procedures
> in 802 notation are actions in this sense. (The only possible
> candidate for an activity is the processing of EAP request for
> method; it might require user interaction.)

I just remembered, there is some text in 2284bis that sort of
assumes that the processing of EAP request by method (or
at least a part of it) is an "activity", not an "action":

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

The good thing is that the activity is not actually interrupted,
so we can work around it even in an 802-style state diagram=20
(e.g. check if any duplicates were received after the EAP method
has finished processing the request, but before the response
is sent). The current state machine doesn't do this, though.

Best regards,=20
Pasi