I would be against this replacement. The application and the lower-layer may not be the same thing for a number of reasons. Looking specifically at the GSS-EAP case, the lower layer consists of both RADIUS and GSS-API. Neither of these is really the application layer. If EAP is directly built into the application, then yes the application and the lower layer are going to be the same. If there is some type of wrapper that is going on in the middle, such as using GSS-API, then they are no longer the same. The application becomes one layer lower than the lower-layer.
If you look at RADIUS, RADIUS is the lower-layer independent of transport that RADIUS is operating on top of. It does not mapper if you are doing RADIUS over UDP, DTLS or TLS/IP, RADIUS is the lower-layer. At some point you say everything below this point is below the lower-layer. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Yoshihiro Ohba > Sent: Thursday, November 15, 2012 11:58 AM > To: [email protected] > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Sam, > > The provided text looks good, except that the text is generally > applicable to any EAP lower-layer inclucing applications. Said that my > suggestion is to replace "application" with "lower-layer". > > Thanks, > Yoshihiro Ohba > > > (2012/11/15 4:37), Sam Hartman wrote: > > 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 > > 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. Options include failing the > > authentication at the application level and waiting for additional EAP > > input, possibly after an EAP retransmit. > > > > 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
