[HOKEY] Document Action: 'Handover Key Management and Re-authentication Problem Statement' to Informational RFC
The IESG <iesg-secretary@ietf.org> Tue, 11 March 2008 12:10 UTC
Return-Path: <hokey-bounces@ietf.org>
X-Original-To: ietfarch-hokey-archive@core3.amsl.com
Delivered-To: ietfarch-hokey-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E08128C3E0; Tue, 11 Mar 2008 05:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-NEP+NZKRZc; Tue, 11 Mar 2008 05:10:53 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47AEA3A6AE2; Tue, 11 Mar 2008 05:10:52 -0700 (PDT)
X-Original-To: hokey@ietf.org
Delivered-To: hokey@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id BB1EE3A69A9; Tue, 11 Mar 2008 05:10:45 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20080311121045.BB1EE3A69A9@core3.amsl.com>
Date: Tue, 11 Mar 2008 05:10:45 -0700
Cc: hokey chair <hokey-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, hokey mailing list <hokey@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [HOKEY] Document Action: 'Handover Key Management and Re-authentication Problem Statement' to Informational RFC
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: hokey-bounces@ietf.org
Errors-To: hokey-bounces@ietf.org
The IESG has approved the following document: - 'Handover Key Management and Re-authentication Problem Statement ' <draft-ietf-hokey-reauth-ps-09.txt> as an Informational RFC This document is the product of the Handover Keying Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-09.txt Technical Summary The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers. This is often the cause of unacceptable latency in various delay-sensitive environments (such as mobile wireless networks). The HOKEY Working Group plans to address these problems by designing a generic mechanism to reuse derived EAP keying material for handover. This document describes the Handover Keying (HOKEY) problem statement. Working Group Summary This document is a product of the hokey working group, and represents rough consensus of the working group. Protocol Quality This document has been reviewed extensively and the Document Shepherd believes it to be of high quality. This document was reviewed for the IESG by Tim Polk. Note to RFC Editor Please replace Section 6.2 with the following text: 6.2. IEEE 802.11r Applicability One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in the process of specifying a fast handover mechanism. Access Points (APs) are grouped into mobility domains. Initial authentication to any AP in a mobility domain requires execution of EAP, but handover between APs within the mobility domain does not require the use of EAP. Internal to the mobility domain are sets of security associations to support key transfers between APs. In one model, relatively few devices, called R0-KHs, act as authenticators. All EAP traffic traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It then distribute cryptographically separate keys to APs in the mobility domain, as necessary, to support the client mobility. For a deployment with M designated R0-KHs and N APs, this requires M*N security associations. For small M, this approach scales reasonably. Another approach allows any AP to act as an R0-KH, necessitating a full mesh of N2 security associations, which scales poorly. The model that utilizes designated R0-KHs is architecturally similar to the fast re-authentication model proposed by HOKEY. HOKEY, however, allows for handover between authenticators. This would allow an IEEE 802.11r-enabled peer to handover from one mobility domain to another without performing an EAP authentication. _______________________________________________ HOKEY mailing list HOKEY@ietf.org https://www.ietf.org/mailman/listinfo/hokey