Re: [HOKEY] Last Call: <draft-ietf-hokey-arch-design-08.txt> (Handover Keying (HOKEY) Architecture Design) to Informational RFC

Stephen Farrell <> Thu, 17 November 2011 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBAFD21F8FBE for <>; Wed, 16 Nov 2011 16:01:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a7JuRZPJW-7W for <>; Wed, 16 Nov 2011 16:01:52 -0800 (PST)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 649F421F8FEC for <>; Wed, 16 Nov 2011 16:01:52 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9442171CCF for <>; Thu, 17 Nov 2011 00:01:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1321488110; bh=PU+lBrtmu2M4+Q S7ZeBX4AydnLD7PnkuCcgj1em2C7A=; b=6VGtlA8vQ2UojgvcIRe+R28YM70jR5 PaZLGTt7nxvzaL1L8WvMgmLsD2DCIF+DGM7Vgq4KiX4p4ajrJhJolOF8I/E00N3F X0zCNh+w0+SvP8rF7MZ5QiW4kNHmcjQRAff3jXzfsgmb37myUQ4Nha8GUDmxOIYL mcov6JO22IGbuha2kJTqwgjG3ot2naxY1evFYQGx14RRYPL9/VS/uPU7EweetySM tAi/ssSC3UCHIOikLCLfkxDxa78GHFq/W3xEGXHzzSjn3rvRIcG0qbGzSe8/Pudm ma0/pQCyePNhO5ozXyjYHwBHdyBX7xRE3RLNHEdkZOdQ6hVstF5qwDzw==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id S0M46W+y0PcY for <>; Thu, 17 Nov 2011 00:01:50 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id EE0CB171C1A for <>; Thu, 17 Nov 2011 00:01:49 +0000 (GMT)
Message-ID: <>
Date: Thu, 17 Nov 2011 00:01:47 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [HOKEY] Last Call: <draft-ietf-hokey-arch-design-08.txt> (Handover Keying (HOKEY) Architecture Design) to Informational RFC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Nov 2011 00:01:57 -0000


IETF last call on this is done. Were there any changes
resulting? I didn't see any.

Are there any further changes to be made? I can't
recall any but this was a last-minute-before-the-
cutoff submission so there might be.

There was also a secdir review [1] with a nit. Fix that
or not as you choose.

Once you confirm no more changes are needed to me I'll
put it on a telechat agenda,



On 11/02/2011 03:56 PM, The IESG wrote:
> The IESG has received a request from the Handover Keying WG (hokey) to
> consider the following document:
> - 'Handover Keying (HOKEY) Architecture Design'
>    <draft-ietf-hokey-arch-design-08.txt>  as an Informational RFC
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2011-11-16. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>     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.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> HOKEY mailing list