Here you go: 2.1 Retransmission
In EAP, the authenticator is responsible for retransmission. By default EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be able to receive and process EAP messages at any time during the authentication conversation. Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach. When retransmission is exclusively handled by the client-side EAP lower-layer, an EAP message that gets silently discarded by the EAP method may stall the EAP lower-layer state machine. In such a case, applications MUST handle discarded EAP messages. The specific way in which discarded messages will be handled depend on the characteristics of the application. Solution options include, but are not limited to, failing the authentication at the application level, and requesting an EAP retransmit and waiting for additional EAP input. Both of these options require the EAP methods to notify the EAP and/or EAP lower-layer when an EAP message is discarded. Specifications of how EAP is used for application authentication MUST document how retransmission are handled. If the retransmissions are exclusively handled by the client-side EAP lower-layer, then the specifications MUST also document how message discards are handled. Alper On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote: > > > 9 mar 2013 kl. 09:09 skrev Alper Yegin <[email protected]>: > >> Hi Leif, >> >> >>> >>> >>>> >>>> This "MUST" cannot be implemented. It's not clear what an implementor >>>> "must" be doing to comply. >>>> This is merely telling us "there's a problem, you MUST deal with it". >>>> This reads more like recognition of an issue, rather than a solution. >>> >>> I' going to weigh in (as an individual) on this point. >>> >>> There is (imo) nothing inherently problematic about calling out a problem >>> that needs to be addressed in another specification, especially when >>> writing an applicability statement. >>> >> >> I read the text again, and let me recap it here: >> > Alternatively, EAP permits a lower layer to set the retransmission timer >> > to infinite. When this happens, the lower layer becomes responsible for >> > reliable delivery of EAP messages. Applications that use a lock-step or >> > client-driven authentication protocol might benefit from this approach. >> > >> > In addition to retransmission behavior applications need to deal with >> > discarded EAP messages. For example, whenever some EAP methods receive >> > erroneous >> > input, these methods discard the input rather than generating an error >> > response. If the erroneous input was generated by an attacker, >> > legitimate input can sometimes be received after the erroneous >> > input. Applications MUST handle discarded EAP messages, >> > although the specific way in which discarded messages will be handled >> > depend on the characteristics of the application. Options include >> > failing the authentication at the application level, requesting an EAP >> > retransmit and waiting for additional EAP input. >> >> This text implies there is a problem, but it does not define what the >> problem is. >> Or under what circumstances that problem arises. >> >> The issue is very specific to the case where the EAP lower layer is in >> charge of rexmits, and the rexmits are solely client-side driven. >> It does not apply to any other case. >> And if the EAP stack (the combination of EAP method, EAP layer, and EAP >> lower layer) does not handle this case in a special way, then the state >> machines may stall. >> >> None of that can be understood from the above text at all. >> >> Once the readers understand the issue, then they can proceed to "dealing >> with it". >> >> As for the suggested solutions, failing the authentication reduces the >> resiliency of EAP solutions. >> The other option requires an API between EAP method and EAP lower-layer. >> >> OK, maybe we don't care about the analysis of the solutions, but we do care >> about defining what the problem is. >> >> And also, this issue is not really an "applicability statement" matter. This >> is a "requirement on EAP lower layer (which is based on strictly >> client-driven rexmits)" matter, IMHO. >> >> (I understand some people might want to get done with this, but if we don't >> do it properly I'm afraid it'd open more problems than it solves for people >> down the road). >> >> >> Alper >> >> > > Why don't you propose text! > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> Cheers Leif >>> >>> >> >> _______________________________________________ >> abfab mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
