Subject: [eap] Re: RFC 2284bis issue

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Mar 2003 04:38:24 -0800 (PST)

The text that is proposed to be changed does not actually exist within RFC
2284bis-01. Please revise this issue and resubmit.

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