Subject: [HOKEY] First draft of new hokey charter

From: "Glen Zorn" <[email-masked]>
Date: Sat, 22 Aug 2009 10:59:58 -0700

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.

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

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 24 Aug 2009 10:45:57 +0900

Hello Glen,

About the milestones, I am wondering if the revision of RFC5296 will not
have an impact on the architecture document, in which case the work on
both documents should be conducted in parallel. What do you think?

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Tina TSOU <[email-masked]>
Date: Mon, 24 Aug 2009 17:37:56 +0800

Hi Sebastien,
When I wrote this draft of re-chartering, I haven't thought about it. You are right. So, what's your suggestion? We could adjust the milestone.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: Sebastien Decugis 
  To: Glen Zorn 
  Cc: [email-masked] 
  Sent: Monday, August 24, 2009 9:45 AM
  Subject: Re: [HOKEY] First draft of new hokey charter

  Hello Glen,

  Best regards,
  Sebastien.

  _______________________________________________
  HOKEY mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/hokey

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 31 Aug 2009 16:35:38 +0900

Hi Tina,

Sorry for my late answer.
I don't know if / how the milestones or the text should be changed. I
would simply like to avoid that the architecture document is based on
the current ERP mechanism, if this mechanism is to be changed in a way
that impacts the architecture (i.e. the architecture document would be
history a few month after its publication...)
If the architecture document is supposed to take into account the
revision of rfc5296, it would seem natural to me that its deadline is
same or after the one of rfc5296bis. I don't know what a reasonable
change to the milestones is (move rfc5296bis earlier or architecture
document later), nor the other constraints on these documents.

Best regards,
Sebastien.

Tina TSOU a écrit :
> Hi Sebastien,
> When I wrote this draft of re-chartering, I haven't thought about it.
> You are right. So, what's your suggestion? We could adjust the milestone.
>  
>  
> B. R.
> Tina
>     *From:* Sebastien Decugis <mailto:[email-masked]>
>     *To:* Glen Zorn <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Monday, August 24, 2009 9:45 AM
>     *Subject:* Re: [HOKEY] First draft of new hokey charter
>
>     Hello Glen,
>
>     [email-masked] <mailto:[email-masked]>

---

From: liu dapeng <[email-masked]>
Date: Mon, 31 Aug 2009 23:20:36 +0800

> and signaling can be employed in a specific access technology.

I am wondering what is exactly is the complementary work to 802.21? thanks.

BR,
Dapeng Liu

---

From: Tina TSOU <[email-masked]>
Date: Tue, 01 Sep 2009 12:27:24 +0800

Bonjour Sebastien, Hi Glen et al,
How about the following changes?

"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."

Changed into

"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.
"

"Goals and Milestones:
"

Changed to 
"Goals and Milestones:
Nov 2011 Submit the Hokey architecture draft to IESG
"

B. R.
Tina

  ----- Original Message ----- 
  From: Sebastien Decugis 
  To: Tina TSOU 
  Cc: [email-masked] 
  Sent: Monday, August 31, 2009 3:35 PM
  Subject: Re: [HOKEY] First draft of new hokey charter

  Hi Tina,

  Best regards,
  Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 01 Sep 2009 13:41:24 +0900

Hi Tina,

Thank you for your mail. The change on the charter text is fine with me.
About the change in the milestones, I don't really have an opinion,
since I don't know much about which documents depends on which others...

Best regards,
Sebastien.

Tina TSOU a écrit :
> There are various useful scenarios that need to be addressed. *This
> specification and the revision of RFC5296 should be conducted in
> parallel.*
> "
>  
> "Goals and Milestones:
> *Jul 2011 Submit the Hokey architecture draft to IESG*
> *Nov 2011 Submit the Hokey architecture draft to IESG*
>     *To:* Tina TSOU <mailto:[email-masked]>
>     *Sent:* Monday, August 31, 2009 3:35 PM
>     <mailto:[email-masked]>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>