[secdir] [New-work] WG Review: Recharter of Handover Keying (hokey)
IESG Secretary <iesg-secretary@ietf.org> Tue, 27 October 2009 21:00 UTC
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC993A6914 for <secdir@core3.amsl.com>; Tue, 27 Oct 2009 14:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 60ZlhwjYkBMr for <secdir@core3.amsl.com>; Tue, 27 Oct 2009 14:00:28 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8D3C828C108 for <secdir@ietf.org>; Tue, 27 Oct 2009 14:00:26 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n9RL0fkW013475 for <secdir@ietf.org>; Tue, 27 Oct 2009 17:00:41 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n9RL0e04013467 for <secdir@PCH.mit.edu>; Tue, 27 Oct 2009 17:00:40 -0400
Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n9RKns6n013174 for <secdir@mit.edu>; Tue, 27 Oct 2009 17:00:29 -0400 (EDT)
X-AuditID: 12074422-b7b60ae000006d0d-3a-4ae75f66da55
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by (Symantec Brightmail Gateway) with SMTP id CE.0D.27917.66F57EA4; Tue, 27 Oct 2009 17:00:23 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000A028C18C; Tue, 27 Oct 2009 14:00:05 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 8B4FB3A6914; Tue, 27 Oct 2009 14:00:01 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20091027210001.8B4FB3A6914@core3.amsl.com>
Date: Tue, 27 Oct 2009 14:00:01 -0700
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
X-Brightmail-Tracker: AAAAARFf+IA=
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
X-Mailman-Approved-At: Tue, 27 Oct 2009 23:36:20 -0700
Subject: [secdir] [New-work] WG Review: Recharter of Handover Keying (hokey)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2009 21:00:29 -0000
A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn <gwz@net-zen.net> Tina Tsou (Ting ZOU) <tena@huawei.com> Security Area Director(s): Tim Polk <tim.polk@nist.gov> Pasi Eronen <pasi.eronen@nokia.com> Security Area Advisor: Tim Polk <tim.polk@nist.gov> Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: 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. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir
- [secdir] [New-work] WG Review: Recharter of Hando… IESG Secretary