Yes. On Mar 11, 2013, at 9:35 PM, Leif Johansson wrote:
> On 03/11/2013 08:12 PM, Alper Yegin wrote: >> Here you go: > So this replaces all of 2.1 (just to be clear) ? >> 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 > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
