Re: [HOKEY] First draft of new hokey charter

[liu dapeng <maxpassion at gmail.com>]

2009/8/23, Glen Zorn <gwz at net-zen.net>:
> Comment, please!
>
>
> Description of Working Group:
>
> A mobile device has to re-authenticate each time it changes its point of
> attachment to the network. When it goes through the full procedure of
> authentication it creates a series of ruptures, during which the medium
> cannot flow. This results in a poor user experience during handover.
> However, it is possible to shorten the time it takes to re-authenticate by
> reusing the key information developed during the initial authentication.
>
> The Handover Keying Working Group is concerned with developing procedures
> for key reuse and delivery, while respecting good security practice. The
> Handover Keying Working Group has already done work on this subject, but it
> has not yet developed the complete set of procedures, protocols, and changes
> needed for different security environment scenarios and situations.
>
> The solutions specified by the HOKEY WG fall into several categories, based
> on timing and mechanism.
> The authentication and key management may occur before handoff, when latency
> is much less critical.
> Alternatively, authentication and key management can occur as part of the
> handoff, where latency is critical.  Solutions should reduce or eliminate
> the number of referrals to AAA servers, and solutions should avoid
> re-executing lengthy EAP method exchanges. This may be accomplished by
> providing new mechanisms for cryptographic keying material in combination
> with a protocol for the timely delivery of appropriate keys to the
> appropriate entities.  Solutions are expected to include "handover keying,"
> "low-latency re-authentication," and "pre-authentication" or "early
> authentication".
>
> All solution categories are useful, each supporting different scenarios.
> The HOKEY WG may provide multiple solutions, each addressing a different
> scenario.
>
> Solutions specified by the HOKEY WG must:
>
> 1) Be responsive to handover and re-authentication latency performance
> objectives within a mobile wireless access network.
>
> 2) Fulfill the requirements in RFC 4962 and RFC 5247.
>
> 3) Be independent of the access-technology.  Any key hierarchy topology or
> protocol defined must be independent of EAP lower layers. The protocols may
> require additional support from the EAP lower layers that use it.
>
> 4) Accommodate inter-technology heterogeneous handover and roaming.
>
> 5) Not require changes to EAP methods.  Any extensions defined to EAP must
> not cause changes to existing EAP methods.
>
> In specifying an access-technology-independent solution, media independent
> guidelines for SDOs may also be needed to explain how the keying material
> and signaling can be employed in a specific access technology.
>
> HOKEY WG Deliverables
> =====================
>
> 1) A specification of Local Domain Name Discovery for ERP. Currently the use
> of DHCP mechanisms to request the local domain name is unspecified. There
> are other useful scenarios that need to be addressed. Lower layer
> announcement for local domain name is unspecified. Ambiguity with using
> initial full EAP exchange for re-authentication needs to be clarified.
> Additional re-authentication scenarios, for which there is interest, need to
> be addressed.
>
> 2) A specification of Early Authentication solutions.  These include use of
> EAP to pre-establish authenticated keying material on a target authenticator
> prior to arrival of the peer.
>
> 3) A specification for a Hokey architecture Document. It includes deployment
> of ERP and EAP early authentication protocol in the mobile environment.
> There are various useful scenarios that need to be addressed.
>
> 4) Assistance to the 802.21a group in specifying the integration of EAP
> pre-authentication with IEEE 802.21. The Hokey Working Group shall perform
> tasks that are complementary to and do not duplicate work being done in IEEE
> 802.21a.

I am wondering what is exactly is the complementary work to 802.21? thanks.

BR,
Dapeng Liu

> 6) A specification for NAS-Authenticator interaction. NAS interaction can be
> used to release resources in the old NAS and achieve faster initiation of
> authentication. Related work in external SDOs on authenticator/NAS
> interaction for re-authentication may be taken into consideration.
>
> 7) A revision of RFC 5296 to eliminate unnecessary references to the home
> server.
>
> 8) Assistance to the radext and dime Working Groups in developing AAA
> support for handoff keying.
>
> Goals and Milestones:
> Nov 2009 First draft on Local Domain Name Discovery for ERP
> Nov 2009 First draft on Early Authentication solutions
> Mar 2010 First draft on Hokey architecture
> Mar 2010 First draft on NAS-Authenticator Interaction
> Jul 2010 First draft on revision of RFC 5296
> Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG
> Mar 2011 Submit the Early Authentication solutions draft to IESG
> Jul 2011 Submit the Hokey architecture draft to IESG
> Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG
> Nov 2011 Submit the revision of RFC 5296 to IESG
> Mar 2012 Re-charter or shut down WG
>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY at ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>