> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Alper Yegin > Sent: Friday, November 16, 2012 1:56 PM > To: Sam Hartman > Cc: [email protected] > Subject: Re: [abfab] Retransmission Text for EAP applicability > > > > > > 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 > > process EAP messages at any time during the authentication conversation. > > > > Alternatively, EAP permits a lower layer to set the retransmission > > timer to infinite. In this case, the lower layer is 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. Whenever some EAP methods receive > erroneous > > Discarding may be done at the EAP layer or the EAP method layer. I think we > need to cover for both.
It is true that the EAP upper lay can discard messages as well, however I am not sure that the text is going to be clearer by stating so. However I think the following change should address your concern s/Whenever/For example, whenever/ > > > 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. 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. > > > 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. 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. > > 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. > > 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
