Re: [802.21] FW: [Hokeyp] HOKEY WG Charter Ready for External Review
Michael,
Thanks for forwarding this to the mailing list. I would also like
to encourage interested WG members to participate in the IETF
mailing list discussion.
regards,
-Subir
Michael G. Williams wrote:
>
> Colleagues,
>
> We had a presentation on the attached IETF work as part of the
> discussion about a possible study group in our working group. This is
> for your information as many of the group participate in IETF as well,
> but some do not.
>
> Best Regards,
> Michael
> -----Original Message-----
> From: hokeyp-bounces@opendiameter.org
> [mailto:hokeyp-bounces@opendiameter.org] On Behalf Of ext Russ Housley
> Sent: Thursday, September 28, 2006 11:21 AM
> To: hokeyp@opendiameter.org
> Subject: [Hokeyp] HOKEY WG Charter Ready for External Review
>
> The IESG will be sending the attached proposed charter for External
> Review. External Review is essentially a two week Last Call for the
> proposed charter. I encourage people on this mail list to participate
> in the discussion on the IETF mail list regarding the charter.
>
> Russ
>
> = = = = = = = = = = =
>
> 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
>