| Two more issues from the state machine | <– Date –> <– Thread –> |
From: Florent Bersani (florent.bersani rd.francetelecom.fr)
|
|
| Date: Fri, 25 Jun 2004 12:56:32 -0400 (EDT) | |
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: florent.bersani [at] rd.francetelecom.fr
Date first submitted: 06/25/2004
Document: Document Requiring change State Machine
Comment type: E
Priority: '1' Should fix
Requested change: define it
Issue #TBC+1
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] rd.francetelecom.fr
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?
Issue #TBC
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] rd.francetelecom.fr
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: florent.bersani [at] rd.francetelecom.fr
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?
-
Two more issues from the state machine Florent Bersani, June 25 2004
-
Re: [Issue 250] Two more issues from the state machine Nick Petroni, July 8 2004
- Re: [Issue 250] Two more issues from the state machine Florent Bersani, July 9 2004
-
Re: [Issue 250] Two more issues from the state machine Nick Petroni, July 8 2004
Results generated by Tiger Technologies using MHonArc.