On 03/12/2013 01:04 PM, Alper Yegin wrote: > Yes. > So at this point I want to hear from others in the WG about this proposed change.
> 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] >>>> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/abfab >
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
