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.
IETF · 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.
{
"id": "RFC6697",
"number": 6697,
"title_en": "Handover Keying (HOKEY) Architecture Design",
"title_ru": "",
"summary_ru": "",
"purpose_ru": "",
"use_ru": "",
"full_translation_path": "",
"full_translation_checked_at": "",
"full_translation_source_sha256": "",
"architect_note_ru": "",
"topics_ru": [],
"translation_state": "not_prepared",
"verification_level": "not_prepared",
"verification_level_ru": "Русская выжимка не подготовлена",
"verification_note_ru": "",
"abstract_en": "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.",
"authors": [
"G. Zorn",
"Q. Wu",
"T. Taylor",
"Y. Nir",
"K. Hoeper",
"S. Decugis"
],
"organizations": [],
"publication_date": "2012-07-01",
"current_status": "INFORMATIONAL",
"current_status_ru": "Информационный",
"publication_status": "INFORMATIONAL",
"publication_status_ru": "Информационный",
"lifecycle": "informational",
"lifecycle_ru": "Справочный",
"stream": "IETF",
"stream_ru": "IETF",
"area": "sec",
"area_ru": "Безопасность",
"working_group": "hokey",
"source_draft": "draft-ietf-hokey-arch-design-11",
"page_count": 20,
"doi": "10.17487/RFC6697",
"keywords": [
"Handover Keying Architecture",
"Re-authentication",
"Early authentication"
],
"formats": [
"TXT",
"HTML"
],
"relations": {
"obsoletes": [],
"obsoleted_by": [],
"updates": [],
"updated_by": [],
"is_also": [],
"see_also": []
},
"links": {
"info": "https://www.rfc-editor.org/info/rfc6697/",
"html": "https://www.rfc-editor.org/rfc/rfc6697.html",
"txt": "https://www.rfc-editor.org/rfc/rfc6697.txt",
"datatracker": "https://datatracker.ietf.org/doc/rfc6697/"
}
}