Protocol Action: 'EAP Extensions for EAP Re-authentication Protocol (ERP)' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce