Hi Sam, Please also share this discussion with EAP WG and EMU WG mailing lists. That's where the EAP expertise is and they should chime in, given that you are proposing to modify EAP applicability statement.
Alper On Oct 19, 2012, at 4:41 PM, Sam Hartman wrote: > > Second issue relates to EAP requirements surrounding server-initiated > re-authentication. We've had one claim that EAP lower layers MUST > support re-authentication initiated by the server. > > If that's true, we have kind of a big problem with GSS-EAP. > > As best I can tell though that's not true. RFC 3748 doesn't really talk > about server-initiated re-authentication. The RADIUS EAP support > doesn't seem to support it, and the COA informational RFC explicitly > says it cannot be used for re-authentication. The Diameter EAP > application says that if the lower layer supports EAP re-authentication > then the Diameter NAS MUST support re-authentication as well. > I have looked up citations for the above in a PCP discussion and am > happy to dig that all up if they would help anyone here. > > As best I can tell, the motivation for re-authentication is an > interesting different between network access and application > authentication. In network access, there is a significant disruption if > your connection drops and you have to re-authenticate before you can > send your next packet. > It's strongly desirable to re-authenticate before your lifetime expires. > (This doesn't speak to server-initiated re-auth, I realize) > > Some applications work like that. > However there are a lot of applications where the server can close the > connection and when the client wants to do the next thing, it will > re-authenticate at that time. > For example with SMTP, it's not going to be a big deal if the next time > I want to send mail it takes a bit longer because my server has closed a > connection to force me to reauthenticate. > > My recommendation is that the applicability statement should discuss > the issue of re-authentication. We should recommend that applications > that will be disrupted by authentication expiration have a mechanism > to re-authenticate while the existing authentication is still live. > > I think we need to say very little about server-initiated > re-authentication. I think we should say that applications MAY support > server-initiated re-authentication. If they do, then the server can send > authentication packets at any time. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
