>>>>> "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
