RFC 6697: Handover Keying (HOKEY) Architecture Design
In plain English — editorial summary, not part of the RFC
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748. This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.
Document record
- Document ID
- RFC6697
- Published
- July 2012
- Authors
- G. Zorn; Q. Wu; T. Taylor; Y. Nir; K. Hoeper; S. Decugis
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- sec
- Pages
- 20
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6440The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 OptionCurrent
December 2011
- RFC 6698The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSAUpdated
August 2012
- RFC 6696EAP Extensions for the EAP Re-authentication Protocol (ERP)Current
July 2012
- RFC 6685Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML RegistryObsoleted
July 2012
- RFC 6684Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)Current
July 2012
- RFC 6712Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)Obsoleted
September 2012
- RFC 6680Generic Security Service Application Programming Interface (GSS-API) Naming ExtensionsCurrent
August 2012
- RFC 6678Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) MethodCurrent
July 2012
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?