Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying MITM:EMSKHierarchy Changes

From: "M. Vanderveen" <[email-masked]>
Date: Thu, 15 Feb 2007 14:04:27 -0800 (PST)

Removed AD from the list to save bw :-).

Speaking about arguments for DSRKs: To me the best one is that introducing new apps is faster and less painful if we only have to update one server (the local one); having to update the home server for it to agree how to derive this new key for Use Y would be downright impossible. 

Does anyone really know what a real-world business-to-business SLA looks like, and whether they two parties are satisfied with it. I would have thought that the desire is to simplify it; e.g. let the user do streaming services, or not. Data services, or not. Perhaps it's much more complicated than that: as Madjid seems to be saying, every app A to Z must be agreed upon between two ISPs. 

One thing I have seen that you mention Madjid, is inter-domain handoff, e.g. as I understand it from adm domain X to adm domain Y, while the home domain is H. I think there is consensus that the home domain must be involved. It does not appear that anyone is proposing handing off from X to Y w/o involving H. So that's not an issue. 

The proposal to work on one domain at a time sounds like a fine goal at first but then once you start drawing out the hierarchy you realize that it will be very hard to add visited domains as an afterthought. I for one could not do this cleanly.  

Michaela

----- Original Message ----
From: Madjid Nakhjiri <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>
Cc: Sam Hartman <[email-masked]>; [email-masked]; Madjid Nakhjiri <[email-masked]>
Sent: Thursday, February 15, 2007 1:40:21 PM
Subject: RE: [HOKEY] why visited domains?? Channel binding/ lying MITM:EMSKHierarchy Changes

Hi Lakshminath,

I am not going to respond line by line. I think I have given enough
consideration to the discussions already. BTW, If you had not snipped
through my email, you would see more explanation:

" The best arguments I heard on DSRKs was to have a symmetry on the key
hierarchy, so that both visited and home domain key hierarchies look the
same."
I already provided an answer to this argument.

To me handing a key to a different domain should be based on a specific
service, as roaming agreements are SLA specific. No operator will agree to
give all kinds of service to a user just because he is authenticated to a
home domain. In Dallas BoF people already indicated that tying EAP and
access service to other services suffers from a skewed business assumption
of having all services coming from the same provider, if we could not get
that pass IESG, how do you expect allowing "a visited domain to do anything
it want and then charge it to home domain" go through?

All along we have been arguing for having USRKs directly below EMSK. This
has the longest history in IETF, starting from AMSK specs off of EAP Keying.
The AMSK or USRK spec was supposed to deal with use of EMSK in generating
keys for a generic use case, not to deal with roaming.

Adding a completely new level between EMSK and USRK just to serve roaming
purposes seems excessive for usages that do not care about roaming.
Especially when the identity exchanges and channel binding is required to
make sure the keys are properly scoped to a proper domain, things get even
more complicated.

As for the charter, visited domain is chartered to be dealt with a later
date and as a separate deliverable, please look at the charter. Both first
and final drafts are separate and that was designed exactly with these
issues in mind.

Finally the decision was supposed to be discussed at the mailing list, this
is IETF procedure. We are already seeing both implicit and explicit
disagreements with this hierarchy.

Madjid  

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:30 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying
MITM:EMSKHierarchy Changes

Madjid Nakhjiri wrote:
> Hi Michaela,
>
> I don't quite understand.  Why is working on a single domain is a 
> "roundabout" way? It is the most common case and it is less complex. 
> Quoting famous old timers: "Complexity can amplify small perturbations"
> 
> Also why do you think removing DSRK (which seems to be an unnecessarily 
> inflated necessity!) out of the key hierarchy causes the lack of root 
> keys, you just remove one level and derive the HRK (as a USRK) directly 
> from EMSK.

Madjid,

Domain specific root keys is not an inflated anything.  It is in the 
charter and we all took a step back and looked at all the requirements 
and agreed that the key hierarchy would look better if we took all the 
requirements into consideration.

Think about this: the simplest way to support efficient reauthentication 
would be to use the EMSK as the root of the hierarchy, but that is 
clearly the wrong way to approach the problem.  There might be other use 
cases for the EMSK and so we have "usage" based "level" introduced into 
the hierarchy.  Likewise "domains" is another level introduced into the 
hierarchy (no need to repeat the case for it).  Given that we are going 
to support "domain-specific" derivation and "usage-specific" derivation, 
the DSRK key hierarchy is the most logical.

<snip>

> 
> Where as we are sacrificing the whole service authorization model and 
No we are *not* sacrificing the "whole service authorization model."  A 
domain gets a key and manages its services.  Sounds perfectly logical to me.
> overseeing signaling (need for exchange of identities and consents for 
I am confused by the above phrase.  What are we overseeing?  And who 
needs to consent to what?
> handovers) and security issues (channel binding). Plus that I don't see 
> how you can do cross-domain handovers without consent of home domain and 
> there goes the symmetry out the door as well.

A domain specific key has been handed out to the domain by the home and 
so there is "consent."  What are you looking for beyond that and under 
what threat model.  Please explain!  TIA.

> Finally, I have to go to every venue and say look to get keys for usage 
> XYZ, now you have to implement EAP, implement this complicated EMSK 
> hierarchy, derive per-domain keys and finally you get to your use case 
> root key, and that is just too hard of sell.

Like I said, the hierarchy is no more complex than it needs to be!

> So yes, lets go through that decision again.

So we go through decisions how many times?  Do you want the work to be 
done quickly or not?

regards,
Lakshminath

> R,
> Madjid

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

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

____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Feb 2007 20:49:35 -0500

On Thu, Feb 15, 2007 at 02:04:27PM -0800, M. Vanderveen wrote:

(snip)

> The proposal to work on one domain at a time sounds like a fine goal at first but then once you start drawing out the hierarchy you realize that it will be very hard to add visited domains as an af…

On the other hand, if we consider variety of AAA deployments, it is
also very hard to add visited domains at the beginning.  This is a
natural consequence because with DSRK you are trying to solve a harder
problem that has more AAA aspects than handover optimization.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 12:36:28 -0800

Yes, the real world business SLA do not say, give WHATEVER service you want
to my clients, it has specific QoS parameters, availability, etc tied to a
specific service. SLAs are transformed into Service level specifications
that are even more specific. 

And yes, home domain needs to always be involved which breaks the claimed
symmetry.

No offense, but it can actually be done cleanly as follows:-)

The middle ground might actually be simple, how about this suggestion, 

The current USRK is as follows:

USRK = KDF(EMSK, key label, optional data, length)

The optional data field is supposed to include usage specific data (that can
cover application specific data). Why can't that data include server ID.

Actually I I had included the AAA server ID in the HRK derivation in my
hokey hierarchy draft (I guess I was pretty forward looking then), simply to
bind the key to the AAA server.

HRK=HRK-PRF (EMSK, "Handover Root key derivation" | EAP session ID |

   Key_ID | AAA server ID)

Lets not argue the other parameters (I know EAP session ID is an optional
output of EAP server, so we can replace it with Peer ID, if we want), but
the point is inclusion of AAA server ID and that means by including
different server IDs, you can get different USRKs for the same usage but for
different domains.

This way you don't have to have a new level in the hierarchy for every use
case, just to deal with roaming, but you would have multiple USRKs for
multiple domains and you do have to go back to home server to get those.

I think this is a less complex hierarchy that also achieves multi-domain
operation and channel binding without compromising the service models in the
roaming agreements.

R,

Madjid

  _____  

From: M. Vanderveen [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 2:04 PM
To: Madjid Nakhjiri; Lakshminath Dondeti
Cc: [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying
MITM:EMSKHierarchy Changes

Speaking about arguments for DSRKs: To me the best one is that introducing
new apps is faster and less painful if we only have to update one server
(the local one); having to update the home server for it to agree how to
derive this new key for Use Y would be downright impossible. 

Does anyone really know what a real-world business-to-business SLA looks
like, and whether they two parties are satisfied with it. I would have
thought that the desire is to simplify it; e.g. let the user do streaming
services, or not. Data services, or not. Perhaps it's much more complicated
than that: as Madjid seems to be saying, every app A to Z must be agreed
upon between two ISPs. 

One thing I have seen that you mention Madjid, is inter-domain handoff, e.g.
as I understand it from adm domain X to adm domain Y, while the home domain
is H. I think there is consensus that the home domain must be involved. It
does not appear that anyone is proposing handing off from X to Y w/o
involving H. So that's not an issue. 

The proposal to work on one domain at a time sounds like a fine goal at
first but then once you start drawing out the hierarchy you realize that it
will be very hard to add visited domains as an afterthought. I for one could
not do this cleanly.  

Michaela

----- Original Message ----
From: Madjid Nakhjiri <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>
Cc: Sam Hartman <[email-masked]>; [email-masked]; Madjid Nakhjiri
<[email-masked]>
Sent: Thursday, February 15, 2007 1:40:21 PM
Subject: RE: [HOKEY] why visited domains?? Channel binding/ lying
MITM:EMSKHierarchy Changes

Hi Lakshminath,

Madjid  

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:30 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying

Madjid,

<snip>

regards,
Lakshminath

 

  _____  

Food
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=39654
5367>  fight? Enjoy some healthy debate
in the Yahoo!
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=39654
5367>  Answers Food & Drink Q&A.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 16 Feb 2007 12:53:45 -0800

Hi Madjid,
I don't understand - are you saying that each domain's HRK is its own
USRK? If so, that would be along the lines of the current model in the
EMSK hierarchy draft. However, the main point is that there are multiple
"usages" within each domain for providing local services to a given peer
and the local server must not have to go to the home server to fetch a
USRK for each of those usages. That is why having a domain-level key
from the EMSK instead of the usage-level key is helpful. 
 
May be I didn't understand your point here... 
 
Vidya

________________________________

	From: Madjid Nakhjiri [mailto:[email-masked]] 
	Sent: Friday, February 16, 2007 12:36 PM
	To: 'M. Vanderveen'; Dondeti, Lakshminath
	Cc: [email-masked]; 'Madjid Nakhjiri'
	Subject: RE: [HOKEY] combine USRK and DSRK??why visited
domains??

	Yes, the real world business SLA do not say, give WHATEVER
service you want to my clients, it has specific QoS parameters,
availability, etc tied to a specific service. SLAs are transformed into
Service level specifications that are even more specific. 

	And yes, home domain needs to always be involved which breaks
the claimed symmetry.

	The middle ground might actually be simple, how about this
suggestion, 

	The optional data field is supposed to include usage specific
data (that can cover application specific data). Why can't that data
include server ID.

	Actually I I had included the AAA server ID in the HRK
derivation in my hokey hierarchy draft (I guess I was pretty forward
looking then), simply to bind the key to the AAA server.

	HRK=HRK-PRF (EMSK, "Handover Root key derivation" | EAP session
ID |

	   Key_ID | AAA server ID)

	Lets not argue the other parameters (I know EAP session ID is an
optional output of EAP server, so we can replace it with Peer ID, if we
want), but the point is inclusion of AAA server ID and that means by
including different server IDs, you can get different USRKs for the same
usage but for different domains.

	This way you don't have to have a new level in the hierarchy for
every use case, just to deal with roaming, but you would have multiple
USRKs for multiple domains and you do have to go back to home server to
get those.

	I think this is a less complex hierarchy that also achieves
multi-domain operation and channel binding without compromising the
service models in the roaming agreements.

	R,

	Madjid

________________________________

	From: M. Vanderveen [mailto:[email-masked]] 
	Sent: Thursday, February 15, 2007 2:04 PM
	To: Madjid Nakhjiri; Lakshminath Dondeti
	Cc: [email-masked]; Madjid Nakhjiri
	Subject: Re: [HOKEY] why visited domains?? Channel binding/
lying MITM:EMSKHierarchy Changes

	Speaking about arguments for DSRKs: To me the best one is that
introducing new apps is faster and less painful if we only have to
update one server (the local one); having to update the home server for
it to agree how to derive this new key for Use Y would be downright
impossible. 

	Does anyone really know what a real-world business-to-business
SLA looks like, and whether they two parties are satisfied with it. I
would have thought that the desire is to simplify it; e.g. let the user
do streaming services, or not. Data services, or not. Perhaps it's much
more complicated than that: as Madjid seems to be saying, every app A to
Z must be agreed upon between two ISPs. 

	One thing I have seen that you mention Madjid, is inter-domain
handoff, e.g. as I understand it from adm domain X to adm domain Y,
while the home domain is H. I think there is consensus that the home
domain must be involved. It does not appear that anyone is proposing
handing off from X to Y w/o involving H. So that's not an issue. 

	The proposal to work on one domain at a time sounds like a fine
goal at first but then once you start drawing out the hierarchy you
realize that it will be very hard to add visited domains as an
afterthought. I for one could not do this cleanly.  

	Michaela

	----- Original Message ----
	From: Madjid Nakhjiri <[email-masked]>
	To: Lakshminath Dondeti <[email-masked]>
	Cc: Sam Hartman <[email-masked]>; [email-masked]; Madjid
Nakhjiri <[email-masked]>
	Sent: Thursday, February 15, 2007 1:40:21 PM
	Subject: RE: [HOKEY] why visited domains?? Channel binding/
lying MITM:EMSKHierarchy Changes

	Hi Lakshminath,
	
	I am not going to respond line by line. I think I have given
enough
	consideration to the discussions already. BTW, If you had not
snipped
	through my email, you would see more explanation:
	
	" The best arguments I heard on DSRKs was to have a symmetry on
the key
	hierarchy, so that both visited and home domain key hierarchies
look the
	same."
	I already provided an answer to this argument.
	
	To me handing a key to a different domain should be based on a
specific
	service, as roaming agreements are SLA specific. No operator
will agree to
	give all kinds of service to a user just because he is
authenticated to a
	home domain. In Dallas BoF people already indicated that tying
EAP and
	access service to other services suffers from a skewed business
assumption
	of having all services coming from the same provider, if we
could not get
	that pass IESG, how do you expect allowing "a visited domain to
do anything
	it want and then charge it to home domain" go through?
	
	All along we have been arguing for having USRKs directly below
EMSK. This
	has the longest history in IETF, starting from AMSK specs off of
EAP Keying.
	The AMSK or USRK spec was supposed to deal with use of EMSK in
generating
	keys for a generic use case, not to deal with roaming.
	
	Adding a completely new level between EMSK and USRK just to
serve roaming
	purposes seems excessive for usages that do not care about
roaming.
	Especially when the identity exchanges and channel binding is
required to
	make sure the keys are properly scoped to a proper domain,
things get even
	more complicated.
	
	As for the charter, visited domain is chartered to be dealt with
a later
	date and as a separate deliverable, please look at the charter.
Both first
	and final drafts are separate and that was designed exactly with
these
	issues in mind.
	
	Finally the decision was supposed to be discussed at the mailing
list, this
	is IETF procedure. We are already seeing both implicit and
explicit
	disagreements with this hierarchy.
	
	Madjid  
	
	-----Original Message-----
	From: Lakshminath Dondeti [mailto:[email-masked]] 
	Sent: Wednesday, February 14, 2007 3:30 PM
	To: Madjid Nakhjiri
	Cc: 'Sam Hartman'; [email-masked]
	Subject: Re: [HOKEY] why visited domains?? Channel binding/
lying

	Madjid,
	
	Domain specific root keys is not an inflated anything.  It is in
the 
	charter and we all took a step back and looked at all the
requirements 
	and agreed that the key hierarchy would look better if we took
all the 
	requirements into consideration.
	
	Think about this: the simplest way to support efficient
reauthentication 
	would be to use the EMSK as the root of the hierarchy, but that
is 
	clearly the wrong way to approach the problem.  There might be
other use 
	cases for the EMSK and so we have "usage" based "level"
introduced into 
	the hierarchy.  Likewise "domains" is another level introduced
into the 
	hierarchy (no need to repeat the case for it).  Given that we
are going 
	to support "domain-specific" derivation and "usage-specific"
derivation, 
	the DSRK key hierarchy is the most logical.
	
	<snip>
	
	> Where as we are sacrificing the whole service authorization
model and 
	No we are *not* sacrificing the "whole service authorization
model."  A 
	domain gets a key and manages its services.  Sounds perfectly
logical to me.
	> overseeing signaling (need for exchange of identities and
consents for 
	I am confused by the above phrase.  What are we overseeing?  And
who 
	needs to consent to what?
	> there goes the symmetry out the door as well.
	
	A domain specific key has been handed out to the domain by the
home and 
	so there is "consent."  What are you looking for beyond that and
under 
	what threat model.  Please explain!  TIA.
	
	> root key, and that is just too hard of sell.
	
	Like I said, the hierarchy is no more complex than it needs to
be!
	
	> So yes, lets go through that decision again.
	
	So we go through decisions how many times?  Do you want the work
to be 
	done quickly or not?
	
	regards,
	Lakshminath

	

________________________________

	Food fight?
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTE
wOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&s
id=396545367>  Enjoy some healthy debate
	in the Yahoo! Answers Food & Drink Q&A.
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTE
wOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&s
id=396545367>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 16 Feb 2007 13:17:06 -0800

Yes, it would be along the lines of the current EMSK draft, since that model
has been around in IETF for quite some time and for a good reason.

If the peer is going to be charged for the service by the visited domain.
The visited domain has no relationship with the peer and gets its money from
the home domain within a couple of days. The home domain pays before getting
money from the peer, so you bet it cares about the usage. This is the
reality of roaming agreements today, I suggest you guys check it out:-)

Madjid

  _____  

From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 12:54 PM
To: Madjid Nakhjiri; M. Vanderveen; Dondeti, Lakshminath
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

Hi Madjid,

I don't understand - are you saying that each domain's HRK is its own USRK?
If so, that would be along the lines of the current model in the EMSK
hierarchy draft. However, the main point is that there are multiple "usages"
within each domain for providing local services to a given peer and the
local server must not have to go to the home server to fetch a USRK for each
of those usages. That is why having a domain-level key from the EMSK instead
of the usage-level key is helpful. 

Vidya

  _____  

Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

   Key_ID | AAA server ID)

R,

Madjid

  _____  

Michaela

----- Original Message ----
From: Madjid Nakhjiri <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>
Cc: Sam Hartman <[email-masked]>; [email-masked]; Madjid Nakhjiri
<[email-masked]>

Hi Lakshminath,

Madjid  

-----Original Message-----
From: Lakshminath Dondeti [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:30 PM
To: Madjid Nakhjiri
Cc: 'Sam Hartman'; [email-masked]
Subject: Re: [HOKEY] why visited domains?? Channel binding/ lying

Madjid,

<snip>

regards,
Lakshminath

 

  _____  

Food

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Feb 2007 13:49:27 -0800

Madjid Nakhjiri wrote:
> Yes, it would be along the lines of the current EMSK draft, since that 
> model has been around in IETF for quite some time and for a good reason.
> 

What if the peer is not going to be charged?

> The visited domain has no relationship with the peer and gets 
> its money from the home domain within a couple of days. The home domain 
> pays before getting money from the peer, so you bet it cares about the 

Payments may not apply in this case, as I noted above, but your word 
"before" caught my attention.  There are pre-paid models you know.  So, 
all I am saying is there are models you know, there are models I know, 
there are models someone in this working group know and there are models 
no one knows (with apologies to Don Rumsfeld).

If we keep an open mind, we can solve the problem in a generic manner 
(no, I am not talking about boiling the ocean!), within reasonable 
limits.  Like I noted in my other email, the context aspect that Russ 
defined can be used here.

regards,
Lakshminath

> usage. This is the reality of roaming agreements today, I suggest you 
> guys check it outJ
> 
>  
> 
> Madjid
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Narayanan, Vidya [mailto:[email-masked]]
> *Sent:* Friday, February 16, 2007 12:54 PM
> *To:* Madjid Nakhjiri; M. Vanderveen; Dondeti, Lakshminath
> *Cc:* [email-masked]
> *Subject:* RE: [HOKEY] combine USRK and DSRK??why visited domains??
> 
>  
> 
> Hi Madjid,
>

---

From: Charles Clancy <[email-masked]>
Date: Mon, 19 Feb 2007 21:30:31 -0500

Madjid, Yoshi,

I'd like to point out that inclusion of the DSRK neither requires 
delegating authorization to a visited AAA domain, nor the existence of a 
visited AAA server.

If a visited AAA server does not exist, or a home EAP server does not 
wish to delegate USRK authorization authority to a visited domain due to 
an SLA, it can generate a DSRK for a particular domain, and simply not 
distribute it.  Services in the visited domain would request USRKs 
directly from the home EAP server, and they would be generated from the 
cached DSRK.

Including the DSRK in the keying hierarchy simply adds the flexibility 
to support visited AAA servers and delegated USRK authorization 
authority, if the deployment supports it and wants it.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

Madjid Nakhjiri wrote:
> If the peer is going to be charged for the service by the visited 
> domain. The visited domain has no relationship with the peer and gets 
>     *From:* Madjid Nakhjiri [mailto:[email-masked]]
>     *Sent:* Friday, February 16, 2007 12:36 PM
>     *To:* 'M. Vanderveen'; Dondeti, Lakshminath
>     *Cc:* [email-masked]; 'Madjid Nakhjiri'
>     Yes, the real world business SLA do not say, give WHATEVER service
>     you want to my clients, it has specific QoS parameters,
>     availability, etc tied to a specific service. SLAs are transformed
>     into Service level specifications that are even more specific.
> 
>      
> 
>     And yes, home domain needs to always be involved which breaks the
>     claimed symmetry.
> 
>      
> 
>     No offense, but it can actually be done cleanly as followsJ
> 
>     The optional data field is supposed to include usage specific data
>     (that can cover application specific data). Why can’t that data
>     include server ID.
> 
>     Actually I I had included the AAA server ID in the HRK derivation in
>     my hokey hierarchy draft (I guess I was pretty forward looking
>     then), simply to bind the key to the AAA server.
> 
>      
> 
>     optional output of EAP server, so we can replace it with Peer ID, if
>     we want), but the point is inclusion of AAA server ID and that means
>     by including different server IDs, you can get different USRKs for
>     the same usage but for different domains.
> 
>      
> 
>     This way you don’t have to have a new level in the hierarchy for
>     every use case, just to deal with roaming, but you would have
>     multiple USRKs for multiple domains and you do have to go back to
>     home server to get those.
> 
>      
> 
>     *From:* M. Vanderveen [mailto:[email-masked]]
>     *Sent:* Thursday, February 15, 2007 2:04 PM
>     *To:* Madjid Nakhjiri; Lakshminath Dondeti
>     *Cc:* [email-masked]; Madjid Nakhjiri
>     *Subject:* Re: [HOKEY] why visited domains?? Channel binding/ lying
>     Speaking about arguments for DSRKs: To me the best one is
>     that introducing new apps is faster and less painful if we only have
>     to update one server (the local one); having to update the home
>     server for it to agree how to derive this new key for Use Y would be
>     downright impossible.
> 
>      
> 
>     Does anyone really know what a real-world business-to-business SLA
>     looks like, and whether they two parties are satisfied with it. I
>     would have thought that the desire is to simplify it; e.g. let the
>     user do streaming services, or not. Data services, or not. Perhaps
>     it's much more complicated than that: as Madjid seems to be saying,
>     every app A to Z must be agreed upon between two ISPs.
> 
>      
> 
>     The proposal to work on one domain at a time sounds like a fine goal
>     at first but then once you start drawing out the hierarchy you
>     <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367>
>     Enjoy some healthy debate
>     <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367>
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 20 Feb 2007 00:33:05 -0500

Charles,

> directly from the home EAP server, and they would be generated from the 

Isn't this adding more complexity?  In fact, the peer would need to
know whether the DSRK is being hold by the home domain or by the
visited domain, if we consider not only key management but also AAA
aspect.

> authority, if the deployment supports it and wants it.

I believe the flexibility can be justisfied only if it does not add 
too much complexity.

I have the following AAA related issues on DSRK.  I think those issues
need to be addressed.

- How can the home AAA server can enforce re-auth when required while
the peer is in the visited domain?

- When re-auth happens, how can the peer know whether a re-auth needs
to go to the home domain or the visited domain?

- How can the peer know which source of authentication and
authorization to be used for which service?

- When entering the visited domain, the peer performs EAP with home
domain and then it may perform another EAP with the visited domain to
get another service specific to the visited domain soon after the peer
enters the visited domain.  The authenticator may refuse the second
EAP because the peer is asking re-auth far before the authorization
lifetime of given by the home domain is expired.

- How can the home AAA server know with which AAA server in the
visited domain to communicate if there is no AAA proxy in the visited
domain?

- How can the home AAA server know with which AAA server in the
visited domain to communicate if there is one or more intermediate
domains between the home domain and the visited domain?

- How can the peer and authenticator maintain two different
authorization lifetimes posed by two different sources of
authorization?

- How can backwards compatibility be guaranteed if home domain
supports EMSK/DSRK while visited domain does not?

Regards,
Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 20 Feb 2007 08:58:26 -0800

Hi Charles,

First, caching the DSRK at the home domain to create USRKs from it and then
distribute USRKs to visited domains is different from what we have been
hearing: "the visited domain gets the DSRK would do whatever it wants with
the key". 

Second, if the visited domain still would have to request visited
domain-USRK (VUSRK) from the home domain, then why not generate VUSRK from
USRK for that service? That is what I have been suggesting. The context is
defined by USRK and the scope would be bound to visited domain through
VUSRK.
Why create a DSRK then? With DSRK, You are not saving any signaling here.
Service model is all messed up and you are forcing an unnecessary level in
hierarchy.

Lets not forget that so far we have not even been able to sell the idea of
adding a level to key hierarchy to any SDO, how can we sell the idea of two
levels, one of which messes up the service models?

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 6:31 PM
To: Madjid Nakhjiri
Cc: 'Narayanan, Vidya'; 'M. Vanderveen'; 'Dondeti, Lakshminath';
[email-masked]
Subject: Re: [HOKEY] combine USRK and DSRK??why visited domains??

Madjid, Yoshi,

>     (that can cover application specific data). Why can't that data
>     include server ID.
> 
specific
5367>
5367>

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 20 Feb 2007 15:20:07 -0500 (EST)

Madjid,

I'm saying that the DSRK could be kept at the home EAP server if there
either wasn't a visited AAA server, or the home EAP server didn't trust
the visited AAA server with the DSRK.  Deployments that wanted to push the
DSRK out to the visited domain could do so.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

On Tue, February 20, 2007 11:58 am, Madjid Nakhjiri wrote:
>>     >  overseeing signaling (need for exchange of identities and
>> consents
>>     for

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 20 Feb 2007 12:32:58 -0800

Hi Charles, 

I understood your point the first time and thus my previous response still
applies.

R,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 12:20 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

Madjid,

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 20 Feb 2007 16:06:18 -0500 (EST)

Sorry, I must have misunderstood what you were getting at.  Let me try again.

I was proposing the idea that DSRKs could optionally be kept at the home
EAP server as a way to address your concerns of situations where we don't
trust visited domains with DSRKs.

I agree that if we were ONLY going to support keeping the DSRK at the home
EAP server, your model would make more sense.  But the idea is that we
also support distributing the DSRK to visited domains, allowing visited
domains to generate USRKs by themselves.

On Tue, February 20, 2007 3:32 pm, Madjid Nakhjiri wrote:
>>> goal
>>> look
>>> authenticated
>>>     to a
>>> EMSK.
>>>     This
>>> EAP
>>>     Keying.
>>> Both
>>>     first
>>> other
>>>     use
>>>     >  Where as we are sacrificing the whole service authorization
>>> model
>> and
>>> model."
>> A
>>>     >  Finally, I have to go to every venue and say look to get keys
>>> for
>>>     usage
>>>     >  hierarchy, derive per-domain keys and finally you get to your
>>> use
>>>     case

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 20 Feb 2007 15:58:35 -0500 (EST)

Overall comment:  The original motivator for using the DSRK is to make the
HRK hierarchy look identical no matter where you are.  I think binding the
domain into the USRK achieves the same thing, but with less complexity.  A
secondary goal has been to allow delegated/faster USRK generation, thus
helping out other domain-specific applications that want USRKs.  Is this
something we really care about?  What are some example use cases?  How
much would their performance suffer if we didn't provide a DSRK?

That being said, I'll try to answer some of Yoshi's questions for how I
could see it all working...

> visited domain, if we consider not only key management but also AAA

The peer wouldn't need to know who held the DSRK, only the service who
wants a USRK.  This could either be accomplished in the protocol or
through configuration.

If there's no visited AAA server, all service servers (e.g. HOKEY server,
etc) would know to contact home EAP servers.  If there is a visited AAA
server, they'd obviously be configured to talk to that instead.  If the
visited AAA server is not trusted with DSRKs, he'd simply proxy key
requests to the home EAP server instead.

> the peer is in the visited domain?

DSRK would have a lifetime associated with it.  When it expires, the
easiest thing to do would be for the peer would do a full EAP
reauthentication and derive a new EMSK.

Allowing re-auth of the DSRK independent of the EMSK is tricky, and should
be avoided IMHO.  Just make lifetime(DSRK)=lifetime(EMSK) and you get the
same security lifetime properties as not using the DSRK.

> to go to the home domain or the visited domain?

The peer doesn't need to know.  It would again be up to the service.  For
example, the HOKEY service should know to whom it should pass the re-auth
credentials.

> authorization to be used for which service?

Again, the peer doesn't need to know.  The service (i.e. HOKEY server)
would need to know if it was configured for a visited or home AAA server.

> lifetime of given by the home domain is expired.

The whole idea is to eliminate the second EAP, and simply reuse the DSRK
cached at the local AAA server.  I'm not sure what the question is here.

> visited domain to communicate if there is no AAA proxy in the visited

Under what circumstances would the home AAA server need to initiate a
conversation with anyone in the visited domain?  If there was no AAA
server or proxy in the visited domain, then individual services would have
to be configured to directly communicate with the home AAA server.  This
sounds like a huge mess, hence why it would be good to have a DSRK cached
locally.

> domains between the home domain and the visited domain?

Again, why does the home AAA server ever want to initiate a conversation
with anyone in the visited domain(s)?

> authorization lifetimes posed by two different sources of

Each key in the hierarchy must have a lifetime less than or equal to the
key above it.  The DSRK has a particular lifetime, and a visited AAA
server cannot distribute USRKs with longer lifetimes.  I don't see it as
two different sources of authorization -- the visited AAA server's
authorization ability is a subset of the home AAA server.  They should
never be in conflict.

> supports EMSK/DSRK while visited domain does not?

This would be configured for each domain.  If a visited domain has a AAA
server and wants to cache DSRKs, and the home AAA server approves, then it
will forward them.  If not, it won't.

Overall, I really don't see any issues.  This is all negotation between
USRK servers (e.g. HOKEY server) and AAA servers.  When the network is
established, you need to configure IP addresses of what AAA
servers/proxies to talk to.  If there's a local server, you configure it
for that, and if not, you need to configure USRK servers to talk all
possible visited AAA servers.  The peer is uninvolved.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 20 Feb 2007 13:52:26 -0800

The "allowing visited domains to generate USRKs by themselves" is the part I
have issues with, it violoates the SLA authorization model. Creating the
visited domain USRK based on USRK that is based on authorized SLA avoids
this issue.  
I also suggested inclusion of domain/context label in generation of USRKs as
a compromise between the two approaches, this way the visited domain can get
its USRK, but I don't know what sort of signaling issues that will cause
yet, it needs further exploration.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 1:06 PM
To: Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

Sorry, I must have misunderstood what you were getting at.  Let me try
again.

---

From: "Charles Clancy" <[email-masked]>
Date: Tue, 20 Feb 2007 18:08:57 -0500 (EST)

What fraction of deployments do you think will be bound by the SLA
authorization model?  I don't mean this question to sound rhetorical -- my
deployment experience consists of a several Cisco APs and FreeRadius.

I agree that your proposal would be a possible compromise, collapsing the
top two layers of the hierarchy into one, and keeping things simple.  It
does have the drawback of not allowing for reduced-latency derivation of
additional USRKs in visited domains.  We, as a working group, need to
decide how important that feature is.

On Tue, February 20, 2007 4:52 pm, Madjid Nakhjiri wrote:
>>> key
>>>>     >  inflated necessity!) out of the key hierarchy causes the lack
>>>> of
>>> root
>>>> into
>>>> home
>>>> to
>>>> be

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 15:31:40 -0800

> Sent: Tuesday, February 20, 2007 3:09 PM
> To: Madjid Nakhjiri
> Cc: [email-masked]
> What fraction of deployments do you think will be bound by 
> the SLA authorization model?  I don't mean this question to 
> sound rhetorical -- my deployment experience consists of a 
> several Cisco APs and FreeRadius.
> 

I've tried to explain in my email on "Local Domain Services, SLAs,
Charging, Keys,Etc." as to why the keying should really be independent
of any SLAs and services. There is really no correlation that I can see
relevant. 

> I agree that your proposal would be a possible compromise, 
> collapsing the top two layers of the hierarchy into one, and 
> keeping things simple.  It does have the drawback of not 
> allowing for reduced-latency derivation of additional USRKs 
> in visited domains.  We, as a working group, need to decide 
> how important that feature is.
> 

Latency reduction is the reason this WG exists. I think it is absolutely
critical that we don't end up defining a model that requires a trip to
the home AAA server every time a local domain USRK is needed. Please, I
encourage everyone to read that email I've referred to above. First of
all, this is not even inter-administrative domains that we are designing
things for - at the very basic level, we are providing an option for a
large provider network to be able to sub-divide their network into
smaller domains and handle faster service keying there. This has nothing
to do with SLAs or charging or any such thing. 

In my view, it would be a huge shortcoming of this group to not take the
appropriate extensible approach to the key hierarchy. I think having the
DSRK-based hiearchy with the option of not distributing the DSRK when
the authorization policies don't support it is a perfectly good balance
here. 

Vidya

> > The "allowing visited domains to generate USRKs by 
> themselves" is the 
> > part I have issues with, it violoates the SLA authorization model. 
> > Creating the visited domain USRK based on USRK that is based on 
> > authorized SLA avoids this issue.
> > I also suggested inclusion of domain/context label in generation of 
> > USRKs as a compromise between the two approaches, this way 
> the visited 
> > domain can get its USRK, but I don't know what sort of signaling 
> > issues that will cause yet, it needs further exploration.
> >
> > Madjid
> >
> > I was proposing the idea that DSRKs could optionally be kept at the 
> > home EAP server as a way to address your concerns of 
> situations where 
> > we don't trust visited domains with DSRKs.
> >
> > I agree that if we were ONLY going to support keeping the 
> DSRK at the 
> > home EAP server, your model would make more sense.  But the idea is 
> > that we also support distributing the DSRK to visited domains, 
> > allowing visited domains to generate USRKs by themselves.
> >
> > --
> >> I understood your point the first time and thus my 
> previous response 
> >> still applies.
> >>
> >> R,
> >>
> >> Madjid
> >>
> >> I'm saying that the DSRK could be kept at the home EAP server if 
> >> there either wasn't a visited AAA server, or the home EAP server 
> >> didn't trust the visited AAA server with the DSRK.  
> Deployments that 
> >> wanted to push the DSRK out to the visited domain could do so.
> >>
> >> --
> >>> First, caching the DSRK at the home domain to create 
> USRKs from it 
> >>> and then distribute USRKs to visited domains is different 
> from what 
> >>> we have been
> >>> hearing: "the visited domain gets the DSRK would do whatever it 
> >>> wants with the key".
> >>>
> >>> domain-USRK (VUSRK) from the home domain, then why not generate 
> >>> VUSRK from USRK for that service? That is what I have been 
> >>> suggesting. The context is defined by USRK and the scope would be 
> >>> bound to visited domain through VUSRK.
> >>> Why create a DSRK then? With DSRK, You are not saving any 
> signaling 
> >>> here.
> >>> Service model is all messed up and you are forcing an unnecessary 
> >>> level in hierarchy.
> >>>
> >>> Lets not forget that so far we have not even been able to 
> sell the 
> >>> idea of adding a level to key hierarchy to any SDO, how 
> can we sell 
> >>> the idea of two levels, one of which messes up the service models?
> >>>
> >>>
> >>>
> >>> Madjid
> >>>
> >>>
> >>> delegating authorization to a visited AAA domain, nor the 
> existence 
> >>> of a visited AAA server.
> >>>
> >>> If a visited AAA server does not exist, or a home EAP server does 
> >>> not wish to delegate USRK authorization authority to a visited 
> >>> domain due to an SLA, it can generate a DSRK for a particular 
> >>> domain, and simply not distribute it.  Services in the visited 
> >>> domain would request USRKs directly from the home EAP server, and 
> >>> they would be generated from the cached DSRK.
> >>>
> >>> Including the DSRK in the keying hierarchy simply adds the 
> >>> flexibility to support visited AAA servers and delegated USRK 
> >>> authorization authority, if the deployment supports it 
> and wants it.
> >>>
> >>> --
> >>>> Yes, it would be along the lines of the current EMSK 
> draft, since 
> >>>> that model has been around in IETF for quite some time and for a 
> >>>> good reason.
> >>>>
> >>>>
> >>>>
> >>>> domain. The visited domain has no relationship with the peer and 
> >>>> gets its money from the home domain within a couple of days. The 
> >>>> home domain pays before getting money from the peer, so 
> you bet it 
> >>>> cares about the usage. This is the reality of roaming agreements 
> >>>> today, I suggest you guys check it outJ
> >>>>
> >>>>
> >>>>
> >>>> Madjid
> >>>>
> >>>>
> >>>>
> >>>> 
> >>>> I don't understand - are you saying that each domain's 
> HRK is its 
> >>>> own USRK? If so, that would be along the lines of the 
> current model 
> >>>> in the EMSK hierarchy draft. However, the main point is 
> that there 
> >>>> are multiple "usages" within each domain for providing local 
> >>>> services to a given peer and the local server must not 
> have to go 
> >>>> to the home server to fetch a USRK for each of those 
> usages. That 
> >>>> is why having a domain-level key from the EMSK instead of the 
> >>>> usage-level key is helpful.
> >>>>
> >>>>
> >>>>
> >>>> derivation in
> >>>> ID
> >>>> |
> >>>>     optional output of EAP server, so we can replace it 
> with Peer 
> >>>> ID, if
> >>>>     we want), but the point is inclusion of AAA server 
> ID and that 
> >>>> means
> >>>>     multi-domain operation and channel binding without 
> compromising 
> >>>> the
> >>>>     *Subject:* Re: [HOKEY] why visited domains?? Channel 
> binding/ 
> >>>> lying
> >>>>     that introducing new apps is faster and less painful 
> if we only 
> >>>> have
> >>>>     while the home domain is H. I think there is 
> consensus that the 
> >>>> home
> >>>>     service, as roaming agreements are SLA specific. No 
> operator will
> >>>>     agree to
> >>>>     of having all services coming from the same 
> provider, if we could
> >>>>     not get
> >>>>     that pass IESG, how do you expect allowing "a 
> visited domain to do
> >>>>     anything
> >>>>     has the longest history in IETF, starting from AMSK 
> specs off 
> >>>> of EAP
> >>>>     Keying.
> >>>>     Adding a completely new level between EMSK and USRK 
> just to serve
> >>>>     roaming
> >>>>     make sure the keys are properly scoped to a proper 
> domain, things
> >>>>     get even
> >>>>     more complicated.
> >>>>
> >>>>     As for the charter, visited domain is chartered to be dealt 
> >>>> with a
> >>> later
> >>>>     >  I don't quite understand.  Why is working on a 
> single domain 
> >>>> is a
> >>>>     >  "roundabout" way? It is the most common case and 
> it is less
> >>> complex.
> >>>>     >  inflated necessity!) out of the key hierarchy causes the 
> >>>> lack of
> >>> root
> >>>>     >  keys, you just remove one level and derive the 
> HRK (as a USRK)
> >>>>     directly
> >>>>     >  from EMSK.
> >>>>
> >>>>     Madjid,
> >>>>
> >>>>     Domain specific root keys is not an inflated 
> anything.  It is 
> >>>> in the
> >>>> introduced
> >>>> are
> >>> going
> >>>>     >  handovers) and security issues (channel binding). 
> Plus that I
> >>>>     don't see
> >>>>     >  how you can do cross-domain handovers without 
> consent of home
> >>>>     domain and
> >>>>     >  Finally, I have to go to every venue and say look to get 
> >>>> keys for
> >>>>     usage
> >>>>     >  hierarchy, derive per-domain keys and finally you get to 
> >>>> your use
> >>>>     case

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 20 Feb 2007 21:46:11 -0800

Hi Vidya,

Do you see a DSRK as an EMSK for a particular domain, in that any
particular key that can be derived from the EMSK can be derived from the
DSRK except that it is localized to a domain?  

I do have some reservations to this approach in that not all the uses
for EMSK have, as of yet, been defined.  Leaving SLAs and Services
behind is it not possible that for a particular usage of the EMSK you
would want to make available a set of usage specific keys to one domain
that is different then the set of keys to another?  (by this I mean not
only differing in domain, but different in what they are used for)

If we get in the habit of passing the DSRK around this becomes somewhat
difficult.  If a new usage wanted to make use of this capability it
would have to do something like this:

EMSK --> DRSK(home) --> USRK ---> SetofURSKD1, SetofURSKD2

Where setofURSKDx is the set of keys for usages allowed to a particular
domain.  

This makes the derivation for usages that requires this differentiation
somewhat awkward.  Note that this probably isn't much of a problem for
keys that should only be used in the home domain since presumably the
client could make these decisions itself. 

I can see the value in delegating a large set of capabilities to a
another domain, however I think there may be usages that do not want to
do this.  Perhaps there are two sets of usages, ones that can be
delegated as a consistent set to a foreign domain and ones that should
not be.   

Joe
> Sent: Tuesday, February 20, 2007 3:32 PM
> To: Charles Clancy; Madjid Nakhjiri
> Cc: [email-masked]
> > authorization model?  I don't mean this question to sound 
> rhetorical 
> > -- my deployment experience consists of a several Cisco APs and 
> > FreeRadius.
> > 
> 
> I've tried to explain in my email on "Local Domain Services, 
> SLAs, Charging, Keys,Etc." as to why the keying should really 
> be independent of any SLAs and services. There is really no 
> correlation that I can see relevant. 
> 
> collapsing 
> > the top two layers of the hierarchy into one, and keeping things 
> > simple.  It does have the drawback of not allowing for 
> reduced-latency 
> > derivation of additional USRKs in visited domains.  We, as 
> a working 
> > group, need to decide how important that feature is.
> > 
> 
> Latency reduction is the reason this WG exists. I think it is 
> absolutely critical that we don't end up defining a model 
> that requires a trip to the home AAA server every time a 
> local domain USRK is needed. Please, I encourage everyone to 
> read that email I've referred to above. First of all, this is 
> not even inter-administrative domains that we are designing 
> things for - at the very basic level, we are providing an 
> option for a large provider network to be able to sub-divide 
> their network into smaller domains and handle faster service 
> keying there. This has nothing to do with SLAs or charging or 
> any such thing. 
> 
> In my view, it would be a huge shortcoming of this group to 
> not take the appropriate extensible approach to the key 
> hierarchy. I think having the DSRK-based hiearchy with the 
> option of not distributing the DSRK when the authorization 
> policies don't support it is a perfectly good balance here. 
> 
> Vidya
> 
> > --
> > >>>>     server for it to agree how to derive this new key 
> for Use Y 
> > >>>> would be
> > >>>>     downright impossible.
> > >>>>
> > >>>>
> > >>>>
> > >>>>     it's much more complicated than that: as Madjid 
> seems to be 
> > >>>> saying,
> > >>>>     and final drafts are separate and that was 
> designed exactly 
> > >>>> with these
> > >>>>     issues in mind.
> > >>>>
> > >>>>     >  Also why do you think removing DSRK (which 
> seems to be an
> > >>>>     unnecessarily
> > >>>>     I am confused by the above phrase.  What are we 
> overseeing?  
> > >>>> And who
> > >>>>     so there is "consent."  What are you looking for 
> beyond that 
> > >>>> and under
> > >>>>     So we go through decisions how many times?  Do you 
> want the 
> > >>>> work to be
> > >>>>     done quickly or not?
> > >>>>
> > >>>>     regards,
> > >>>>     Lakshminath
> > >>>>
> > >>>>     >
> > >>>>     >  R,
> > >>>>     >
> > >>>>     >  Madjid
> > >>>>     >
> > >>>>

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 21 Feb 2007 02:07:44 -0500

I agree with Joe (I think?)

>From a generalization perspective wouldn't you derive USRK from EMSK for a given application and then if that application requires per domain distribution it would derived DUSRK and distribute these?

So we have:

EMSK-->USRK---->DUSRKs(bound to specific domains)
         |
         | <--- Per Application ---------------->

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wed 2/21/2007 12:46 AM
To: Narayanan, Vidya; Charles Clancy; Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??
 
Hi Vidya,

I can see the value in delegating a large set of capabilities to a
another domain, however I think there may be usages that do not want to
do this.  Perhaps thereFrom [email-masked] Wed Feb 21 02:12:07 2007
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??
Date: Wed, 21 Feb 2007 02:07:44 -0500
From: "Avi Lior" <[email-masked]>
To: "Joseph Salowey \(jsalowey\)" <[email-masked]>,
	"Narayanan, Vidya" <[email-masked]>,
	"Charles Clancy" <[email-masked]>,
	"Madjid Nakhjiri" <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.
I agree with Joe (I think?)

>From a generalization perspective wouldn't you derive USRK from EMSK for a given application and then if that application requires per domain distribution it would derived DUSRK and distribute these?

So we have:

EMSK-->USRK---->DUSRKs(bound to specific domains)
         |
         | <--- Per Application ---------------->

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wed 2/21/2007 12:46 AM
To: Narayanan, Vidya; Charles Clancy; Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??
 
Hi Vidya,

Joe
> > > that we also support distributing  are two sets of usages, ones that can be

Joe
> > >>>> domain. The vithe DSRK to visited domains, 
> > >>>sited domain has no relationship with 
> the peer and 
> > >> https://www1>>>> introduced
> > >>> into

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Feb 2007 23:11:36 -0800

Hi Joe, 

> Sent: Tuesday, February 20, 2007 9:46 PM
> Do you see a DSRK as an EMSK for a particular domain, in that 
> any particular key that can be derived from the EMSK can be 
> derived from the DSRK except that it is localized to a domain?  
> 

I don't think this necessarily needs to be the case. For one, a
DSRK-equivalent key can't be derived from a DSRK itself. Also, the
AAA/EAP server may send specific context for which the DSRK may be used,
if the policy dictates that. However, enforcement of such a policy will
still depend on the peer and the local AAA server (just as key lifetime
enforcement by parties using the key, for instance). 

> I do have some reservations to this approach in that not all 
> the uses for EMSK have, as of yet, been defined.  Leaving 
> SLAs and Services behind is it not possible that for a 
> particular usage of the EMSK you would want to make available 
> a set of usage specific keys to one domain that is different 
> then the set of keys to another?  (by this I mean not only 
> differing in domain, but different in what they are used for)
> 
> If we get in the habit of passing the DSRK around this 
> becomes somewhat difficult.  If a new usage wanted to make 
> use of this capability it would have to do something like this:
> 
> Where setofURSKDx is the set of keys for usages allowed to a 
> particular domain.  
> 

I'm not sure I understand the above. I don't understand why there would
be a set of USRKs meant for a different domain derived from DSRK(home).
I agree that there should definitely be no restrictions or correlations
between what USRKs may be derived in each domain. However, I see this as
follows: 

* Home server holds the EMSK; it derives a DSRK(home) and derives any
USRKs needed in the home domain from that key. 

* Upon request for a DSRK (which itself will likely be triggered by the
HOKEY protocol), the home server derives a DSRK from the EMSK and passes
the appropriate context (which may bom with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 23:11:35 -0800
Content-class: urn:content-classes:message
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??
Date: Tue, 20 Feb 2007 23:11:36 -0800
From: "Narayanan, Vidya" <[email-masked]>
To: "Joseph Salowey \(jsalowey\)" <[email-masked]>,
	"Charles Clancy" <[email-masked]>,
	"Madjid Nakhjiri" <[email-masked]>
Cc: [email-masked]

Hi Joe, 

> Sent: Tuesday, February 20, 2007 9:46 PM
> Do you see a DSRK as an EMSK for a particular domain, in that 
> any particular key that can be derived from the EMSK can be 
> derived from the DSRK except that it is localized to a domain?  
> 

I don't think this necessarily needs to be the case. For one, a
DSRK-equivalent key can't be derived from a DSRK itself. Also, the
AAA/EAP server may send specific context for which the DSRK may be used,
if the policy dictates that. However, enforcement of such a policy will
still depend on the peer and the local AAA server (just as key lifetime
enforcement by parties using the key, for instance). 

> I do have some reservations to this approach in that not all 
> the uses for EMSK have, as of yet, been defined.  Leaving 
> SLAs and Services behind is it not possible that for a 
> particular usage of the EMSK you would want to make available 
> a set of usage specific keys to one domain that is different 
> then the set of keys to another?  (by this I mean not only 
> differing in domain, but different in what they are used for)
> 
> If we get in the habit of passing the DSRK around this 
> becomes somewhat difficult.  If a new usage wanted to make 
> use of this capability it would have to do something like this:
> 
> Where setofURSKDx is the set of keys for usages allowed to a 
> particular domain.  
> 

I'm not sure I understand the above. I don't understand why there would
be a set of USRKs meant for a different domain derived from DSRK(home).
I agree that there should definitely be no restrictions or correlations
between what USRKs may be derived in each domain. However, I see this as
follows: 

* Home server holds the EMSK; it derives a DSRK(home) and derives any
USRKs needed in the home domain from that key. 

* Upon request for a DSRK (which itself will likely be triggered by the
HOKEY protocol), the home server derives a DSRK from the EMSK and passes
the appropriate context (which may be * or as granular as a single
service) and the DSRK to the local server. 

* Local server will derive any USRKs from the DSRK it received as needed
and as allowed by the context. 

In all cases, the USRK labels will need to be IANA registered as
currently required by draft-ietf-hokey-emsk-hierarchy. So, while we are
introducing a level of hierarchy (DSRKs), the USRK derivation remains
largely the same, except that it is now derived from the DSRK, instead
of the EMSK directly. 

So, if domains D1 and D2 had Usages U1, U2, U3 and U2, U4, U5
respectively, DSRK1 and DSRK2 (associated with D1 and D2 respectively)
will lead to: 

DSRK1 --> USRK (U1, D1), USRK (U2, D1), USRK (U3, D1)

DSRK2 --> USRK (U2, D2), USRK (U4, D2), USRK (U5, D2) 

All USRKs derived from a given DSRK are limited in scope to that domain
by definition. By this model, the home server will only derive the EMSK,
DSRK for any domains that the peer roams to, DSRK (home) and any USRKs
for the home domain. Any USRK required for a local domain will only be
derived by that local server. In all this, if the context of a DSRK
given out is limited to a single usage, then, the local domain is only
authorized to derive one USRK corresponding to that allowed usage. 

So, the usage of DSRKs seems to allow the granularity to range from
having a model where any number of USRKs may be derived for use within
the local domain to a single USRK. And, this is always a matter of
authorization policy. 

> This makes the derivation for usages that requires this 
> differentiation somewhat awkward.  Note that this probably 
> isn't much of a problem for keys that should only be used in 
> the home domain since presumably the client could make these 
> decisions itself. 
> 

Please see if the above explanation makes sense. 

> I can see the value in delegating a large set of capabilities 
> to a another domain, however I think there may be usages that 
> do not want to do this.  

Absolutely. 

> Perhaps there are two sets of 
> usages, ones that can be delegated as a consistent set to a 
> foreign domain and ones that should
> not be.   
> 

I'm not sure that the home server always needs to know that complete
set. It may know, but, there are scenarios where the home domain really
does not need to be aware of what local services are offered in a given
domain. Take local mobility, for instance - it makes no difference to
the home domain whether or not there is local mobility in the visited
domain; any impact of local mobility is limited to that local domain
(security-wise and otherwise) - so, there is no reason why we need to
require the home domains to know this set of services. But, I can see
that when the home domain does know and care, it may decide to set the
context to be something more specific. 

Thanks,
Vidya

> > of any SLAs and services. There is really no correlation that I can 
> > see relevant.
> > 
> > >e * or as granular as a single
service) and the DSRK to the local server. 

* Local server will derive any USRKs from the DSRK it received as needed
and as allowed by the context. 

In all cases, the USRK labels will need to be IANA registered as
currently required by draft-ietf-hokey-emsk-hierarchy. So, while we are
introducing a level of hierarchy (DSRKs), the USRK derivation remains
largely the same, except that it is now derived from the DSRK, instead
of the EMSK directly. 

So, if domains D1 and D2 had Usages U1, U2, U3 and U2, U4, U5
respectively, DSRK1 and DSRK2 (associated with D1 and D2 respectively)
will lead to: 

DSRK1 --> USRK (U1, D1), USRK (U2, D1), USRK (U3, D1)

DSRK2 --> USRK (U2, D2), USRK (U4, D2), USRK (U5, D2) 

All USRKs derived from a given DSRK are limited in scope to that domain
by definition. By this model, the home server will only derive the EMSK,
DSRK for any domains that the peer roams to, DSRK (home) and any USRKs
for the home domain. Any USRK required for a local domain will only be
derived by that local server. In all this, if the context of a DSRK
given out is limited to a single usage, then, the local domain is only
authorized to derive one USRK corresponding to that allowed usage. 

So, the usage of DSRKs seems to allow the granularity to range from
having a model where any number of USRKs may be derived for use within
the local domain to a single USRK. And, this is always a matter of
authorization policy. 

> This makes the derivation for usages that requires this 
> differentiation somewhat awkward.  Note that this probably 
> isn't much of a problem for keys that should only be used in 
> the home domain since presumably the client could make these 
> decisions itself. 
> 

Please see if the above explanation makes sense. 

> I can see the value in delegating a large set of capabilities 
> to a another domain, however I think there may be usages that 
> do not want to do this.  

Absolutely. 

> Perhaps there are two sets of 
> usages, ones that can be delegated as a consistent set to a 
> foreign domain and ones that should
> not be.   
> 

I'm not sure that the home server always needs to know that complete
set. It may know, but, there are scenarios where the home domain really
does not need to be aware of what local services are offered in a given
domain. Take local mobility, for instance - it makes no difference to
the home domain whether or not there is local mobility in the visited
domain; any impact of local mobility is limited to that local domain
(security-wise and otherwise) - so, there is no reason why we need to
require the home domains to know this set of services. But, I can see
that when the home domain does know and care, it may decide to set the
context to be something more specific. 

Thanks,
Vidya

> > of any SLAs and services. There is really no correlation that I can 
> > see relevant.
> > 
> > absolutely critical that we don't end up defining a model that 
> > requires a trip to the home AAA server every time a local 
> domain USRK 
> > is needed. Please, I encourage everyone to read that email I've 
> > referred to above. First of all, this is not even 
> inter-administrative 
> > domains that we are designing things for - at the very 
> basic level, we 
> > are providing an option for a large provider network to be able to 
> > sub-divide their network into smaller domains and handle faster 
> > service keying there. This has nothing to do with SLAs or 
> charging or 
> > any such thing.
> > 
> not take 
> > the appropriate extensible approach to the key hierarchy. I think 
> > having the DSRK-based hiearchy with the option of not 
> distributing the 
> > DSRK when the authorization policies don't support it is a 
> perfectly 
> > good balance here.
> > 
> > Vidya
> > 
> > > --
> > > >> t. charles clancy, ph.d.  <>  [email-masked]  <>
> > absolutely critical that we don't end up defining a model that 
> > requires a trip to the home AAA server every time a local 
> domain USRK 
> > is needed. Please, I encourage everyone to read that email I've 
> > referred to above. First of all, this is not even 
> inter-administrative 
> > domains that we are designing things for - at the very 
> basic level, we 
> > are providing an option for a large provider network to be able to 
> > sub-divide their network into smaller domains and handle faster 
> > service keying there. This has nothing to do with SLAs or 
> charging or 
> > any such thing.
> > 
> not take 
> > the appropriate extensible approach to the key hierarchy. I think 
> > having the DSRK-based hiearchy with the option of not 
> distributing the 
> > DSRK when the authorization policies don't support it is a 
> perfectly 
> > good balance here.
> > 
> > Vidya
> > 
> > > --
> > > >>>> I don't understan> > www.cs.umd.edu/~clancy
> > > >>
> > > >>>>     *Subject:* RE: [HOKEY] combine USRK and 
> DSRK??why visited 
> > > >>>> domains??
> > > >>>>
> -----------------------------------------------d - are you saying that each domain's
> > > HRK is its
> > > >>>>     *Subject:* RE: [HOKEY] combine USRK and 
> DSRK??why visited 
> > > >>>> domains??
> > > >>>>
> > > >>>>     handoff, e.g. as I understand it from adm domain 
> X to adm 
> > > >>>> domain Y,
> > > >>>>     domain must be involved. It does not appear that 
> anyone is 
> > > >>>> proposing
> > > >>>>     access service to other services suffers fro---------------------
> > > >>> ----
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>     handoff, e.g. as I understand it from adm domain 
> X to adm 
> > > >>>> domain Y,
> > > >>>>     domain must be involved. It does not appear that 
> anyone is 
> > > >>>> proposing
> > > >>>>     >  Quoting famous old timers: "Complexity can 
> amplify small
> > > >>>>     perturbations"
> > > >>>>     >
> > > >>>>     him a
> > > skewed business
> > > >>>>     >  Quoting famous old timers: "Complexity can 
> amplify small
> > > >>>>     perturbations"
> > > >>>>     >
> >erarchy (no need to repeat the case for it).  
> > > Given that we
> > > >>>> are
> > > >>> going

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 20 Feb 2007 23:53:13 -0800

Ahhh, there we have the AAA guru:-)

Thanks Avi,

Madjid

  _____  

From: Avi Lior [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 11:08 PM
To: Joseph Salowey (jsalowey); Narayanan, Vidya; Charles Clancy; Madjid
Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

>From a generalization perspective wouldn't you derive USRK from EMSK for a
given application and then if that application requires per domain
distribution it would derived DUSRK and distribute these?

So we have:

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wed 2/21/2007 12:46 AM
To: Narayanan, Vidya; Charles Clancy; Madjid Nakhjiri
Cc: [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

Hi Vidya,

Joe
> www.cs.umd.edu/~clancy
> > www.cs.umd.edu/~clancy
> > www.cs.umd.edu/~clancy

---

From: Charles Clancy <[email-masked]>
Date: Wed, 21 Feb 2007 08:05:49 -0500

Avi,

Indeed this is certainly one approach.  I see a couple advantages of the 
DSRK over this approach though:

1. Services in need of a USRK can request one from their local AAA 
server, rather than having to communicate with the peer's home AAA 
server (decreases latency).

2. Domain-specific services need only have a trust relationship with 
their local AAA server, rather than requiring trust relationships with 
every possible peer home AAA server (decreases deployment complexity).

3. Services don't need to implement their own key handoff protocols.  In 
the approach you described, each service would require a 
domain-independent server that could cache the USRK and provide DUSRKs 
to service servers in other domains.  When a client moved from one 
domain to another, each cross-domain service would have to independently 
do its own rekeying across domains, which again increases latency.  With 
the DSRK, we can do the key handoff just once.

Avi Lior wrote:
>  >From a generalization perspective wouldn't you derive USRK from EMSK 
> for a given application and then if that application requires per domain

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 21 Feb 2007 09:26:41 -0500

Hi Charles,

I see your points.

I think you still can use the EMSK-USRK model thusly:

In this case the USRK is an Application-Key derived from EMSK to allow domain specific root key from which other application keys can be derived.  That is, at the local access network it acts like an EMSK, a delegated EMSK if you would like.

So we have:

EMSK---DomainSpecificEMSKGen---+---DEMSK(domain1) delivered to domain 1.
          (a USRK)             |
                               +---DEMSK(domain2) delivered to domain 2.
                                      |
                                      +---USRK1(@domain2)
                                      |
                                      +---USRK2 (@domain2)
                                           etc....

This maintains a consistent model.

I don't want the EMSK---USRK derivation to be too complex and have special cases.

Does this work?

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]]
Sent: Wed 2/21/2007 8:05 AM
To: Avi Lior
Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid Nakhjiri; [email-masked]
Subject: Re: [HOKEY] combine USRK and DSRK??why visited domains??
 
Avi,

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 13:11:47 -0500

Charles,

On Tue, Feb 20, 2007 at 03:58:35PM -0500, Charles Clancy wrote:
> HRK hierarchy look identical no matter where you are.  

Actually DSRK matters where the peer is.  Otherwise, the peer should
not even need to know the identifier of the visited domain.  If the
primary goal is to make HRK hierarchy look identical no matter where
the peer is, then DSRK should not be needed.

>I think binding the
> domain into the USRK achieves the same thing, but with less complexity.  

This is one point I don't understand.  I am actually seeing
complexity.  To me, generating DSRK *only if* the key needs to be
distributed to the visited domain makes more sense and less complex.

> much would their performance suffer if we didn't provide a DSRK?

I agree, this secondary goal seems not much important.  We should not
really care about it.  Having said that, what is actually needed for
HOKEY is handing out *HRK* to the visited domain, not DSRK, no?

> wants a USRK.  This could either be accomplished in the protocol or

This does not seem to work.  If the visited domain does not support
the DSRK, the peer may not have any idea about the identifier of the
visited domain.  In other words, if the peer does not need to know who
is holding the DSRK then the peer should not need to know the
identifier of the visited domain at all.

> cached at the local AAA server.  I'm not sure what the question is here.

I think you are assuming that there is the local AAA server is the AAA
signaling path between visited AAA clients and the home AAA server if
visited domain supports DSRK caching.  This seems to be a big
deployment restriction to me.

> sounds like a huge mess, hence why it would be good to have a DSRK cached

I did not mention the case where there is no AAA server.  I only
mentioned the case where there is no AAA proxy.  If there is a AAA
server in the visited domain *without a AAA proxy* (this is a valid
AAA deployment), then I thought DSRK is supposed to held by the local
AAA server if the visited domain supports DSRK.  This means that there
would be a communication between the visited AAA server and home AAA
server.  In this case, visited AAA server may not be on the AAA
signaling path between the visited AAA client and the home AAA server.
In this case, the home AAA server would need to know which visited AAA
server to communicate with.  That is why I asked this question.  The
next question below came up with the same thought.

> authorization ability is a subset of the home AAA server.  They should

Are you saying that once the home AAA server has delegated USRK
authorization authority to the visited domain, then it should not be
possible for the home AAA server and the peer to generate USRKs for
services provided by the home domain?

> will forward them.  If not, it won't.

Again this does not seem to work.  If the visited domain does not
support the DSRK, the peer may not have any idea about the identifier
of the visited domain to generate DSRK.

Regards,
Yoshihioro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 21 Feb 2007 10:36:58 -0800

Hi Avi,
What you describe below is the model we were first going down the path
of pursuing - in other words, there would be a Local Domain Rook Key
which itself would be a USRK - from there, every domain's DSRK (what you
note as DEMSK) would be derived. But, the problem with this is that it
doesn't allow the HOKEY (and USRK) key hierarchy to be symmetrical
between the home and local domains. For instance, this would lead to the
following: 
 
The HOKEY Root Key (HRK, known as the rRK or re-auth root key in
draft-vidya-eap-er) for the home domain will be a USRK, directly from
the EMSK (EMSK-->HRK (a USRK)), while the same for a local domain will
be derived two levels below. Using your diagram below, it would be
EMSK--->DomainSpecificEMSKGen (a USRK) -->DEMSK
(Domain1)-->HRK(domain1). If you see draft-dondeti-eap-vkh, it basically
proposes that (EMSK-->VRK(Visited Root Key)-->VMSK1 (Visited MSK for
Domain1)-->V-rRK (for domain 1)). 

Glen suggested that if the home domain has its own "domain level key",
i.e., say, Domain(Self or Home), we can make the key hierarchies
symmetrical for everything. This has one other advantage that it is
easier to register the labels for USRKs irrespective of the domains,
since, the USRKs will come from the DSRK always. For this, we would have

EMSK --> DSRK (Domain X) --> USRK, where, X could be home or a local
domain. The USRK would be for any usage, including the HRK. 

So, in essence, the introduction of the DSRK adds one level for the home
domain and gets rid of one level for local domains. The end result is a
simpler key hierarchy with ease of USRK label registration. In the end,
both hierarchies would lead to the same result for local domains. With
the symmetry, someone implementing a HOKEY server would not have to do
different things for a home operation vs a local domain operation. For
the purpose of USRKs, the key derivations would always be done the same
way. At the interim meeting, we discussed this and had decided that the
symmetry in key hierarchy was the way to go. 

Hope this helps in providing a snapshot of how we got here. Please share
your thoughts. 

Regards,
Vidya

	From: Avi Lior [mailto:[email-masked]] 
	Sent: Wednesday, February 21, 2007 6:27 AM
	To: Charles Clancy
	Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid
Nakhjiri; [email-masked]
	Subject: RE: [HOKEY] combine USRK and DSRK??why visited
domains??

	Hi Charles,
	
	I see your points.

	In this case the USRK is an Application-Key derived from EMSK to
allow domain specific root key from which other application keys can be
derived.  That is, at the local access network it acts like an EMSK, a
delegated EMSK if you would like.
	
	So we have:
	
	EMSK---DomainSpecificEMSKGen---+---DEMSK(domain1) delivered to
domain 1.
	          (a USRK)             |
	                               +---DEMSK(domain2) delivered to
domain 2.
	                                      |
	                                      +---USRK1(@domain2)
	                                      |
	                                      +---USRK2 (@domain2)
	                                           etc....

	I don't want the EMSK---USRK derivation to be too complex and
have special cases.
	
	Does this work?

	-----Original Message-----
	From: Charles Clancy [mailto:[email-masked]]
	Sent: Wed 2/21/2007 8:05 AM
	To: Avi Lior
	Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid
Nakhjiri; [email-masked]
	Subject: Re: [HOKEY] combine USRK and DSRK??why visited
domains??
	
	Avi,
	
	Indeed this is certainly one approach.  I see a couple
advantages of the
	DSRK over this approach though:
	
	1. Services in need of a USRK can request one from their local
AAA
	server, rather than having to communicate with the peer's home
AAA
	server (decreases latency).
	
	2. Domain-specific services need only have a trust relationship
with
	their local AAA server, rather than requiring trust
relationships with
	every possible peer home AAA server (decreases deployment
complexity).
	
	3. Services don't need to implement their own key handoff
protocols.  In
	the approach you described, each service would require a
	domain-independent server that could cache the USRK and provide
DUSRKs
	to service servers in other domains.  When a client moved from
one
	domain to another, each cross-domain service would have to
independently
	do its own rekeying across domains, which again increases
latency.  With
	the DSRK, we can do the key handoff just once.
	
	--
	t. charles clancy, ph.d.  |  [email-masked]  |
www.cs.umd.edu/~clancy
	
domains??
	> Do you see a DSRK as an EMSK for a particular domain, in that
any
	> I do have some reservations to this approach in that not all
the uses
	> Where setofURSKDx is the set of keys for usages allowed to a
particular
	> This makes the derivation for usages that requires this
differentiation
to a
domains??
domains??
domains??
	>  > > >
	>  > > > Sorry, I must have misunderstood what you were getting
at.
	>  > > Let me try
	>  > > >>> Subject: Re: [HOKEY] combine USRK and DSRK??why
visited
	>  > > >>>> that model has been around in IETF for quite some
time
	>  > and for a
	>  > > >>>> good reason.
	>  > > >>>>
	>  > > >>>>
	>  > > >>>>
	>  > > >>>> If the peer is going to be charged for the service
by
	>  > > >>>> gets its money from the home domain within a couple
of
	>  > days. The
	>  > > >>>> cares about the usage. This is the reality of
roaming
	>  > agreements
-------------------------------------------------------------------
	>  > > >>>> -----
--------------------------------------------------------------------
DSRK??why visited
	>  > > >>>> domains??
	>  > > >>>>
	>  > > >>>>     Yes, the real world business SLA do not say,
give
	>  > > WHATEVER service
	>  > > >>>>     availability, etc tied to a specific service.
SLAs
	>  > > are transformed
	>  > > >>>>     into Service level specifications that are even
more
	>  > > specific.
	>  > > >>>>     The optional data field is supposed to include
usage
	>  > > specific data
	>  > > >>>>     HRK=HRK-PRF (EMSK, "Handover Root key
derivation" |
	>  > > EAP session
	>  > > >>>>     This way you don't have to have a new level in
the
	>  > > hierarchy for
	>  > > >>>>     every use case, just to deal with roaming, but
you
	>  > would have
	>  > > >>>>     multiple USRKs for multiple domains and you do
have
	>  > > to go back to
--------------------------------------------------------------------
	>  > > >>>>     would have thought that the desire is to
simplify
	>  > > it; e.g. let the
	>  > > >>>>     user do streaming services, or not. Data
services,
	>  > > or not. Perhaps
	>  > > >>>>     One thing I have seen that you mention Madjid,
is
	>  > > inter-domain
X to adm
anyone is
	>  > > >>>> proposing
	>  > > >>>>     handing off from X to Y w/o involving H. So
that's
	>  > > not an issue.
	>  > > >>>>
	>  > > >>>>
	>  > > >>>>
	>  > > >>>>     The proposal to work on one domain at a time
sounds
	>  > > like a fine
	>  > > >>>>     Subject: RE: [HOKEY] why visited domains??
Channel
	>  > > binding/ lying
	>  > > >>>>     I am not going to respond line by line. I think
I
	>  > have given
	>  > > >>>> enough
	>  > > >>>>     consideration to the discussions already. BTW,
If
	>  > > you had not
	>  > > >>>>     " The best arguments I heard on DSRKs was to
have a
	>  > > symmetry on
	>  > > >>>> the
	>  > > >>> key
	>  > > >>>>     hierarchy, so that both visited and home domain
key
	>  > > hierarchies
	>  > > >>>>     To me handing a key to a different domain should
be
	>  > > based on a
	>  > > >>>>     home domain. In Dallas BoF people already
indicated
	>  > > that tying
	>  > > >>>>     The AMSK or USRK spec was supposed to deal with
use
	>  > > of EMSK in
	>  > > >>>>     Especially when the identity exchanges and
channel
	>  > binding is
	>  > > >>>>     As for the charter, visited domain is chartered
to
	>  > be dealt
	>  > > >>>> with a
	>  > > >>> later
	>  > > >>>>     date and as a separate deliverable, please look
at
	>  > > the charter.
	>  > > >>>>     Finally the decision was supposed to be
discussed at
	>  > > the mailing
	>  > > >>>>     Subject: Re: [HOKEY] why visited domains??
Channel
	>  > > binding/ lying
amplify small
	>  > > >>>>     and agreed that the key hierarchy would look
better
	>  > > if we took
	>  > > >>>>     the hierarchy.  Likewise "domains" is another
level
	>  > > >>>>     >  XYZ, now you have to implement EAP, implement
this
	>  > > >>>> complicated EMSK
	>  > > >>>>     Like I said, the hierarchy is no more complex
than
	>  > > it needs to be!
--------------------------------------------------------------------
	>  > > >>>>     Food fight?
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0N
	>  > > > TEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid
	>  > > > =39654
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0N
	>  > > > TEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid
	>  > > > =39654
-------------------------------------------------------------------
	>  > > >>>> -----

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 21 Feb 2007 14:15:04 -0500

Hi Vidya,

I will digest this and get back to you all. 

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Wednesday, February 21, 2007 1:37 PM
To: Avi Lior; Charles Clancy
Cc: Joseph Salowey (jsalowey); Madjid Nakhjiri; [email-masked]
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

Hi Avi,

Regards,
Vidya

	Hi Charles,
	
	I see your points.

	
	So we have:

	
	
	Does this work?

	-----Original Message-----
	From: Charles Clancy [mailto:[email-masked]]
	Sent: Wed 2/21/2007 8:05 AM
	To: Avi Lior
	Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid
Nakhjiri; [email-masked]
	
	Avi,

	

	
domains??
any
the uses
particular
differentiation
to a
domains??
domains??
domains??
at.
visited
time
by
of
roaming
DSRK??why visited
give
SLAs
more
usage
derivation" |
the
you
have
simplify
services,
is
X to adm
anyone is
that's
sounds
Channel
I
If
have a
key
be
indicated
use
channel
to
at
discussed at
Channel
amplify small
better
level
this
than

---

From: "T. Charles Clancy" <[email-masked]>
Date: Wed, 21 Feb 2007 17:02:10 -0500 (EST)

> distributed to the visited domain makes more sense and less complex.

I think having DSRK as an optional step in the hierarchy makes things MUCH 
more complicated.  We should only explore choices where the DSRK is always 
there or never there, but sometimes there is bad.

> really care about it.

Others disagree.

> Having said that, what is actually needed for

Within the confines of HOKEY, that is correct.

> identifier of the visited domain at all.

The domain identifier bound to the DSRK would always be included and the 
same, regardless of where the DSRK was cached.

> deployment restriction to me.

I'm not assuming anything in my comment.  Whatever service that required 
the second EAP session could instead request a USRK derived from the 
appropriate DSRK of the first EAP session, regardless of where the DSRK 
was cached.  There's no need for a local AAA server if the DSRK is cached 
at the home EAP server.

> next question below came up with the same thought.

Interesting point.  The home AAA server wouldn't *push* the DSRK anywhere 
by itself.  It would wait for someone to do an EAP-ER bootstrap (for 
example), and that would *pull* the DSRK.

> services provided by the home domain?

Correct, not without the cooperation of the visited AAA server.

> of the visited domain to generate DSRK.

As I mentioned at the begining of my response, the identifier would be the 
same regardless of where the key was cached, so the client wouldn't need 
to know.

Yoshi, I appreciate the discussion -- I think it's brought up some 
interesting points and possible limitations of the DSRK approach.  I guess 
it will come down to what people think the most important features are.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Feb 2007 17:28:58 -0500

> same, regardless of where the DSRK was cached.

My point was that, once we mandate DSRK, the domain identifier always
needs to be known to the peer even if the visited domain does not
support DSRK.  It does not sound a reasonable assumption to me.
(Restriction#1).

> was cached.  There's no need for a local AAA server if the DSRK is cached 

You seem to agree that second EAP is needed in some case (Restriction#2).

> example), and that would *pull* the DSRK.

This seems to be second restriction (Restriction#3).

> Correct, not without the cooperation of the visited AAA server.

This seems to be another restriction to me (Restriction#4).

> it will come down to what people think the most important features are.

Thank you,
Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 21 Feb 2007 15:00:58 -0800

Hi Charles,

I can give the exact number for the fraction, but consider this. Would a
roaming partner allow you to use GPRS in Prague if you are only subscribed
to GSM? 

Speaking as an individual, not as an affiliate to a manufacturer, Why do you
think the operators are so eager to add fancy services while in reality you
sometimes have trouble even making a phone call from your living room? In
fact my provider just told me on Sunday they don't guarantee service inside
the house. Well because the service agreements bring revenue per service,
while fixing a coverage hole does not.

As far as latency involved in deriving USRKs in the visited domain. Lets not
forget we are talking about initial call set up not handovers. Initial set
up delay is widely accepted, that is getting the visited domain USRK. For
handover within the visited domain, the visited domain simply does its own
handover keying. So the latency for handover should not be affected, once
have successful roamed. Thus the feature you are talking about is not worth
the added complexity to the hierarchy for all the people that don't care
about roaming...

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 21 Feb 2007 16:42:06 -0800

Well, I don't quite agree with the "domain independent server part". The EAP
server at the home domain is the entity that creates the USRK (since EMSK
cannot be exported) and passes it down to the AAA layer. Given that EAP
server does not have a direct interface with visited domain AAA server, it
means that the AAA layer actually resides in the home AAA server. This means
the home AAA server can create domain specific USRKs for the visited
domains. And no, I don't necessarily see this as a security violation (no I
don't call this a domino effect, since the subscription profiles are also
stored at the home AAA server and charges for the user are produced.

A little bit of humor: the symmetry of the key hierarchy seems to be a
desired artistic feature, rather than an engineering strive for simplicity:)

Sure per-service key handoff protocol is an issue, but like anything else in
the AAA world, multiple things can be bundled in a single transfer between
the domain AAA servers.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, February 21, 2007 5:06 AM
To: Avi Lior
Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid Nakhjiri;
[email-masked]

Avi,

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 21 Feb 2007 16:47:22 -0800

HI Avi,

Well the proposal that is being debated (Vidya described it in another
email) is slightly different, since it forces you to go through a domain
specific key for every USRK, meaning even the USRK1 (@domain 1 or @domain2)
should come off a domain specific EMSK. This for instance mean for Mobile
IP, you first have to shove a DEMSK between the EMSK and MIP-root-key and my
contention is that it adds too much complexity in a lot of specs.

I have initially proposed domain-USRKs be derived form top USRK, and then I
proposed to add a "domain label" in USRK derivation, so you have a
"domain-use case" specific key at once with only one level in the hierarchy.

R,

Madjid

  _____  

Hi Charles,

I see your points.

In this case the USRK is an Application-Key derived from EMSK to allow
domain specific root key from which other application keys can be derived.
That is, at the local access network it acts like an EMSK, a delegated EMSK
if you would like.

So we have:

I don't want the EMSK---USRK derivation to be too complex and have special
cases.

Does this work?

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]]
Sent: Wed 2/21/2007 8:05 AM
To: Avi Lior
Cc: Joseph Salowey (jsalowey); Narayanan, Vidya; Madjid Nakhjiri;
[email-masked]

Avi,

---

From: Charles Clancy <[email-masked]>
Date: Wed, 21 Feb 2007 21:50:28 -0500

> support DSRK.  It does not sound a reasonable assumption to me.

Any keys provided to any entity of a domain, regardless of how they're 
derived, need context information.  I view the domain as part of that 
context information, so I don't see that as a restriction.  The peer 
always needs to know what domain it's in so it can verify key context.

> You seem to agree that second EAP is needed in some case (Restriction#2).

I think by "second EAP" you're referring to the case where we perform an 
initial EAP authentication in a visited domain, and then need to perform 
a bootstrap to obtain the DSRK/HRK?  Ordinarily you could wait until you 
did a handover/reauth to execute this bootstrap, but if you have 
services in the visited domain that need USRKs you may need to execute 
it sooner in order to obtain the DSRK.  Thus it wouldn't be a "second 
EAP" but rather a premature HOKEY reauth.

I agree that this is a restriction with the current approach.  One 
solution would be to provide a generic, HOKEY-independent, AAA mechanism 
to transport the DSRK (i.e. RADIUS keyreq).  Then any service, including 
HOKEY, could use this to initiate the DSRK transport.  This would 
require no more latency than the service communicating directly with the 
home AAA server, which is the alternative.

> This seems to be second restriction (Restriction#3).

I think this is the same as "(Restriction#2)".

> This seems to be another restriction to me (Restriction#4).

If the visited AAA server has a history of being non-cooperative, then 
the home AAA server can simply not distribute DSRKs to it.

The whole point is to be able to distribute DSRKs if it works in your 
environment.  I agree there are plenty of edge cases, and it won't work 
in every environment.  In those scenarios you can choose not distribute 
it, and get the exact same system properties as an approach that derives 
USRKs directly from the EMSK.

Are there any restrictions that can't be solved by choosing not to 
distribute the DSRK?

---

From: Charles Clancy <[email-masked]>
Date: Wed, 21 Feb 2007 22:01:30 -0500

I agree with your GSM/GPRS example.  However what about networks that 
don't charge you for everything you do (e.g. WiFi)?

People that don't want to delegate authorization can simply not 
distribute the DSRK.  The end result is a system isomorphic to the flat 
D/USRK approach.  I see no added complexity.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Feb 2007 12:08:33 -0500

On Wed, Feb 21, 2007 at 09:50:28PM -0500, Charles Clancy wrote:
(snip)
> Are there any restrictions that can't be solved by choosing not to 

This choice may not be easier considering edge cases relating to AAA
issues, and we yet know whether edge cases can form a non-exhaustive
list or not.  I think that it is a bit risky to rely on this choice at
the highest key hierarchy level.

Yoshihiro Ohba