The IESG has approved the following document: - 'EAP Extensions for EAP Re-authentication Protocol (ERP) ' <draft-ietf-hokey-erx-14.txt> as a Proposed Standard This document is the product of the Handover Keying Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-14.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
