Subject: [HOKEY] 2nd draft of new hokey charter

From: Tina TSOU <[email-masked]>
Date: Wed, 02 Sep 2009 17:22:35 +0800

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. This specification
and the revision of RFC5296 should be conducted in parallel.

4) Assistance to the 802.21a group in specifying the integration of 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.

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 NAS-Authenticator Interaction draft to IESG
Nov 2011 Submit the Hokey architecture draft to IESG
Nov 2011 Submit the revision of RFC 5296 to IESG
Mar 2012 Re-charter or shut down WG

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 2 Sep 2009 13:02:52 +0300

What is this work about? Typically "EAP authenticator" is implemented on the
"NAS". Is this about an API, or separating the two and defining a protocol
in between? 

Alper

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tina TSOU
Sent: Wednesday, September 02, 2009 12:23 PM
To: [email-masked]
Subject: [HOKEY] 2nd draft of new hokey charter

Comment, please!

HOKEY WG Deliverables
=====================

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

Goals and Milestones:

---

From: Tina TSOU <[email-masked]>
Date: Thu, 03 Sep 2009 09:58:39 +0800

Hi Alper, Dash et al,
Thank you for pointing out the architectural muddling that the 
original phrasing presented.

Let's amend the work item to talk about inter-authenticator 
communication. It could look like this
 
6) A specification for inter-authenticator interaction. Authenticator interaction can be
used to release resources in the old authenticator and achieve faster initiation of
authentication. Related work in external SDOs on authenticator
interaction for re-authentication may be taken into consideration.

WDYT?

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

  ----- Original Message ----- 
  From: Dash Liu 
  To: 'Alper Yegin' ; 'Tina TSOU' ; [email-masked] 
  Sent: Thursday, September 03, 2009 9:33 AM
  Subject: 答复: [HOKEY] 2nd draft of new hokey charter

  I think it should be an interaction to adjusting the resources. Is it?

  Best Regards

  Dash

------------------------------------------------------------------------------

  发件人: [email-masked] [mailto:[email-masked]] 代表 Alper Yegin
  发送时间: 2009年9月2日 18:03
  收件人: 'Tina TSOU'; [email-masked]
  主题: Re: [HOKEY] 2nd draft of new hokey charter

  What is this work about? Typically “EAP authenticator” is implemented on the “NAS”. Is this about an API, or separating the two and defining a protocol in between? 

  Alper

  From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
  Sent: Wednesday, September 02, 2009 12:23 PM
  To: [email-masked]
  Subject: [HOKEY] 2nd draft of new hokey charter

  Comment, please!

  HOKEY WG Deliverables
  =====================

  Goals and Milestones:

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 03 Sep 2009 13:31:22 +0200

Hi Tina,

I have a couple of comments/questions about the charter
> tasks that are complementary to and do not duplicate work being done 
I was wondering what kind of "assistance to the 802.21a group in 
specifying the integration of EAP
pre-authentication with IEEE 802.21a" is required?.
> interaction for re-authentication may be taken into consideration.
If I understood correctly from the last HOKEY WG meeting minutes (number 
9 in the minutes), the received comment was that this should be out of 
the scope of HOKEY, is that correct?.

On the other hand, I do not understand very well what it is the 
purpose/meaning of a specification for NAS-authenticator interaction. 
That is, I am not sure what it is trying to solve. Now, there is a 
change in the new text saying:

6) A specification for inter-authenticator interaction. Authenticator 
interaction can be
used to release resources in the old authenticator and achieve faster 
initiation of
authentication. Related work in external SDOs on authenticator
interaction for re-authentication may be taken into consideration.

Even with this change I am not able to understand the purpose. Moreover, 
does this change imply a change in the the scenarios and goals included 
in the slides presented about this topic in last IETF meeting?.
 
My apologies for the questions but I am trying to catch up with this.

Best regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 04 Sep 2009 01:24:18 +0900

(My comment in this email is based on my personal opinion, and does not 
represent a position of IEEE 802.21a Task Group.)

I have a comment on the following text:

"4) Assistance to the 802.21a group in specifying the integration of 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."

First of all, I thank HOKEY WG for mentioning IEEE 802.21a.  

However, the text seems to imply that IEEE 802.21a Task Group needs some assistance from HOKEY WG, and I have not seen such a need in 802.21a Task Group. On the other hand, whenever 802.21a Task Group comes to require assistance from IETF, a liaison letter asking for a specific assistance could be sent from IEEE 802 to an appropriate IETF WG (and such an IETF WG may not be the HOKEY WG depending on what specific assistance on a specific issue is needed), using the existing liaison relationship between IEEE 802 and IETF, even if HOKEY charter does not have the above text.  Having said that I don't see a real need for having the above text in HOKEY charter for now.

Regards,
Yoshihiro Ohba

Tina TSOU wrote:
> ------------------------------------------------------------------------
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 04 Sep 2009 18:24:56 +0800

Hola Rafa,
One person made strong representations against the work as presented in the 
meeting. On the other hand, there was definite interest in this topic on the 
list before the meeting.

As to the second question: one would have to look at the scenarios on the 
slides, but I think they are still valid.

B. R.
Tina

  ----- Original Message ----- 
  From: Rafa Marin Lopez 
  To: Tina TSOU 
  Cc: [email-masked] 
  Sent: Thursday, September 03, 2009 7:31 PM
  Subject: Re: [HOKEY] 2nd draft of new hokey charter

  Hi Tina,

   

  Best regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 04 Sep 2009 17:13:24 +0200

> Hola Rafa,
Hola Tina, thanks for your answer.

First of all, any comments about my question regarding charter point 4).?
> meeting. On the other hand, there was definite interest in this topic 
Secondly, I have just checked the e-mails in the ML but I failed to see 
the interest as a work item. In fact, the only thing I have seen is one 
comment in this e-mail:

http://www.ietf.org/mail-archive/web/hokey/current/msg01623.html

where it is said that this should not be a separate work item (If I 
correctly understood).

Am I missing something? Could you point me the e-mails I missed about 
this interest?

Btw, the charter text says:

"Related work in external SDOs on authenticator interaction for 
re-authentication may be taken into consideration."

I would be interested in the related work in external SDOs, could you 
point out some references?.
> slides, but I think they are still valid.
If they are still valid, then I don't completely understand the general 
purpose/goal of this particular aspect. What are we trying to solve here?.

Best Regards.
>     *From:* Rafa Marin Lopez <mailto:[email-masked]>
>     *To:* Tina TSOU <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Thursday, September 03, 2009 7:31 PM
>     *Subject:* Re: [HOKEY] 2nd draft of new hokey charter
>
>     Hi Tina,
>
>     > 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
>     Telf: +34968398501    e-mail: [email-masked] <mailto:[email-masked]>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 04 Sep 2009 12:10:18 -0400

I agree with the proposed charter item on grounds of flexibility. While 
milestones can be updated fairly easily, as we have seen, the basic text of the 
charter is more difficult to change. It's better to leave room for the 
possibility of cross-SDO effort rather than ignore the issue and have to 
persuade the IESG to let Hokey get involved if a liaison does come.

Yoshihiro Ohba wrote:
> 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."
> 
> However, the text seems to imply that IEEE 802.21a Task Group needs some 
> assistance from HOKEY WG, and I have not seen such a need in 802.21a 
> Task Group. On the other hand, whenever 802.21a Task Group comes to 
> require assistance from IETF, a liaison letter asking for a specific 
> assistance could be sent from IEEE 802 to an appropriate IETF WG (and 
> such an IETF WG may not be the HOKEY WG depending on what specific 
> assistance on a specific issue is needed), using the existing liaison 
> relationship between IEEE 802 and IETF, even if HOKEY charter does not 
> have the above text.  Having said that I don't see a real need for 
> having the above text in HOKEY charter for now.
> 
> Regards,
> Yoshihiro Ohba
> 
> 
....

---

From: Tom Taylor <[email-masked]>
Date: Fri, 04 Sep 2009 22:25:22 -0400

As the person who presented the authenticator interaction proposal at the 
meeting I'd better answer this. At the meeting I heard Glen mutter "funny, there 
seemed to be interest on the list". That may be where the "definite interest" 
impression came from.

I agree with you, Katrin seems to have suggested it should be part of the 
architecture work. I suppose we can take the AD's advice on whether we need a 
separate work item just in case the architectural discussion leads to protocol work.

As for external SDOs, Simon Mizukovsky (hope I spelled that right) stated quite 
firmly at the meeting that other SDOs have already specified protocols in this 
area. I myself am unaware of such work (though 3GPP and 3GPP2 may have done the 
logical equivalent), but it seems reasonable to allow for its existence. One 
interesting point: Simon said the solutions were technology-specific. That 
suggests that there is work needed to develop a cross-technology optimization.

As the charts themselves indicate, that could be based on 802.21 signalling. If 
so, the protocol work obviously belongs to 802.21. However, are there scenarios 
where an IP-based inter-authenticator protocol would be useful?

I seemed to have reached a conclusion that we'd better do the architectural work 
first to find out.

Tom Taylor

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 06 Sep 2009 02:00:36 +0900

On what specific topic in EAP pre-authentication cross-SDO effort may 
happen?

Yoshihiro Ohba

Tom Taylor wrote:
> I agree with the proposed charter item on grounds of flexibility. 
> While milestones can be updated fairly easily, as we have seen, the 
> basic text of the charter is more difficult to change. It's better to 
> leave room for the possibility of cross-SDO effort rather than ignore 
> the issue and have to persuade the IESG to let Hokey get involved if a 
> liaison does come.
>
> Yoshihiro Ohba wrote:
>>
>> (My comment in this email is based on my personal opinion, and does 
>> not represent a position of IEEE 802.21a Task Group.)
>>
>> perform tasks that are complementary to and do not duplicate work 
>> being done in IEEE 802.21a."
>>
>> First of all, I thank HOKEY WG for mentioning IEEE 802.21a. However, 
>> the text seems to imply that IEEE 802.21a Task Group needs some 
>> relationship between IEEE 802 and IETF, even if HOKEY charter does 
>> not have the above text.  Having said that I don't see a real need 
>> for having the above text in HOKEY charter for now.
>>
>> Regards,
>> Yoshihiro Ohba
>>
>>
> ....
>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 06 Sep 2009 10:22:54 -0400

Isn't that up to you?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 07 Sep 2009 08:09:45 +0900

> Isn't that up to you?

If it's up to 802.21a, then I am fine.

Thanks,
Yoshihiro Ohba

>>> the issue and have to persuade the IESG to let Hokey get involved if 
>>> a liaison does come.
>>>
>>> Yoshihiro Ohba wrote:
>>>>
>>>> assistance could be sent from IEEE 802 to an appropriate IETF WG 
>>>> (and such an IETF WG may not be the HOKEY WG depending on what 
>>>> specific assistance on a specific issue is needed), using the 
>>>> existing liaison relationship between IEEE 802 and IETF, even if 
>>>> HOKEY charter does not have the above text.  Having said that I 
>>>> don't see a real need for having the above text in HOKEY charter for 
>>>> now.
>>>>
>>>> Regards,
>>>> Yoshihiro Ohba
>>>>
>>>>
>>> ....
>>>
>>
>>
>>
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 09 Sep 2009 15:29:01 +0200

Hi Tom,

thanks for answering to the second question I made. Please see my 
comments below.

Tom Taylor wrote:
> As the person who presented the authenticator interaction proposal at 
> the meeting I'd better answer this. At the meeting I heard Glen mutter 
> "funny, there seemed to be interest on the list". That may be where 
> the "definite interest" impression came from.
>
> I agree with you, Katrin seems to have suggested it should be part of 
> the architecture work. I suppose we can take the AD's advice on 
> whether we need a separate work item just in case the architectural 
> discussion leads to protocol work.
I guess so.
>
>
> As for external SDOs, Simon Mizukovsky (hope I spelled that right) 
> stated quite firmly at the meeting that other SDOs have already 
> specified protocols in this area. I myself am unaware of such work 
> (though 3GPP and 3GPP2 may have done the logical equivalent), but it 
> seems reasonable to allow for its existence. One interesting point: 
> Simon said the solutions were technology-specific. That suggests that 
> there is work needed to develop a cross-technology optimization.
>
> As the charts themselves indicate, that could be based on 802.21 
> signalling. If so, the protocol work obviously belongs to 802.21. 
> However, are there scenarios where an IP-based inter-authenticator 
> protocol would be useful?
>
> I seemed to have reached a conclusion that we'd better do the 
> architectural work first to find out.
I also agree with your conclusion.

Best regards.
>> Secondly, I have just checked the e-mails in the ML but I failed to 
>> see the interest as a work item. In fact, the only thing I have seen 
>> is one comment in this e-mail:
>>
>> If they are still valid, then I don't completely understand the 
>> general purpose/goal of this particular aspect. What are we trying to 
>> solve here?.
>>
>> Best Regards.
>>>  
>