Sam, I recommend starting from identifying what aspects of "applications" are different from "network access", and how such differences play into EAP.
Below you are talking about one such difference. (In that, in my understanding, you are OK with server initiated re-auth for network access, but you think this is not needed for applications. What is the root cause of this difference? ) There may be other differences. Alper On Oct 24, 2012, at 1:35 PM, Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba <[email protected]> writes: > > Yoshihiro> RFC 5247 discusses EAP re-authentication in several > Yoshihiro> sections. Here is one part: > > Yoshihiro> " Where TSKs are derived from or are wrapped by exported > Yoshihiro> EAP keying material, compromise of that exported EAP > Yoshihiro> keying material implies compromise of TSKs. Therefore, > Yoshihiro> if EAP keying material is considered stale, not only > Yoshihiro> SHOULD EAP re-authentication be initiated, but also > Yoshihiro> replacement of child keys, including TSKs. " > > Yoshihiro> Since EAP keying material can be considered stale by > Yoshihiro> either peer or authenticator, it makes sense to support > Yoshihiro> both peer-initiated and authenticator-initiated > Yoshihiro> re-authentication. If an application protocol has a > Yoshihiro> design restriction that prevents from suppporting > Yoshihiro> authenticator-initiated re-authentication, then it is > Yoshihiro> better to let each application specification have some > Yoshihiro> text in their Security Considerations section to assess > Yoshihiro> potential impact on the application due to lack of the > Yoshihiro> functionality. > > A few points. > > First, I agree with you that stale keying is an important thing to > consider when integrating EAP into an application. > So, I think we should make sure applications have the advice they need > with regard to this topic. > > I also agree with you that the keying framework applies. > > However, we disagree about the need to discuss application-specific > issues. > Here are some things to consider: > > 1) If your application uses TLS for confidentiality and integrity, say > because it uses EAP with the eap-aes128 SASL mechanism, then compromise > of the MSK does not affect traffic keys for your application. If the > MSK was compromised at time of generation--say because a long-term > password was compromised--then your entire authentication is > compromised. > If on the other hand the MSK is compromised after authentication, no > harm appears to be done in this case. > > 2) The EAP keying framework is written in the context of network > access. In that context, shutting down a session in response to needing > to re-key is a disruptive event. However, for something like SMTP, it > seems entirely reasonable to just take down the session, which the > server can do at an appropriate sequence point. If the client still > wants to talk it will reconnect. There are actually a number of > applications that work this way. > > 3) As you point out, if an application doesn't have a way to respond to > key compromise, there are likely to be security considerations. > One thing applicability statements often do is point out security issues > people should consider when applying a technology. > > Especially where application use differs from network access use, we > should document that sort of thing. > > Various aspects of the "detailed security analysis" provided by RFC 5247 > are different, or the common assumptions are different for applications > rather than network access. > This is why you can't just change the one sentence in section 1.3 of RFC > 3748 and be done. > > In conclusion, thanks for pointing out the really interesting issue of > key compromise. We'll want to handle that. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
