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
