Meeting minutes of hokey meeting on Monday, July 27th, IETF-75
Seven people on Jabber including some physically present.
0. Glen explained that Qin was the only one to respond to call for agenda items
1. Tim introduced Tina as new WG Chair
2. Glen presented status for key transport draft (now in IETF Last Call)
3. Qin Wu presented status report for problem statement. No comments.
4. Qin Wu presented proposal for local domain name discovery.
Glen said would take hum later on items as a whole: should the group re-charter?
5. Qin Wu presented proposal for solution to EAP preauthen and early authen problem
Glen asked for Jabber comment. Hannes had suggested the fact that only one person contributed did not bode well for work of the group.
6. Qin Wu presented on possibilities for EAP-AKA optimization
Tim Polk commented that this was probably not the right group for method-specific work. Would have to be rejected by method-specific people first (emu)
. Yoshi (Jabber) fully agreed. Glen also.
7. Hokey architecture Qin Wu on behalf of Katrin
Glen: doesn't have the same view of arch. Thinks of stuff like fault tolerance. Feels Diameter people missing the point worrying about message routing. Probably won't be used a lot for mobility. Corporate people would love to do network authen when home server is down. Hokey an answer.
Simon Visikovsky ?? why a link between domains in early authen Scenario C? Further discussion suggested it is not used.
8. 802.21 integration, Qin presenting
Yoshi (Jabber): I am all against making 802.21/hokey integration a HOKEY work item. 802.21/hokey integration is being defined in 802.21a TG as part of its work item #1 (to define a mechanism to reduce the latency during authentication and key establishment for handovers between heterogeneous access networks that support IEEE 802.21). There is no need for the HOKEY WG to work on the same thing as 802.21a. 802.21/hokey integration needs to address media-specific things, but IETF is not the right forum to address media-specific things. I suggest HOKEY people who are proposing this work item in HOKEY to attend 802.21a meeting first.
Tim Polk: We have to make sure we are doing complementary, not redundant work. If 802.21a doing it already, we shouldn't do it. However, we should advocate use mof the mechanisms we have devised in Hokey with 802.21a. We must be thoughtful before we leap forward.
Glen: was very popular on mailing list
9. NAS interactions (Tom Taylor presenting)
Samuel Mizikovsky (ALU) commented that this was a topic completely outside Hokey. This sort of thing is done now but is access-technology-dependent
---------------------------------------------------------------------------------------------
Meeting minutes of hokey meeting on Wednesday, July 29th, IETF-75
- how many people were in the meeting on Monday?
Most
- two presentations by Glen
RFC 5296 revisions: 3-4 people had read it.
- few problems in 5296. Glen isn't sure how it got past the WG.
- explicit bootstrapping requires going back to the home AAA server
for no good reason. Not a trust or security issue
- it's a mistake.
- visited has signaled to home that it supports ERP.
- response will has DS-RK
- explicit bootstrapping is to find out what the local domain name is
- RFC has the messages going to the home AAA server.
- SHOULD be able to go to a local ERP server, which has the keys
- mobile domain is able to provide the keys
- problems that it causes is when home AAA is unreachable, ERP doesn't
work
Tim: this looks like a fairly significant change. Was expecting to
see a line at the mike, but there have been no concerns. Have people
seen this as a problem, or is there no operational experience with ERP?
Glen: key deriviation is a big change.
Simon: discover of local domain, only system that specified ERP was in
3GPP2, all AAA signaling was going through NAS to AAA proxy. Signaling
domain of AAA server that was ERP was distributed to NAS through layer
2. It has never been deployed, and has been deprecated. No practical
experience with it.
Lionee: more general question: ensure backwards compatibility, or
deprecate previous version?
Glen: depends on extent of changes. Asking that restrictions on
explicit bootstrapping be relaxed, which will not break compatibility.
Changes to key derivation will break compatibility, but if no one has
deployed it, who cares.
Q: are there benefits if we relax this restrictions?
Glen: it will speed things up
Q: if we have NAS handover, we need to do authentication as fast as
possible. if client doesn't know location of ERP server, it could delay
authentication. It's a matter of architecture
Sebastian: plan to relax explicit bootstrapping but we can still do it?
Yoshi: can local domain name be advertised by lower layers?
Glen: yes. In that case, you would not need to do explicit
bootstrapping. It only comes into play when the mobile does not know
what domain it's in.
-----
Glen: presentation #2 AAA components (with slides!)
Planned to go over each and every charter item... but will not do it.
Plan is to just go through items, talk about them as much as
necessary,get an advisory hum about the idea of chartering. Will take
it all to the list.
- not convinced that work we need to get done will get done in RADEXT
or DIME. Not a lot of progress
- cochair of dime asked to bring it to dime, but it's better to be
done in hokey
Hannes: glen delayed the work... already have 5 authors on the document
- RADIUS: needs security, (see slides)
- DIME has security and application support
- need someone with clear understanding of hokey, AAA less important
- proposal to develop AAA support for hokey in hokey, encourage
reviews by radext, dime, AAA doctors
Hannes: disagrees with Glens summary.
Tim: these things will get discussed further. The ADs have work to
do. If work is moving forward, we don't want it to change WGs, but we
do want to make sure that work gets done. This shouldn't be discussed
on the list, but is a coordination issue that chairs && ADs can work on.
Glen: is surprised by Hannes remarks. Glen stated on the DIME list
that the architecture document would be part of the hokey rechartering.
Tim: We're at the end of this topic
Glen: last 10 minutes of general recharting discussion
Tom: I think there's work to do
Tim: it appears that the architecture document would make a
significant difference in encouraging adoption.
Glen: discussion of proposed new charter items.
Group hum on general question of rechartering
Lionel: Q of organization. How will we prioritize the work, to be
sure that we have clear guidelines and targets.
Glen: would you be in favor of continuing the WG with one or more items
that have come up in the past few days.
Hum: in favor.
no "anti" hums.
Tim: would people be willing to edit and/or review items on the list
Room: 10-11 people willing