|
Hi Da-Peng,
Thank you for your comments.
Regarding the complementary work to 802.21 in the chartering file, I just keep the text
as simple as possible, leave more space for people working in hokey. Then there
is no need to update the charter always.
You could propose the complementary work by I-D.
----- Original Message -----
Sent: Monday, August 31, 2009 11:20
PM
Subject: Re: [HOKEY] First draft of new
hokey charter
2009/8/23, Glen Zorn <gwz at net-zen.net>:
> Comment,
please!
>
>
> 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.
>
> 4) Assistance to
the 802.21a group in specifying the integration of EAP
>
pre-authentication with IEEE 802.21. The Hokey Working Group shall
perform
> tasks that are complementary to and do not duplicate work
being done in IEEE
> 802.21a.
I am wondering what is exactly is
the complementary work to 802.21? thanks.
BR,
Dapeng Liu
>
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 Hokey architecture draft to IESG
> Jul 2011 Submit the
NAS-Authenticator Interaction draft to IESG
> Nov 2011 Submit the
revision of RFC 5296 to IESG
> Mar 2012 Re-charter or shut down
WG
>
>
>
_______________________________________________
> HOKEY mailing
list
> HOKEY at ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>
_______________________________________________
HOKEY
mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey
|