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
