Handover Keying (hokey)
-----------------------

 Charter
 Last Modified: 2011-10-19

 Current Status: Active Working Group

 Chair(s):
     Glen Zorn  <glenzorn@gmail.com>
     Tina Tsou (Ting ZOU)  <tena@huawei.com>

 Security Area Director(s):
     Stephen Farrell  <stephen.farrell@cs.tcd.ie>
     Sean Turner  <turners@ieca.com>

 Security Area Advisor:
     Stephen Farrell  <stephen.farrell@cs.tcd.ie>

 Mailing Lists: 
     General Discussion:hokey@ietf.org
     To Subscribe:      https://www.ietf.org/mailman/listinfo/hokey
     Archive:           http://www.ietf.org/mail-archive/web/hokey/current/maillist.html

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. This
specification
and the revision of RFC5296 should be conducted in parallel.

4) Assistance to the 802.21a group in specifying the integration of EAP
pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform
tasks that are complementary to and do not duplicate work being done in IEEE
802.21a.

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:

   Done         First draft on EMSK-based Keying Hierarchy 

   Done         First draft with a problem statement on EAP re-authentication 
                and key management 

   Done         First draft on EAP Re-authentication and Handover Keying 
                Hierarchy 

   Done         First draft on EAP Re-authentication Protocol 

   Done         First draft on Protocol and Keying Hierarchy for Visited Domain 
                Handovers and Re-authentication 

   Done         Submit EMSK-based Keying Hierarchy draft to IESG 

   Done         First draft on Handover Key Distribution Protocol 

   Done         Submit the problem statement draft to IESG 

   Done         Submit EAP Re-authentication and Handover Keying Hierarchy 
                draft to IESG 

   Done         Submit EAP Re-authentication Protocol draft to IESG 

   Done         First draft on EAP Pre-authentication Specification for 
                inter-technology and inter-domain handoffs 

   Done         Submit Protocol and Keying Hierarchy for Visited Domain 
                Handovers and Re-authentication draft to IESG 

   Nov 2009       First draft on Early Authentication solutions 

   Done         First draft on Local Domain Name Discovery for ERP 

   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 NAS-Authenticator Interaction draft to IESG 

   Nov 2011       Submit the Hokey architecture draft to IESG 

   Nov 2011       Submit the revision of RFC 5296 to IESG 

   Mar 2012       Re-charter or shut down WG 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Apr 2010 Apr 2011   <draft-ietf-hokey-ldn-discovery-10.txt>
                The ERP Local Domain Name DHCPv6 Option 

Apr 2010 Oct 2011   <draft-ietf-hokey-erp-aak-06.txt>
                EAP Re-authentication Protocol Extensions for Authenticated 
                Anticipatory Keying (ERP/AAK) 

Sep 2010 Nov 2011   <draft-ietf-hokey-arch-design-09.txt>
                Handover Keying (HOKEY) Architecture Design 

Sep 2010 Nov 2011   <draft-ietf-hokey-rfc5296bis-06.txt>
                EAP Extensions for EAP Re-authentication Protocol (ERP) 

 Request For Comments:

  RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC5169 I    Mar 2008    Handover Key Management and Re-authentication Problem 
                       Statement 

RFC5295 PS   Aug 2008    Specification for the Derivation of Root Keys from an 
                       Extended Master Session Key (EMSK) 

RFC5296 PS   Aug 2008    EAP Extensions for EAP Re-authentication Protocol (ERP) 

RFC5749 PS   Mar 2010    Distribution of EAP-Based Keys for Handover and 
                       Re-Authentication 

RFC5836 I    Apr 2010    Extensible Authentication Protocol (EAP) Early 
                       Authentication Problem Statement