Re: [802.21] FW: [Hokeyp] HOKEY WG Charter Ready for External Review
I would like to clarify that the two-week discussion for External
Review on the HOKEY WG charter is supposed to happen in the IETF
mailing list (ietf@ietf.org), not in hokeyp@opendiameter.org. The
former mailing list is for discussion in the entire IETF community
while the latter will be used as the HOKEY WG mailing list if the WG
is formed.
General information on the IETF mailing list (subscription interface
as well as access archives) is avalable at:
https://www1.ietf.org/mailman/listinfo/ietf
Best regards,
Yoshihiro Ohba
On Thu, Sep 28, 2006 at 03:41:57PM -0700, 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
>