Hi, chairs:
Sorry
for my
with the Hokey WG Charter text and would like to have some comments inline.
Would you like to take them into consideration?
Regards!
-Qin
---------------------
Handover Keying (hokey)
------------------------
Last Modified: 2009-10-19
Chair(s):
Security Area Director(s):
Security Area Advisor:
Mailing Lists:
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 situa
tions.
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".
[Qin]:
tication should be separated from early authentication,
because as described in draft-ietf-hokey-preauth-ps, pre-authentication is one integral
part of early authentication, therefore I would like to suggest you to delete *pre-authentication*
in this paragraph.
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
inde
pendent<
y 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. Th
ese incl
re-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. This specification and the revision of RFC5296 should be
conducted in parallel.
[Qin]: ERP can also be useful in the non-mobile environment,
where the ERP server can act as a kind of authentication proxy, therefore
I would like to suggest you to change the *mobile enviroment* in the bullet 3)
as *wireless enviroment*
4) Assistance to the 802.21a group
in spec
EAP
pre-authentication with IEEE 802.21a. The Hokey Working Group shall
perform tasks that are complementary to and do not duplicate work being
done in IEEE 802.21a.
[Qin]: As I mentioned above, the pre-authentication is part of early authentication,
So I would like to suggest you to change *pre-authentication* in this bullet as * early
authentication*.
[Qin]: Why bullet 5) is missing? what am I missing?
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 t
aken int
div>
[Qin]: I don't think this work item is useful or worthwhile being developed although I proposed to include this topic in the charter at the beginning in the IETF 74. As Katrin indicated,this work can be potentially part of hokey architecture. Also as I know, this work has been specified in WiMAX Forum as technology specific mechanism, I don't think we should specify it in the IETF as well. It is better to be incorporated it into bullet 3) with few words.
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.
&
e="Times New Roman">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 NAS-Authenticator Interaction draft to IESG
[Qin]: I don't think it is worthwhile being taken as an independent work item.
Actually there is other valuable work item that can be taken into account, e.g.,
token based authentication.