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] https://www.ietf.org/mailman/listinfo/abfab
