IETF-76 hokey minutes

Slides

Hokey Architecture
Local Domain Name Discovery
ERP extension for EAP Early-authentication protocol (EEP)
Token based handover key derivation for Re-authentication
ER architectural exploration

Minutes

HOKEY WG Notes

Dorothy Stanley (Aruba Networks)

Agenda: IETF-76 HOKEY agenda

Handover Keying (HOKEY) Working Group

Chairs : Glen Zorn (gwz@net-zen.net)
Tina Tsou (Ting ZOU) (tena@huawei.com

Jabber : hokey@jabber.ietf.org
URL : http://tools.ietf.org/wg/hokey/

Agenda : Version 1.0 (draft)
Meeting : IETF 76; Hiroshima, Japan
=========================================================

Date : Tuesday 10th, November 2009
Time : 15:20 - 17:00
Location: Cattleya West

=========================================================

Welcome & Administrivia (10 minutes)
Bluesheets
Jabber scribe
Minute Takers
Document Status (5 minutes)

1. Hokey architecture <draft-hoeper-hokey-arch-design-01.txt>
Sebastien Decugis (15 minutes)

2. Local Domain Name Discovery for ERP <draft-wu-hokey-ldn-discovery-00.txt>
Qin Wu/TBD (15 minutes)

3. The architectural choices available if one wanted to havea local ERP server independent of the Diameter proxy
Tom Taylor (15 minutes)

4. Early Authentication solutions
Hui Deng (15 minutes)

5. Token based handover key derivation for Re-authentication
Shu Liu (15 minutes)

Wrap-Up (5 minutes)

1. Chair reminded participants to sign the blue sheets

2. Chair asks for note takers and jabber scribe. Dorothy Stanley volunteers to take notes.

3. Document status: The remaining 2 docs have passed WGLC and are in the tender clutches of the IESG.

4. First presentation: HOKEY Architecture draft: Sebastien Decugis (15 minutes)

• - Motivation: Currently unclear how necessary handover infrastructure is deployed and can be integrated into existing EAP infrastructures

• - Goals: Lower signaling overhead; Minimize communication in home devices

• - Integrate Local Domain Name Discovery. Described system overview and components, relation sip between HOKEY key management and HOKEY authentication, and HOKEY authorization.

• - Describes deployment scenarios: Home HOKEY Service, non roaming case., visited HOKEY Service, Hybrid Service

• - Question on the deployment scenario, hybrid case, when you hand off between the domains can you use ERP? Can, not recommended, issue is authorization. Also of discovery of ER server.

• - Divide use case into two, Same or different visited network: inter or intra domain. Could be both visited, but in varying domains.

• - Conclusion: Request to accept the draft as a WG item. Chair asks for group's input on open issues, encourage review of the draft, and early feedback.

• - Is there interest in the drafts: Who has read the draft: a few hands are raised.

• - Believe work is important; summarize the components for the user community.

• - Open Questions: additional architecture goals, local Domain Name Discovery, ERP capability discovery.

• - Adopt as a WG item now, Chair asks for a hum: adopt, not adopt. Some but not definitive level. Wait for adoption of the charter before adopting this as a WG item.

5. Second presentation: Tom Taylor: Can a Local ERP Server be separated from a Diameter Proxy?

• 5.Second presentation – Tom Taylor: Can a Local ERP Server be separated from a Diameter Proxy?
  
  See slides for this presentation at http://www.ietf.org/proceedings/09nov/slides/hokey-4.pdf. In summary, these slides begin with one showing functional components and potential interfaces to the local ERP server. The remaining slides show
   - information flow requirements during the initial authentication phase
   - possible solutions (three alternatives) to achieve this flow
   - information flow requirements during the re-authentication phase
   - possible solutions for this phase.
  
  Qin Wu sought clarification of the point about need for a "correlator", mentioned on the first information flow slide. Tom Taylor described this as some piece of information that is generated or provided during initial authentication and has to appear in re-authentication signalling sent to the local ERP server, to allow it to retrieve the DSRK instance applicable to this particular peer.
  
  Sebastien Decugis said this was an interesting analysis. It raises the thought that it might also be possible to decorrelate the home EAP server from Hokey functions.
  
  At the end of the presentation, Qin referred to the various alternatives offered for the initial authentication flow and expressed his feeling that an on-path solution is to be preferred. Glen Zorn warned that we should not assume that the ERP server and Diameter servers or proxies are collocated. Such an assumption causes problems with Diameter and routing. With RADIUS the ERP server has to be on path. With Diameter, we don’t have to assume this. Gain flexibility in deployment and implementations, including fault tolerance. Do need to distinguish between ER-Diameter Agent and NAS-ER Server.

6. Local Domain Name Discovery for ERP <draft-wu-hokey-ldn-discovery-00.txt>
Qin Wu/TBD (15 minutes)

• - Example of Local Domain Name

• - Use DHCP to request local domain name; domain name must be available to the peer during or after the full EAP authentication

• - Description of scenario as explained in RFC5296.

• - Description of additional scenario for re-authentication

• - Should this be adopted as a WG item?

• - Discussion: WG chair asks for a hum. Moderate level of interest. Volunteers for reviewing the document: 2 volunteers.

7. ERP extension for EAP Early Authentication Solutions Hui Deng (15 minutes)

• - Overview of current document solutions, and terminology

• - Overview of the information flow

• - EAP Early Authentication Protocol (EEP) re-uses the ERP packets, summarizes the extensions: new flag, New TLV.

• - Lower layer specifications may need to be revised to support EEP.

• - New Diameter EEP application message is needed, to transport EE keying materials.

• - Discussion - Step 1 Information Flow. Why would peer discover the possible NAS? Usually peer doesn't know or care where authenticator is located.

• - Peer only knows the physical link of the base station, query the network before link is established.

• - Current WiMax architecture. ASN gateways serves N base stations. Can have authenticator function. First one is not the anchor authenticator. Don't understand the CA discovery.

• - Consider 2 scenarios: homogeneous scenario, from one technology, e.g. 802.21.

• - CA discovery is pre-handover.

• - Mobile hands over from one coverage area to another: control plane. Only need to check when cross a boundary.

• - Format of the message: how to indicate different server destinations.

8. Token based handover key derivation for Re-authentication
Shu Liu (15 minutes)

• - Objective is to provide fresh, valid re-authenticaiton root key to the authenticator when inter-authenticator handover within the dame local ER server happens.

• - Description of the problem

• - Summary of requirements for the solution

• - Re-use existing authentication credentials, centralized management, access control protection.

• - Straw-man proposal: authentication token.

• - Comment: use of an incremental counter will not expose information to an attacker. Basic MAC property. Don't believe this is a problem.

• - How is rMSK compromised?

• - When peer moves, RMSK is the same, sequence number is re-used?

• - Doesn't matter. If have a strong PRF.

• - Probably not a real problem. Onus on the authors to prove that it is.

• - History on key generation: WIMax, 3GPP, EAP draft, Hokey draft. Only one not aligned is the HOKEY draft.

Meeting adjourned 5pm Local time.