Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[iesg-secretary@xxxxxxxx: [Hokeyp] WG Review: Handover Keying (hokey)]



External Review of the proposed HOKEY WG charter has been announced.
You may send your comments to iesg@ietf.org with cc'ing to
hokeyp@opendiameter.org by October 9th.

Since hokeyp@opendiameter.org does not allow non-subscriber posting,
here is the subscription information:

http://www.opendiameter.org/mailman/listinfo/hokeyp

[Also, please disregard my previous email that incorrectly mentioned
that ietf@ietf.org would be used for External Review of HOKEY.]

Best regards,
Yoshihiro Ohba



----- Forwarded message from IESG Secretary <iesg-secretary@ietf.org> -----

X-VirusChecked: Checked
X-Env-Sender: hokeyp-bounces@opendiameter.org
X-Msg-Ref: server-14.tower-136.messagelabs.com!1159841444!14259037!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [165.254.55.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
To: ietf-announce@ietf.org
From: IESG Secretary <iesg-secretary@ietf.org>
X-Mailman-Approved-At: Mon, 02 Oct 2006 22:03:20 -0400
Cc: hokeyp@opendiameter.org
Subject: [Hokeyp] WG Review: Handover Keying (hokey)
X-BeenThere: hokeyp@opendiameter.org
X-Mailman-Version: 2.1.6
Reply-To: iesg@ietf.org
List-Id: Handover Key and Pre-Authentication Mailing List
	<hokeyp.opendiameter.org>
List-Unsubscribe: <http://www.opendiameter.org/mailman/listinfo/hokeyp>,
	<mailto:hokeyp-request@opendiameter.org?subject=unsubscribe>
List-Archive: <http://www.opendiameter.org/pipermail/hokeyp>
List-Post: <mailto:hokeyp@opendiameter.org>
List-Help: <mailto:hokeyp-request@opendiameter.org?subject=help>
List-Subscribe: <http://www.opendiameter.org/mailman/listinfo/hokeyp>,
	<mailto:hokeyp-request@opendiameter.org?subject=subscribe>
X-UIDL: ;9["!AYJ!!eSn"!7JA"!

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following draft
charter was submitted, and is provided for informational purposes 
only.  Please send your comments to the IESG mailing list 
(iesg@ietf.org) by October 9.

+++

Handover Keying (hokey)
==========================

Current Status: Proposed Working Group

Chair(s): TBD

Security Area Director(s):
Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:
Russ Housley <housley@vigilsec.com>

Mailing List: hokeyp@opendiameter.org

Most deployments of EAP in wireless networks employ an authenticator 
in pass-through mode, usually located at the edge, coupled with a 
backend AAA/ EAP server. Many EAP methods generate an MSK and an 
EMSK. The MSK is used by several EAP lower layers. The EMSK remains 
at the peer and server, but it is not presently used in any 
specifications. Different EAP lower layers make use of the MSK 
differently; the most common usage is to derive Transient Session 
Keys (TSKs) to provide access link security in networks (e.g., IEEE 
802.11i, IEEE 802.16e), although some lower layers (e.g., IKEv2) use 
the MSK for other purposes.

Extensions to current EAP key framework will be needed to support 
some envisioned scenarios. Some problems that need to be addressed 
with extensions to EAP keying include:

1) Transport of the EAP MSK from the EAP/AAA server to the initial 
authenticator means a handover from the initial authenticator to 
another authenticator may require re-execution of EAP authentication, 
even though the same EAP/AAA server will handle the 
authentication. Handover scenarios vary considerably in their 
fundamental assumptions. In scenarios where hosts remain connected 
during the handover period, EAP authentication need not be in the 
critical path for handover. However, there are scenarios where 
necessary connectivity is not available or where the EAP does not 
support "make before break" communications. In these scenarios, 
significant handover latency can result. To avoid this latency, SDOs 
have employed methods such as context transfer and anchoring that are 
inefficient or insecure or both.

2) EAP peers with unexpired keying material from a full EAP exchange 
must take part in a full EAP exchange with the same AAA server to 
extend a session. While some EAP methods provide fast 
re-authentication mechanisms, these procedures require a minimum of 
one-and-a-half roundtrips. A consistent, method-agnostic, single 
roundtrip protocol is needed.

3) EAP generates keys (MSK and EMSK). When the EAP WG updated the 
protocol and specified the keying framework, many details regarding 
the use of the EMSK were not specified. The EMSK can be used as the 
root of a cryptographic key hierarchy, and then the keys in the 
hierarchy are used in various ways to provide the needed security 
services. In order to ensure that different keys derived from the 
EMSK are cryptographically separate and that the key derivations are 
coordinated in an acceptable manner, it is important to clearly 
specify the top of the topology for the key hierarchy and some 
guidelines for child key derivations.

4) When wireless networks employ AAA infrastructures, the 
cross-domain roaming is handled by inter-domain authentication via 
the "home" AAA/EAP server. Any authentication must pass through the 
home server, which increases latency. Latency can be reduced by 
establishing a trust relationship between the EAP peer and the 
visited domain's AAA/EAP server. This trust relationship would be 
brokered by the home EAP/AAA server. Efficient re-authentication for 
the EAP peer can be supported locally within the visited domain.

Some of the inconsistency can be attributed to different trade-offs 
between computational cost, mobility performance, and 
security. However, clear direction by the IETF on AMSK (also called 
USRK) derivation could reduce some of the inconsistencies. However, 
the HOKEY WG will not attempt to standardize TSK derivation from the 
MSK, as this would interference with work of other SDOs.

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."

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 draft-housley-aaa-key-mgmt and
draft-ietf-eap-keying.

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) No 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
=====================

All the specifications will be EAP-method-independent manner and 
access-technology-agnostic. They will provide enough semantics and 
guidance so that all SDOs can employ them and preserve cryptographic 
separation.

1) A Problem Statement that defines the problem of re-authentication 
and key management. The discussion will include security and 
performance goals for the solutions. Too often, mobility 
optimization discussions do not clearly identify the scenarios that 
are being addressed; this lack of clarity often makes it difficult to 
agree on whether the proposed optimizations offer real value. To 
avoid this situation, the Problem Statement must clearly describe the 
scenarios that are being addressed, and the assumptions about the 
handover environment associated with that scenario.

2) A specification of an EMSK-based key hierarchy topology. The 
specification will include a requirements, one or more key derivation 
function (KDF), and parameters. This is follow-on work EAP (RFC 
3748) and EAP keying framework that was developed in the EAP WG.

3) A specification for the derivation of root keys, such as the 
handover root key (HRK), to support re-authentication and handover 
key management. The HOKEY WG can base these keys on either the MSK 
or the EMSK produced by EAP (pick one). If the consensus is to use 
the EMSK, then the HRK forms one branch in the EMSK-based key 
hierarchy. This specification will describe the properties of each 
key that is specified, and the topics must include caching, naming, 
scope, binding, storage, and key lifetime.

4) A protocol specification for media-independent, low-latency 
re-authentication. The EAP re-authentication mechanism must support 
handovers between EAP authenticators. This protocol specification is 
expected to employ a re-authentication branch in the key hierarchy.

5) A protocol specification for secure and timely distribution of 
cryptographic keys to support roaming and handover. Use of AAA 
protocols is preferred, and if used, should leverage existing work if 
possible (such as RADEXT WG work on RFC 3576bis and RADIUS 
cryptographic algorithm agility). However, if AAA protocols cannot 
meet the objectives, other protocols for reactive or proactive 
distribution or retrieval of keys by the proper entities is permitted.

6) A specification for inter-domain roaming solutions based on use of 
either trust relationships or pre-authentication methods or both.

MILESTONES
==========

Dec 06 First draft with a problem statement on EAP re-authentication and
key management

Dec 06 First draft on EMSK-based Keying Hierarchy

Feb 07 First draft on EAP Re-authentication and Handover Keying
Hierarchy

Feb 07 First draft on EAP Re-authentication Protocol

Mar 07 First draft on Protocol and Keying Hierarchy for Visited Domain
Handovers and Re-authentication

Mar 07 Submit the problem statement draft to IESG

Mar 07 Submit EMSK-based Keying Hierarchy draft to IESG

Jun 07 First draft on Handover Key Distribution Protocol

Aug 07 Submit EAP Re-authentication and Handover Keying Hierarchy draft
to IESG

Aug 07 Submit EAP Re-authentication Protocol draft to IESG

Sep 07 Submit Protocol and Keying Hierarchy for Visited Domain Handovers
and Re-authentication draft to IESG

Sep 07 First draft on EAP Pre-authentication Specification for
inter-technology and inter-domain handoffs

Mar 08 Submit EAP Pre-authentication Specification to IESG

Mar 08 Re-charter or shut down WG
_______________________________________________
Hokeyp mailing list
Hokeyp@opendiameter.org
http://www.opendiameter.org/mailman/listinfo/hokeyp


----- End forwarded message -----