Handover Keying
charter-ietf-hokey-05

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.