Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

From: "M. Vanderveen" <[email-masked]>
Date: Mon, 4 Feb 2008 12:34:02 -0800 (PST)

Thanks for the comments Dan, some responses follow.

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: M. Vanderveen <[email-masked]>
Cc: Dan Harkins <[email-masked]>; [email-masked]
Sent: Monday, February 4, 2008 12:10:15 PM
Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for      EAP Re-authentication Protocol (ERP)) to Proposed Standard

Hi 
Michaela,

On 
Mon, 
February 
4, 
2008 
11:21 
am, 
M. 
Vanderveen 
wrote:
Hello 
Dan,
Regarding 
DSRKs 
below:
You 
mention 
that 
the 
key 
hierarchy 
as 
it 
stands 
would 
be
simplified 
with 
the 
removal 
of 
DSRKs. 
The 
ERP 
solution 
"accommodates
roaming" 
as 
required 
by 
the 
charter 
but 
without 
DSRKs 
it 
is 
not 
in 
line
with 
the 
"spirit" 
of 
roaming 
if 
I 
may 
call 
it 
that; 
roaming 
should
achieve 
some 
separation 
between 
two 
service 
providers, 
in 
order 
to
simplify 
their
BLA.

I 
believe 
the 
peer 
must 
perform 
a 
full 
authentication 
back 
to 
the
home 
AAA 
server 
when 
establishing 
connectivity 
at 
some 
new 
service
provider. 
That 
still 
allows 
"roaming" 
(as 
the 
term 
is 
commonly 
used 
today
for 
things 
like 
mobile 
phones) 
and 
there 
is 
key 
separation 
because 
the
key 
derived 
from 
the 
EMSK 
for 
ER 
purposes 
will 
be 
unique 
for 
that 
domain.
If 
the 
peer 
goes 
to 
a 
different 
domain, 
or 
goes 
home, 
it 
will 
do 
another
full 
authentication 
back 
to 
its 
home 
AAA 
server 
and 
get 
a 
completely
different 
key 
that 
is 
unique 
for 
that 
new 
domain.

MCV>> The operational scenario you describe is correct. What I mean by "every
time a new service is needed" is the scenario where a new application is to be deployed,
and also operationally, whenever the peer decides it wants to launch a new application 
needing such keys. Ideally the peer should not have to decide on which apps it's going
to want to run today in this visited domain at the very time of the initial, full home authentication. 
The peer should have the freedom to request keys from the local domain as needed.

I 
don't 
see 
a 
reason 
for 
using 
one 
root 
(EMSK) 
and 
binding 
in 
domain-
specific 
information 
into 
derived 
keys 
to 
support 
different 
domains. 
It
doesn't 
seem 
to 
serve 
a 
purpose 
and 
complicates 
things. 
It's 
much 
better
to 
have 
distinct 
roots 
(EMSKs) 
for 
each 
domain.

MCV>> I have been supportive (along with some other folks not involved in this list right now)
the idea of domain-specific keys since about 2002 and at that time we were going to use
the MSK. Much progress has been made since then as this use of MSK is now clearly "bad".
I would be ok with distinct roots for each domain, as it is in line with the intent of roaming,
save for the fact that the EAP spec is already in place and already defined only one root key
for future use. Right now hokey being the "future use" we have no choice but to start from here.

I 
have 
heard, 
"you 
can 
choose 
to 
do 
a 
full 
authentication 
if 
you 
want
to" 
but 
that 
is 
not 
justification 
for 
having 
this 
added 
complexity. 
I
still 
have 
to 
support 
the 
complexity, 
it 
is 
just 
pointless. 
What 
I 
have
not 
heard 
is 
a 
real 
justification 
for 
having 
a 
single 
root 
(EMSK) 
and
supporting 
domain-specific 
branches 
off 
it. 
Every 
justification 
("key
separation", 
"because 
it's 
needed") 
applies 
just 
as 
well 
to 
having
distinct 
root 
keys 
(EMSKs).

Most 
importantly, 
DSRKs 
allow 
for 
flexibility 
and
scalability, 
in 
that 
new 
local 
usage 
keys 
can 
be 
derived 
if/when 
needed
without
bothering 
the 
home 
domain. 
Enabling 
this 
feature 
now 
will 
be 
beneficial
later
-- 
well 
worth 
the 
one 
extra 
layer 
in 
the 
hierarchy 
IMO. 
It 
would 
be 
too
painful
to 
add 
them 
in 
later.

If 
and 
when 
they 
are 
needed 
they 
can 
be 
defined 
by 
the 
particular
requirement 
that 
prompted 
that 
need. 
I 
don't 
know 
what 
the 
pain 
would 
be
for. 
A 
real 
need 
doesn't 
exist 
now. 
Maybe 
there 
will 
be 
one 
in 
the 
future
but 
there 
are 
no 
guarantees 
that 
what 
we 
craft 
up 
now 
will 
even 
be
suitable 
for 
the 
need 
when 
it 
arises. 
It 
might 
have 
to 
come 
up 
with
something 
else 
altogether. 
I 
think 
it's 
better 
to 
just 
keep 
this 
as
simple 
as 
possible 
today.
MCV>> I think this is still the best we can do given the constraints of the existing
EAP specification. The vision is still there, I would not say that there is no real need.

regards,

Dan.

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

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