Subject: [eap] Two more issues from the state machine

From: Florent Bersani <[email-masked]>
Date: Fri, 25 Jun 2004 19:13:52 +0200

Cut and paste from a lenghty mail 
(http://mail.frascone.com/pipermail/public/eap/2004-June/002553.html):

Issue #TBC

Submitter name: Florent Bersani

Submitter email address: [email-masked]

Date first submitted: 06/25/2004

Document: Document Requiring change State Machine

Comment type: E

Priority: '1' Should fix

Rationale/Explanation of issue:
allowMethod is not defined in the document IINM but is used in figure 3

Requested change: define it

Issue #TBC+1

Submitter name: Florent Bersani

Submitter email address: [email-masked]

Date first submitted: 06/25/2004

Document: Document Requiring change State Machine

Comment type: T

Priority: '1' Should fix

Rationale/Explanation of issue:

I did not find a place in RFC 3748 saying that it is forbidden to have 
multiple round trips of the Identity method.

If this is the case, the state machine reflects this... sadly, this 
leads to an unnecessary (& stupid & not dramatic) DoS attack: the 
attacker keeps sending EAP Identity request and the peer may keep 
replying to these requests (and discarding the valid requests of the 
server).

I thought about this when talking about the methodstate variable and 
noticing that there was a difference between Identity/Notification 
(which are from a theoretical POV two methods) and the other methods. 
Namely, while the identity and notification methods do not impact the 
methodstate variable nor the decision one...

Reply by Nick :

I don't see the RFC as denying the use of immediate failure. The 
behavior is valid IMHO.  

My reply

To be honest, I started the mail you replied to by lamenting that this 
was not mandated by EAP (which you tend to think) but after rereading 
RFC 3748 (I stumbled across some wording like "The EAP authentication 
exchange proceeds as follows: [1] The authenticator sends a Request to 
authenticate the peer." RFC 3748 page 7).

So, although it didn't seem like very normative text, I changed my mind 
and now think that EAP mandates that a dialog begins with a request.

I'd really like others' opinion on this, Bernard, Jari?

An addition to my reply

Another example of RFC 3748 text that made me change my mind and think a 
valid EAP authenticator *cannot* start with a success or a failure is 
located  page  23 section 4.2 "The Success packet is sent by the 
authenticator to the peer after completion of an EAP authentication 
method" - since this applies only to success, would it mean that 
although it is not allowed to start with success, one can start with 
failure?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap