>>> 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 an EAP method discarding a message, although >>> the specific way in which discarded messages will be handled depend on >>> the characteristics of the application. >> >> Now, saying "MUST handle" and then leaving the way it's handled out-of >> scope does not make sense. > > I think this makes perfect sense. We have just said that how it is going to > happen - in fact what the correct response to happen - is going to be based > on the specific application we are discussing. This means that we can't say > what it should do. >
Why would the application care what happens when an EAP-layer or EAP method-layer message is discarded? If an EAP-layer message is discarded, it's for the EAP-layer to deal with that. If an EAP method-layer message is discarded, it's for the EAP method layer to deal with that. If you are designing a protocol that needs to deal with what happens at 1 or 2 layers above, then I'd say there's an issue with this design. This is like saying, if HTTP discards a packet, then IP MUST handle this. > Some applications will assume transmission error and send the fact that the > EAP packet was not processed. (I kind of expect TEAP to do this behavior). > > Some applications will treat it as an Access-Fail and kill the whole > process. > > We cannot dictate what the correct behavior should be. > Because, that's not the business of this layer. Having a MUST w/o a clear normative text and this explanation is the indication of the problem. Don't you think? >> >>> Options include >>> failing the authentication at the application level >> >> This is problematic. If the EAP method has discarded the message, now you >> need this be conveyed down the stack to the EAP lower-layer. This does not >> happen today. And enforcing that requires changing existing EAP methods, >> creating additional requirement on future methods. > > If I make a call to the EAP handler, it does not say that I got an > Access-Accept or an Access-Reject, and it does not return anything for me to > send back continuing the conversation. This sounds like a pretty good clue > the packet was dropped on the floor given the lock-step behavior of EAP > itself. > Nope. Maybe the EAP method is awaiting an input from the user. The "EAP lower layer" cannot know what's going on at the EAP method layer. > I don't see any need to change either current EAP behavior or future > behavior. > >> >>> and waiting for >>> additional EAP input, possibly after an EAP retransmit. >>> >> >> Who is retransmitting here? The EAP peer? If so, we need to clarify that. > And >> also described how the EAP peer decides to retransmit, and what it really >> retransmits (the previous EAP response?). >> > > That is going to be application specific behavior. In part it is going to > depend on who dropped the message on the floor and who actually has the > ability to even try and do the resend. Without knowing your application > data flow, I cannot answer this question. > The options provided by the text is ambiguous. >> >> Is this text meant to cover how the EAP conversation can be made reliable >> with client-driven retransmissions? I see the implications of it, but not > clear >> and complete description of it. > > No. That may be one of the things that an application may define, but it is > not required in any way. I'd say if this text is meant to cover that possibility, then we need to make it very clear. Otherwise, the text is rather vague… Alper > >> >> Alper >> >> >> >>> Specifications of how EAP is used for application authentication >>> SHOULD document how retransmission and message discards are handled. >>> _______________________________________________ >>> 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
