Furthermore, as we discussed in PCP WG there's another problem. Sam is proposing to decouple EAP security association management from the application state. More specifically, even after the EAP session is release/timed out, application may still be in use. What that means is, if the server has an application message that is pending to be transmitted to the client, and if at that time there's no security association available (see above), then the server needs to initiate re-authentication in order to re-generate a security association and send the app message securely.
In PCP WG meeting Sam claimed he can design a solution to this problem, and committed to sending a straw man solution. I just want to make ABFAB people aware of this issue, and indicate that we are looking forward to seeing Sam's solution proposal. Cheers, Alper On Oct 24, 2012, at 10:14 AM, Yoshihiro Ohba wrote: > RFC 5247 discusses EAP re-authentication in several sections. > > Here is one part: > > " > Where TSKs are derived from or are wrapped by exported EAP keying > material, compromise of that exported EAP keying material implies > compromise of TSKs. Therefore, if EAP keying material is considered > stale, not only SHOULD EAP re-authentication be initiated, but also > replacement of child keys, including TSKs. > " > > Since EAP keying material can be considered stale by either peer or > authenticator, it makes sense to support both peer-initiated and > authenticator-initiated re-authentication. If an application protocol has a > design restriction that prevents from suppporting authenticator-initiated > re-authentication, then it is better to let each application specification > have some text in their Security Considerations section to assess potential > impact on the application due to lack of the functionality. > > Having said that I don't agree with having text like "applications MAY > support server-initiated re-authentication" in EAP applicability statement. > What we sould have in EAP applicability statement is that the key management > framework described in RFC 5247 is applicable to both network access and > application usage of EAP. > > Regards, > Yoshihiro Ohba > > > (2012/10/19 22:41), 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
