{"draft":"draft-ietf-hokey-arch-design-11","doc_id":"RFC6697","title":"Handover Keying (HOKEY) Architecture Design","authors":["G. Zorn, Ed.","Q. Wu","T. Taylor","Y. Nir","K. Hoeper","S. Decugis"],"format":["ASCII","HTML"],"page_count":"20","pub_status":"INFORMATIONAL","status":"INFORMATIONAL","source":"Handover Keying","abstract":"The Handover Keying (HOKEY) Working Group seeks to minimize handover\r\ndelay due to authentication when a peer moves from one point of\r\nattachment to another.  Work has progressed on two different\r\napproaches to reduce handover delay: early authentication (so that\r\nauthentication does not need to be performed during handover), and\r\nreuse of cryptographic material generated during an initial\r\nauthentication to save time during re-authentication.  A basic\r\nassumption is that the mobile host or \"peer\" is initially\r\nauthenticated using the Extensible Authentication Protocol (EAP),\r\nexecuted between the peer and an EAP server as defined in RFC 3748.\r\n\r\nThis document defines the HOKEY architecture.  Specifically, it\r\ndescribes design objectives, the functional environment within which\r\nhandover keying operates, the functions to be performed by the HOKEY\r\narchitecture itself, and the assignment of those functions to\r\narchitectural components.  It goes on to illustrate the operation of\r\nthe architecture within various deployment scenarios that are\r\ndescribed more fully in other documents produced by the HOKEY Working\r\nGroup.  This document is not an Internet Standards Track specification;\r\nit is published for informational purposes.","pub_date":"July 2012","keywords":["Handover Keying Architecture","Re-authentication","Early authentication"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC6697","errata_url":null}