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

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Mar 2007 23:08:51 -0800

Hi Michaela,

I am catching up with old mail. This is funny. I guess this is the most
interesting motivation I heard for DSRKs: making inter-operator conference
calls short. I hope they are not using third party calling cards to dial
in:-)

Madjid

  _____  

From: M. Vanderveen [mailto:[email-masked]] 
Sent: Thursday, February 22, 2007 9:44 AM
To: Madjid Nakhjiri; Charles Clancy
Cc: [email-masked]; Madjid Nakhjiri
Subject: Re: [HOKEY] combine USRK and DSRK??why visited domains??

Perhaps the "reduced latency" Charles was mentioning refers to the
*introduction* of new services, not the time it takes to derive keys upon
power-up (or on demand).  By not allowing enough control to a domain we are
putting an obstacle in the roadmap to more services. Rapid time-to-market is
a major concern for operators and 3rd party service providers.

The popularity of flat fees, even though scaled by usage, is indicative of a
need for simplification of SLAs. That's why I have a hard time with the
model where a home domain operator has to hold long meetings every time a
visited operator wants to introduce a service, and proceeds to have their
engineers update the home server (authorization and acct'ing too).  General
classes of services should be sufficient -e .g. USA user allowed low
bit-rate streaming (e.g. voice) and voice calls should be allowed similar
services in Prague.  

I recently saw an article about the end of ad-free cell phones... the truth
of that is still to unfold, but that's an indication that "free" services
are about to ensue...by free meaning contaminated with ads...In this case,
subscribing to these should not involve the home domain; yet not giving the
visited domain a key to derive security for such a service does not allow
the visited domain to limit this service to whomever they choose.

Michaela

----- Original Message ----
From: Madjid Nakhjiri <[email-masked]>
To: Charles Clancy <[email-masked]>
Cc: [email-masked]; Madjid Nakhjiri <[email-masked]>
Sent: Wednesday, February 21, 2007 3:00:58 PM
Subject: RE: [HOKEY] combine USRK and DSRK??why visited domains??

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

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

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.

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

On Tue, February 20, 2007 4:52 pm, Madjid Nakhjiri wrote:
> 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.
>
> 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.
>
> --
> t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy
>
> On Tue, February 20, 2007 3:32 pm, Madjid Nakhjiri wrote:
>> 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,
>>
>> 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:
>>> 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,
>>>
>>> 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:
>>>> 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 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,
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>     No offense, but it can actually be done cleanly as followsJ
>>>>
>>>>     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
>>>>
>>>>
>>>>
>>>>     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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>>
>>>>     Food fight?
>>>>
>>>
>>
>
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=39654
>>> 5367>
>>>>     Enjoy some healthy debate
>>>>     in the Yahoo! Answers Food & Drink Q&A.
>>>>
>>>
>>
>
<http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOAR
fcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=39654
>>> 5367>
------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> HOKEY mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>
>>>
>>
>>
>> _______________________________________________
>> HOKEY mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/hokey
>>
>>
>
>
>

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

  _____  

Finding fabulous fares is fun.
Let
<http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9T
Azk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--%0a>
Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.

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