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
