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 > Cheers Leif > >
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
