Chairs : Glen Zorn (gwz@net-zen.net)
Tina Tsou (tena@huawei.com)
Jabber : hokey@jabber.ietf.org
URL : http://tools.ietf.org/wg/hokey/
Minutes : Version 0.1 (DRAFT); edited
by Glen Zorn from notes by Tom Taylor and Sebastien Decugis
Meeting : IETF 79; Beijing, China
Date : TUESDAY, November 9, 2010
Time : 13:00-15:00
Location:
Jade 1
Glen
Zorn
The
draft has been submitted to the IESG for publication and is in Tim Polk’s
queue.
EAP
Extensions for EAP Re-authentication Protocol (ERP)
Qin Wu
Some open
issues remain. Revised after last meeting.
Issue 1: ERP with one ER
server vs. ERP with multiple servers
-----------------------------------------------------------------
Qin thinks two ER servers
is over-design. Case 4 on his slide is the problem.
Sebastien questions
whether Case 3 exists; clarified. Sebastien maintains that Case 4 is required
because explicit bootstrapping cannot work with Case 3 at a time later than
initial authentication -- key is signed by the home domain and cannot be
verified by the local ER server. Discussion taken to the list.
Issue 2:
-----------------------------------
Tom Taylor:
Seems reasonable.
EAP
Extensions for EAP Early Authentication Protocol (EEP)
Hao
Wang
Goal: support inter-AAA-realm handover
Qin Wu: already supported easily with
other draft
Presenter: I continue and you will see the
differences
Direct vs. indirect models:
Qin
Wu:
Indirect
is not interesting for IETF
Presenter:
I
will show my idea and get feedback
New model presented
Qin
Wu:
Terminology
issue
First problem
Glen Zorn:
This
model allows roaming between two networks that have no relationship with the
home network ? It is a
bad idea and probably illegal
Remarks
Glen
Zorn:
Problem
raised with trust relationship with home domain.
Lionel
Morand:
All AAA servers have the
info about the clients?
What
is the relation with home domain?
Sebastien Decugis:
Discussing
authorization maybe does not belong to HOKEY
Tom Taylor:
[Comment
not recorded]
ERP
Improvements
·
Sebastien Decougis
Glen Zorn:
Could we get rid of the distinction between rRk and DS-rRk?
Assume that "implicit bootstrapping" always
takes place.
Derive the key the same way every time, send it back the
same way every time.
Distinction
makes no sense.
Sebastien:
Doesn't know the local domain name to derive
the DS-rRk.
Glen:
Seems like a security issue if a remote party can use a key
derived based on
the home domain name
Qin:
Need to have home and local because of the dependency on domain
name (different issue)
On chart "Second
change problem statement":
Note that DS-rRK can only be derived by the EAP Server itself,
since it is the only
holder of the EMSK. Not a question of collocated functions.
Handover
Keying (HOKEY) Architecture Design
Tom Taylor
"logical" i.e. "signaling" architecture
Lionel Morand:
How does it fit with discussion about so-called "home ER
server" ?
Tom:
Clarification is certainly required here, given the contents of
previous presentations.
Tom:
What is missing?
Qin Wu:
Maybe not add new models like new EEP.
Lionel Morand:
Rechartering of HOKEY was due to clarification requests.
We need these clarifications, we should focus on it.
Sebastien Decugis:
Keep the deployment scenarii as
examples to help understanding (appendix)
Add the message flow & timing, it might be useful.
Tom Taylor:
OK, will try to do that.