Subject: Re: [HOKEY]change of AAA domains: EMSK Hierarchy Changes

From: Charles Clancy <[email-masked]>
Date: Thu, 01 Feb 2007 16:58:25 -0500

Madjid,

Might be okay -- can you draw it?

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

Madjid Nakhjiri wrote:
> If I understand what is Yoshi is saying, it makes sense:
> 
> You do an initial authentication to home AAA/EAP server, get an EMSK and if
> you are in domain X, get an X-EMSK and H-EMSK (for your home domain).
> Now, you move to new AAA domain (domain Y), you re-authentication to the
> home AAA (using your Re-Auth key that is probably derived from H-EMSK) and
> get an Y-EMSK.
> I think we should require a re-authentication with home AAA, whenever we
> move to a new AAA domain, plus we need to hit the home AAA to get the
> Y-EMSK.
> 
> What do people think?
> 
> R,
> 
> Madjid
> 
> 
> 
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 4:27 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [HOKEY] EMSK Hierarchy Changes
> 
> On Thu, Jan 25, 2007 at 04:01:18PM -0800, Narayanan, Vidya wrote:
>>  
>>
>>> -----Original Message-----
>>> From: Yoshihiro Ohba [mailto:[email-masked]] 
>>> Sent: Thursday, January 25, 2007 2:51 PM
>>> To: Narayanan, Vidya
>>> Cc: Glen Zorn (gwz); Yoshihiro Ohba; Charles Clancy; [email-masked]
>>> Subject: Re: [HOKEY] EMSK Hierarchy Changes
>>>
>>> So upon change of a AAA domain, re-authentication all the way 
>>> to the home AAA is needed.  This means that EMSK re-key 
>>> happens and all EMSK child keys are re-keyed for each domain 
>>> change.  Then what is the problem with the current hierarchy?
>>>
>> I am not sure if I understand that. Upon movement out of a domain served
>> by a given local server (not necessarily a AAA domain change), a
>> re-authentication to the home server is needed. At that point, an EMSK
>> is not derived - only a new EMSK-server_new is derived. 
> 
> This would mean that the scope of authorization of the initial EAP
> authentication is for network access from all AAA domains that has
> roaming relationship with the home AAA domain, and that is why you are
> saying that EMSK is not re-keyed.  However, this seems to be
> contradicting to the fact that re-authentication all the way to the
> home AAA is needed for change of a AAA domain.
> 
> Yoshihiro Ohba
> 
> 
> 
> 
>> Vidya
>>
>>> Yoshihiro Ohba
>>>
>>> On Thu, Jan 25, 2007 at 02:30:51PM -0800, Narayanan, Vidya wrote:
>>>> I didn't think there is any change to the authorization 
>>> scope with the 
>>>> proposed change - it is just allowing a symmetric key hierarchy 
>>>> irrespective of which domain it is derived for.
>>>>
>>>> Vidya
>>>>
>>>>> -----Original Message-----
>>>>> From: Glen Zorn (gwz) [mailto:[email-masked]]
>>>>> Sent: Thursday, January 25, 2007 1:28 PM
>>>>> To: Yoshihiro Ohba; Charles Clancy
>>>>> Cc: [email-masked]
>>>>> Subject: RE: [HOKEY] EMSK Hierarchy Changes
>>>>>
>>>>> Yoshihiro Ohba <mailto:[email-masked]> allegedly 
>>> scribbled 
>>>>> on Thursday, January 25, 2007 1:21 PM:
>>>>>
>>>>>> I think this issue relates to authorization scope.  The 
>>> proposed 
>>>>>> change seems to assume that the scope of authorization 
>>> made by the 
>>>>>> home AAA server is for network access from different AAA domains
>>>>>> under the same roaming agreement.   
>>>>> Perhaps the explanation of the hierarchy is not clear enough
>>>>> -- I don't thing that it implies anything like that.
>>>>>
>>>>>> On the other hand, in existing AAA deployment, the scope of 
>>>>>> authorization is for network access from a specific AAA
>>>>> domain only,
>>>>>> and re-authentication all the way to the home AAA 
>>> server cannot be 
>>>>>> avoided when the authorization scope changes due to a change of 
>>>>>> AAA domain.  So I am not sure what problem the proposed change
>>>>> is trying
>>>>>> to solve.  Are we also trying to change the existing 
>>> authorization
>>>>>> model for roaming?      
>>>>>>
>>>>>> Yoshihiro Ohba
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 24, 2007 at 07:31:29PM -0500, Charles Clancy wrote:
>>>>>>> At the interim meeting, there was consensus to make 
>>> the following 
>>>>>>> changes to the EMSK keying hierarchy:
>>>>>>>
>>>>>>> Currently, it looks like:
>>>>>>>
>>>>>>> EMSK --+-- USRK1
>>>>>>>        +-- USRK2
>>>>>>>        \-- USRK3
>>>>>>>
>>>>>>> The proposed change is to make it look like:
>>>>>>>
>>>>>>> EMSK --+-- EMSK-Server1 --+-- Server1-USRK1
>>>>>>>        |                  \-- Server1-USRK2
>>>>>>>        +-- EMSK-Server2 --+-- Server2-USRK1
>>>>>>>        |                  \-- Server2-USRK1
>>>>>>>        \-- EMSK-Home -----+-- Home-USRK1
>>>>>>>                           \-- Home-USRK2
>>>>>>>
>>>>>>> The advantage here is that the home EAP server can distribute 
>>>>>>> server-specific EMSKs to servers throughout the 
>>> network.  These 
>>>>>>> servers can then derive USRKs without having to
>>>>> communicate with the
>>>>>>> home EAP server.  The home EAP server can distribute a key
>>>>> to a local
>>>>>>> keying server, which can then generate USRKs for use
>>>>> within its own
>>>>>>> network.
>>>>>>>
>>>>>>> --
>>>>>>> t. charles clancy, ph.d.  <>  [email-masked]  <>
>>>>> www.cs.umd.edu/~clancy
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>
>>
> 
> _______________________________________________
> 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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 1 Feb 2007 14:14:10 -0800

Charles Clancy <mailto:[email-masked]> allegedly scribbled on
Thursday, February 01, 2007 1:58 PM:

>> You do an initial authentication to home AAA/EAP server, get an EMSK
>> and if you are in domain X, get an X-EMSK and H-EMSK (for your home
>> domain). 
>> Now, you move to new AAA domain (domain Y), you re-authentication to
>> the home AAA (using your Re-Auth key that is probably derived from
>> H-EMSK) and get an Y-EMSK. I think we should require a
>> re-authentication with home AAA, whenever we move to a new AAA
>> domain, plus we need to hit the home AAA to get the Y-EMSK. 

I think that, stripped of the possibly unintentional obfuscating
introduction of a non-existent strong link between authorization and
authentication, it is exactly what we were talking about in SJ.  I don't
recall anybody suggesting that a full EAP authentication would not be
required as a part of entrance into a new network domain, nor that the
EMSK-derived HOKEY re-auth key would be valid in multiple domains.  

>>> I am not sure if I understand that. Upon movement out of a domain
>>> served by a given local server (not necessarily a AAA domain
>>> change), a re-authentication to the home server is needed. At that
>>> point, an EMSK is not derived - only a new EMSK-server_new is
>>> derived. 
>> 
>> roaming relationship with the home AAA domain, and that is why you
>> are saying that EMSK is not re-keyed.  However, this seems to be
>>>>> I didn't think there is any change to the authorization scope
>>>>> with the proposed change - it is just allowing a symmetric key
>>>>> hierarchy irrespective of which domain it is derived for.
>>>>> 
>>>>> Vidya
>>>>> 
>>>>>> scribbled on Thursday, January 25, 2007 1:21 PM:
>>>>>> 
>>>>>>> I think this issue relates to authorization scope.  The proposed
>>>>>>> change seems to assume that the scope of authorization made by
>>>>>>> the home AAA server is for network access from different AAA
>>>>>>> domains under the same roaming agreement.
>>>>>>> authorization is for network access from a specific AAA domain
>>>>>>> only, and re-authentication all the way to the home AAA server
>>>>>>> cannot be avoided when the authorization scope changes due to a
>>>>>>> change of AAA domain.  So I am not sure what problem the
>>>>>>> proposed change is trying to solve.  Are we also trying to
>>>>>>> change the existing authorization model for roaming? 
>>>>>>> 
>>>>>>> Yoshihiro Ohba
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> At the interim meeting, there was consensus to make the
>>>>>>>> following changes to the EMSK keying hierarchy:
>>>>>>>> 
>>>>>>>> server-specific EMSKs to servers throughout the network.  These
>>>>>>>> servers can then derive USRKs without having to communicate
>>>>>>>> with the home EAP server.  The home EAP server can distribute
>>>>>>>> a key to a local keying server, which can then generate USRKs
>>>>>>>> for use within its own network. 
>>>>>>>> 
>>>>>>>> --

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 16:59:55 -0800

Well, as a non-native English speaker, trying to understand the X-tuple
negatives in your first statement, I think you want to put the separation of
authentication and authorization out of the discussion, so I will do:)

Now, if I am hearing the rest ok, you are saying entering a new domain you
can well require a full EAP authentication. Then I don't understand why were
people suggesting creating multiple per-domain EMSKs from the initial auth?

Anyway, my suggestion was not that the same EMSK-derived HOKEY re-auth key
would be valid for multiple domain. What I was saying is that if you move
across domains and require new per-domain EMSK to do your business in the
new domain, you first have to re-authenticate (implied from your statement
full auth, mine: may be a fast re-auth) with the HOME server based on a key
that is available only at the home server.

Maybe this is more clarified in my upcoming response to Charles;)

R,

Madjid

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 17:31:40 -0800

Hi Charles,

We might have passed each other, but this is what it would look like, using
your latest chart. I thought naming the key for inter-domain handover
re-auth (with the home) as RK for domainchange, would be better. Note that I
had to go off EMSK, not HRK in the home domain to achieve near-symmetry.

EMSK (*.*) -+- home (*.home) -----+- USRK (service1.home)
             |                     \- HRK (handoff.home)
		 |				\-RK(domainchange.home)
             \- domainX (*.domainX) -+- USRK (service2.domainX)
                                     \- HRK (handoff.domainX)

The peer has to reauthenticate with the home (using RK) to get a new EMSK
for the new domain and trigger the delivery of that EMSK to the new domain.

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 1:58 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Narayanan, Vidya'; [email-masked]
Subject: Re: [HOKEY]change of AAA domains: EMSK Hierarchy Changes

Madjid,

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 15:44:36 -0500 (EST)

Madjid,

What is a domain-specific EMSK?  The keys "home (*.home)" and "domainX
(*.domainX)" represent domain-specific root keys (DSRK?) derived from the
initial EMSK.  These keys can be used to derive domain-specific HRKs.  You
don't need to re-auth when you switch domains -- just re-key (i.e. have
the local AAA server derive an HRK from its domain key).

Having said that, I don't see the purpose of the RK.  It's scope is just
for the home domain, so I'm not sure how you could use it to bootstrap a
move to another domain.

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

On Thu, February 1, 2007 8:31 pm, Madjid Nakhjiri wrote:
>>> served

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 02 Feb 2007 12:56:29 -0800

Hi Charles,

"What is domain-specific EMSK?"
What ever you want to call it, EMSK junior, etc. It is the key off the EMSK
for each domain. You want to call it DSRK, I am ok with that. A lot of
energy on this discussion is spent on terminology, while people are saying
the same things.
However, when you switch domains (re-key in your terminology, I don't like
the term "rekey" because there is no key to begin with in that domain, hence
"re" does not mean anything to me), how does the new domain gets the DSRK
(see the pic)?
It has to go back to the initial server (EAP server) with the EMSK to get it
and that is why you need a re-auth with the initial server that did the
first EAP. That is why it belongs to home domain. Having said that you are
right, I lifted the RK one level up to the EMSK junior level:)

		    /- RK(domainchange.home)
		   |
 EMSK (*.*) -+- home (*.home) -----+- USRK (service1.home)
              |                     \- HRK (handoff.home)
              \- domainX (*.domainX) -+- USRK (service2.domainX)
              |                        \- HRK (handoff.domainX)
		   \new domain??	

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 12:45 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Narayanan, Vidya'; [email-masked]
Subject: RE: [HOKEY]change of AAA domains: EMSK Hierarchy Changes

Madjid,

---

From: "Charles Clancy" <[email-masked]>
Date: Fri, 2 Feb 2007 16:03:26 -0500 (EST)

Madjid,

I think the terminology has converged.

How exactly do you intend to use the RK?  That will affect wehre it shoudl
live in the hierarchy.

Personally, I think the DSRK/LSRK/EMSKjr/DS-EMSK can be proactively
distributed, so it's already there when you get to the visited domain.  If
not, the local AAA server can request it.  Of course, this gets into the
whole 2/3-party model discussion of whether that key can be distributed
without the peer's consent.

On Fri, February 2, 2007 3:56 pm, Madjid Nakhjiri wrote:
>> re-auth (with the home) as RK for domainchange, would be better. Note
>> that
>> I
>>> and
>> if
>>> the

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 05 Feb 2007 22:14:12 -0800

Hi Charles,

Please see inline.

Regards,

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 1:03 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Narayanan, Vidya'; [email-masked]
Subject: RE: [HOKEY]change of AAA domains: EMSK Hierarchy Changes

Madjid,

Madjid>>Oh, I guess, had I seen this email, I would not need to write the
previous one.

Madjid>>The peer would initiate some sort of signaling with home, including
some info about the visited domain (visisted server ID, etc) and uses RK to
sign the request and in effect do a re-auth with home. This way, when
visited domain server ID can be included in DSRK generation for the new
domain DSRK.

Personally, I think the DSRK/LSRK/EMSKjr/DS-EMSK can be proactively
distributed, so it's already there when you get to the visited domain. 

Madjid>>The devil is in the timing of the signaling, IMO. I don't think it
is impossible.

 If

Madjid>>that is a traditional never-ending mobility debate: peer controlled
or network controlled. Right now, my gut feeling is that we end up doing
both ways.