Technical Summary
The current Extensible Authentication Protocol (EAP) keying framework is
not designed to support re-authentication and handovers. This is often
the cause of unacceptable latency in various delay-sensitive
environments (such as mobile wireless networks). The HOKEY Working
Group plans to address these problems by designing a generic mechanism
to reuse derived EAP keying material for handover. This document
describes the EAP Extensions necessary to implement fast
re-authentication.
Working Group Summary
This document is a product of the hokey working group, and represents the
rough consensus of that group.
Protocol Quality
This document has been reviewed extensively and the Document Shepherd
(Charles Clancy) believes it to be of high quality. This document was
reviewed for the IESG by Tim Polk.
Note to RFC Editor
Please make the following substitution in Section 6.
Old:
Our analysis indicates that some EAP implementations are not RFC 3748
compliant in that instead of silently dropping EAP packets with code
values higher than 4, they may consider it an error. Furthermore, it
may not be easy to upgrade all the peers in some cases. In such
cases, authenticators may be configured to not send EAP-Initiate/
Re-auth-Start; peers may learn whether an authenticator supports ERP
via configuration, from advertisements at the lower layer.
In order to accommodate implementations that are not compliant to
RFC3748, such lower layers need to ensure that both parties support
ERP; this is trivial for an instance when using a lower layer that is
known to always support ERP; otherwise, it can be negotiated.
New:
Our analysis indicates that some EAP implementations are not RFC 3748
compliant in that instead of silently dropping EAP packets with code
values higher than 4, they may consider it an error. To accommodate
such non-compliant EAP implementations, additional guidance has been
provided below. Furthermore, it may not be easy to upgrade all the
peers in some cases. In such cases, authenticators may be configured
to not send EAP-Initiate/Re-auth-Start; peers may learn whether an
authenticator supports ERP via configuration, from advertisements at
the lower layer.
In order to accommodate implementations that are not compliant to
RFC3748, such lower layers SHOULD ensure that both parties support
ERP; this is trivial for an instance when using a lower layer that is
known to always support ERP. For lower layers where ERP support is
not guaranteed, ERP support may be indicated through signaling (e.g.,
piggy-backed on a beacon) or through negotiation. Alternatively,
clients may recognize environments where ERP is available based on
pre-configuration. Other similar mechanisms may also be used. When
ERP cannot be verified, lower layers may mandate falling back to full
EAP authentication to accommodate EAP implementations that are not
compliant to RFC 3748.