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 11:21:22 -0800 (PST)

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. 

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.

Michaela

----- Original Message ----
From: Dan Harkins <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Friday, February 1, 2008 5:16:42 PM
Subject: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

<snip>

  
- 
The 
aforementioned 
rationale 
begs 
the 
question 
of 
why 
have

"Domain 
Specific 
Keys". 
If 
the 
peer 
doesn't 
care 
whether 
proxies

have 
a 
key, 
potentially 
for 
a 
different 
domain, 
then 
it 
doesn't

care 
about 
key 
separation 
between 
domains. 
This 
is 
significant

added 
complexity 
for 
no 
benefit.

<snip>

      ____________________________________________________________________________________
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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Feb 2008 12:10:15 -0800 (PST)

Hi Michaela,

> achieve some separation between two service providers, in order to

  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.

  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.

  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).

> -- well worth the one extra layer in the hierarchy IMO. It would be too

  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.

  regards,

  Dan.