Chairs : Glen Zorn (gwz@net-zen.net)
Tina Tsou (tena@huawei.com)
Jabber : hokey@jabber.ietf.org
URL : http://tools.ietf.org/wg/hokey/
Agenda : Version 0.1 (draft)
Meeting : IETF 78; Maastricht,
Netherlands
Date : Thursday, 29 July 2010
Time : 15:10-16:10
Location:
0.1 London
Glen
Zorn
Draft:
http://www.ietf.org/id/draft-ietf-hokey-ldn-discovery-01.txt
Discussion
Glen
Zorn:
WGLC
ends tomorrow
Need
to send in comments immediately
Zhen
Cao:
Noted
his comment on the list that this might be better be
an RA option.
Glen
Zorn:
Suggested
that could be done, but as another draft.
It is correct that the title should be
"DHCPv6 Option For ..."
Zhen Cao
Draft: http://datatracker.ietf.org/doc/draft-ietf-hokey-erp-aak/
Discussion
Simon
Mizikovsky:
What is the issue with CAP
determination?
Zhen Cao:
The
problem is which CAP will receive the master key?
Tom
Taylor:
Could
not see what the problem was either, and thought it was a question of
cryptographic separation of keys issued to different CAPs.
Glen
Zorn:
Clarified
that this was a question of whether a given CAP was authorized to provide
service to the mobile node. The EAP/AAK server could not do the job,
particularly if multiple AAA hops separate the server from the CAP.
Current Status of
IEEE 802.21a
Yoshihiro Ohba
Discussion
Qin
Wu:
Asked whether Option III is related to AAA.
Yoshi:
Explained
that AAA has to do with access control, and that may require
centralized control. So there is a relationship between Option III and AAA.
Simon
Mizikowsky:
Both
schemes show key establishment on the target system.
Simon
Mizikowsky:
Referring
to chart 2, how is association established between serving and target PoS?
Yoshi:
Single
domain situation is clear. Not so clear for inter-domain.
Simon:
But
reference point is specified between Serving and Target PoS. Surely this is acceptable only in when a
security association is established between them.
Discussion
cut short by Chair: belongs in 802.21a.
Qin
Wu:
Asked
how discovery is carried out.
Yoshi:
Clarified that this is part of 802.21a work, but
just as an information element. Main task is
for 802.21.
Proposed
New Charter Items
§ EAP Extensions
for EAP Re-authentication Protocol (ERP)
Qin Wu
Discussion
No
changes from 5296 so far.
Three
key issues raised by errata.
- requirement that ER
server lie in the path of AAA messages
- assumption that ER
server can edit AAA messages
- unnecessarily
restrictive in deployment options
Open
issues
- Terminology issue
Glen Zorn suggested simply calling it
"re-authentication protocol".
- Need to clarify description of NAI-keyname
- Editorial issues with section 3.1. Need
clear text to address ERP with home
ER server.
- Qin: re-authentication can only happen after
attachment.
Yoshi concerned that removal of text
referring to re-authentication before
attachment could
hurt 802.21a work. Referred to list for discussion.
- other issues
Follow
up: resolve errata, issue new version, look for feedback from WG.
§ EAP Extensions for Early Authentication
Protocol (EEAP) for Inter-AAA-Domain handover
Qin Wu
Out
of time -- presentation limited -- discussion to the list