It is more correct to say that GSS-API gets its reliability by pushing some of it down a layer, but that is no different that RADIUS saying it can have reliable transport if it requires TLS/IP as its underlying transport.
Also the requirements that GSS-API imposes during the authentication phase are different than those during the normal application processing. For GSS-EAP it is a lock-step delivery during authentication. That is much stricter than just saying it is in-order delivery. However this does not change my opinion that application protocol that is using GSS-API is not part of the EAP lower-level. The requirements that GSS-API makes are independent of the use of EAP. Jim > -----Original Message----- > From: Yoshihiro Ohba [mailto:[email protected]] > Sent: Monday, November 19, 2012 9:33 PM > To: Jim Schaad > Cc: [email protected] > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Jim, > > In the context of EAP, GSS-EAP solely cannot be considered as EAP lower- > layer because GSS-EAP itself does not provide in-order delivery of EAP > messages. GSS-EAP requires applications to provide in-order delivery. > Therefore, GSS-EAP applications must be considered as part of EAP lower > layer. > > Yoshihiro Ohba > > (2012/11/20 13:48), Jim Schaad wrote: > > 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
