|
Good point. Will fix it.
----- Original Message -----
Sent: Tuesday, September 01, 2009 10:27
PM
Subject: Re: [HOKEY] First draft of new
hokey charter
It is actually 802.21a not 802.21.
Regards,
Behcet
From: Tina
TSOU <tena at huawei.com> To: Glen Zorn <gwz at net-zen.net>; liu dapeng <maxpassion at gmail.com> Cc: hokey at ietf.org Sent: Tuesday, September 1, 2009
4:33:57 AM Subject: Re:
[HOKEY] First draft of new hokey charter
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.
B. R. Tina http://tinatsou.weebly.com/contact.html
----- 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
|