Subject: [HOKEY] EMSK Hierarchy Changes

From: Charles Clancy <[email-masked]>
Date: Wed, 24 Jan 2007 19:31:29 -0500

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Jan 2007 16:21:13 -0500

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.

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

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 25 Jan 2007 13:28:00 -0800

Yoshihiro Ohba <mailto:[email-masked]> allegedly scribbled on
Thursday, January 25, 2007 1:21 PM:

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

>> 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: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 25 Jan 2007 14:30:51 -0800

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:
> 
> Perhaps the explanation of the hierarchy is not clear enough 
> -- I don't thing that it implies anything like that.
> 
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Jan 2007 17:51:24 -0500

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?

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 25 Jan 2007 16:01:18 -0800

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

Vidya

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Jan 2007 19:26:46 -0500

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Jan 2007 14:06:15 -0500

I believe the current hierarchy is the right one.  
Also, I have another suggestion at the bottom.

First, keys for re-auth and re-key should be separated something like:

EMSK --+-- USRK1(=re-key key)
       +-- USRK2(=re-auth key)
       \-- USRK3

The re-key key is for HOKEY re-key which is always used for re-key in
the visited domain (which may be the home domain as well) to cover
intra-domain handover.

The re-auth key is for HOKEY re-authentication which always goes to
home AAA/EAP server, in the same way as legacy EAP re-authentication.
This HOKEY re-authentication covers re-authentication required for a
change of domain as well as for extending the authorization lifetime
of the current authorization scope, again in the same way as legacy
EAP re-authentication.

When a change of domain occurs, re-authentication to the home domain
is performed, which generates a new EMSK and a new re-key key for the
new domain.  An important point is, this re-authentication for
generating the re-key key can be a legacy EAP re-authentication (Case
1) or a HOKEY re-authentication (Case 2).  In Case 1, the re-key key
is derived from the root EMSK which is re-keyed by the legacy EAP
re-authentication.  In Case 2, the re-key key is derived from the
non-root EMSK that is derived from the re-auth key.  In Case 2, root
EMSK is not re-keyed.  The key hierarchy should look like:

EMSK --+-- USRK1(=re-key key for Case 1)
       +-- USRK2(=re-auth key)
       \-- USRK3   |                     
                   +- EMSK --+-- USRK1(=re-key key for Case 2)
                             +-- USRK2
                             \-- USRK3

(Note: we don't need to define multiple re-key keys for different
domains since the EMSK that generates the re-key key has to be
re-keyed by re-authentication for each change of domain.)

What this analysis indicates is that we need to clearly separate
re-authentication and re-key, where these two are currently mixed up
in the entire discussion.  Here is the fact:

A protocol for HOKEY re-key is totally missing piece in the current
system.

A protocol for re-authentication is already available which is known
as EAP re-authentication.  We are discussing development of HOKEY
re-authentication protocol for more optimized re-authentication.

As a result of re-auth/re-key mixed up, we are currently discussing a
single protocol for HOKEY re-key and HOKEY re-authentication.

I believe that the right way to proceed is, we should first discuss
re-key and re-authentication separately to come with a clean and solid
architecture, and then discuss whether it is better to couple HOKEY
re-key and HOKEY re-authentication in a single protocol or not, or
whether we ever need to change EAP to improve re-authentication part
which already exists.

Best Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 Jan 2007 11:33:57 -0800

Yoshi, none of the stuff about rekey and reauth makes sense to me. 
Next, the EMSK hierarchy you have drawn is not what we agreed to at the 
meeting.

At the meeting you've tried to explain rekey and reauth, but that was 
not at all clear.  Please explain clearly what the differences are in 
your mind: goals and requirements would be a good way to start.

As Glen notes there needs to be no difference in the key hierarchies for 
various "domains."

thanks,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Jan 2007 17:44:28 -0500

Lakshminath,

I'd appreciate it if you could make more specific comments 
as I spent a fair amount of time to write my comments.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 Jan 2007 14:55:17 -0800

Yoshi,

I don't mean to be disrespectful, but merely making the point that we've 
had the rekey and reauth discussion and it appears to me that there is 
nothing there, if I may put it that way.

On the EMSK hierarchy itself, Charles has posted what the group agreed 
to, pending discussion on the list.

Given that, I am puzzled by your proposal.  Re-authentication is not 
different whether you go to home domain or not.  If the terminology and 
semantics are confusing, we can work on that.  If you are saying the use 
of the term "authentication" should be reserved for LTC verification, we 
can discuss that (I don't quite agree, but we can talk about it for sure).

If upon changing domains a full authentication is forced by the home 
domain, that is always allowed; no problems there.

So, I for one don't see the value in your proposed terminology or the 
key hierarchy changes.

best regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Jan 2007 21:56:04 -0500

I really think that this is an essential discussion. 

Please see my lengthy response below.

> to, pending discussion on the list.

When this topic was discussed in the meeting, I did not fully
understand the point of the proposed key hierarchy and hence I was
wondering whether I should agree or disagree, and decided to be
silient.  Now I still don't understand the point of the proposed key
hierarchy, and I will explain below why.

> different whether you go to home domain or not.  

In existing deployment, re-authentication always goes to home domain
without an exception.  As far as I understand, HOKEY re-authentication
is supposed to happen within a visited domain as long as the peer
stays within the visited domain.  On the other hand, HOKEY
re-authentication is supposed to go to home domain when the peer moves
to a new domain.  So there is a clear difference between the existing
re-authentication model and HOKEY re-authentication model.  That is
why I suspect if there is something is wrong in the terminology or
architecture.  I further explain this in details below.

> If the terminology and 

With regard to the term authentication, I meant peer entity
authentication that is based on verification of credentials associated
with the peer.  The credentials are long-term credentials for initial
access authentication, but short-term credentials associated with the
LTC could be used for subsequent authentication.  Authentication is
needed for authorizing the peer on a particular usage of network
resources where authenticity of the peer is required to make an
authorization decision.  The authorized usage determines the scope of
authorization.

Once authorization is made, no additional authentication and
authorization should be required as long as the authorization scope of
the peer entity does not change.  On the other hand, authentication
(i.e,. re-authentication) and authorization should be re-executed if
the scope of authorization changes.  In addition, in existing AAA
roaming model, (re-)authentication and authorization has to go to the
home AAA domain of the peer.

If we take a look at HOKEY re-authentication within a visited domain
(which can be a home domain if the peer is in the home domain),
re-authentication signaling between the peer and the HOKEY server in
the visited domain will happen when the peer moves from one
authenticator to another within the visited domain.  There are two
contradictions here.

One contradiction is that the re-authentication is performed within
the visited domain without going to the home domain.  One could argue
that this is not a contradiction by using UMTS AKA example, but it
would be much less contradictive if we consider it as re-key.

The other contradiction is that the re-authentication is performed
while the peer does not change its authorization scope which is
"network access from the visited domain".

In my analysis, HOKEY re-authentication within a visited domain is
actually re-key for which no additional authentication and
authorization is required because the signaling happens without
changing the scope of authorization.

> domain, that is always allowed; no problems there.

HOKEY re-authentication upon changing domains is a different case than
the case of HOKEY re-authentication within a visited domain.  Yes,
HOKEY re-authentication upon changing domains has to be forced by the
home domain.  This is really re-authentication.  And this could be a
full EAP authentication, a method-specific re-authentication or a
HOKEY re-authentication upon changing domains.  Furthermore, if we
agree to allow a full EAP authentication and a method-specific
re-authentication here, then EMSK re-key will happen upon the domain
change for these types of re-authentication, then the additional
hierarchy level (EMSK-Server1 and EMSK-Server2 and EMSK-Home) between
the EMSK and USRKs in the proposed key hierarchy does not make sense
to me.

My whole point is that HOKEY re-authentication within a visited domain
is not really re-authentication, and we should not call it a
re-authentication, it's a re-key.  Re-key does not require
authentication or authorization, it just requires a proof of
possession of a session key that is associated with the authorized
peer in order to secure the re-key procedure.  I don't see any
essential difference from re-keying an IKEv2 CHILD_SA here.

Regards,
Yoshihiro Ohba

---

From: Subir Das <[email-masked]>
Date: Fri, 26 Jan 2007 22:44:47 -0500

I have few basic questions:

-- Are we saying that HOKEY re-authentication is only within the visited 
domain scope?

-- Is HOKEY applicable to within a AAA domain?

-- What is the meaning of authorization in HOKEY context?

-- In  the latest architecture, both EAP and HOKEY servers  send MSK to 
the authenticator. Are they same?

regards,
-Subir

Lakshminath Dondeti wrote:
> Yoshi,
>
> I don't mean to be disrespectful, but merely making the point that 
> we've had the rekey and reauth discussion and it appears to me that 
> there is nothing there, if I may put it that way.
>
> different whether you go to home domain or not.  If the terminology 
> and semantics are confusing, we can work on that.  If you are saying 
> the use of the term "authentication" should be reserved for LTC 
> verification, we can discuss that (I don't quite agree, but we can 
> talk about it for sure).
>
>> I'd appreciate it if you could make more specific comments as I spent 
>> a fair amount of time to write my comments.
>>
>> Yoshihiro Ohba
>>
>>
>>> Next, the EMSK hierarchy you have drawn is not what we agreed to at 
>>> the meeting.
>>>
>>> At the meeting you've tried to explain rekey and reauth, but that 
>>> was not at all clear.  Please explain clearly what the differences 
>>> are in your mind: goals and requirements would be a good way to start.
>>>
>>> As Glen notes there needs to be no difference in the key hierarchies 
>>> for various "domains."
>>>
>>> thanks,
>>> Lakshminath
>>>
>>
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 Jan 2007 19:44:43 -0800

Yoshi,

I started reading your email and immediately found a misunderstanding, 
so I stopped reading.  There are existing authentication systems where 
re-authentication does happen with a visited domain server.  Does that 
alleviate your concerns?

Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 26 Jan 2007 20:07:41 -0800

Well, I read your email anyway, getting past the obviously incorrect 
generalization of "In existing deployment, authentication always goes to 
home domain without an exception."  I found it especially troublesome 
given that you know of the UMTS AKA example.  Of the two purported 
contradictions, you've admitted that the first one is in fact not a 
contradiction.  We will leave it at that.

On your other one
 > "network access from the visited domain".

So, is the problem the fact that we are calling it re-authentication? 
Like others have said at the meeting, we can find a name for it.  But, 
there is another aspect to that we must realize.  The entire operation 
will be so similar to the "full" authentication, it would be disruptive 
to rename it.  We can call it "local" re-authentication perhaps.

The similarities are that the authentication runs via a new 
authenticator.  Channel binding, MSK delivery, proof of possession of 
key material are all requirements.  Also, note that without the HOKEY 
work, although the peer is in a network that it has been authorized to 
connect to via one authenticator, when it moves to another authenticator 
in the same network, a full "authentication" or method specific 
re-authentication is forced upon it.  By your definitions the scope 
hasn't changed.  Was the use of the word re-authentication a misnomer 
there too?

And finally there is the discussion about terminology.  I said a few 
times already, terminology isn't an issue.  We can put an adjective and 
be done.

best wishes for the weekend,
Lakshminath

PS: I have some sympathy for the notion that the term "entity 
authentication" be associated with LTC and rekey for any subsequent key 
material changes based on old key material (the 4-way exchange rekeys 
the TSK for instance).  But, I have been advised at the meeting by 
people who know these things a bit better than me, that that kind of 
semantical discussion is academic.  Nevertheless, I have been advised to 
come up with another name.  I decided it's best to just move on!

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 27 Jan 2007 00:07:15 -0500

Lakshminath,

> to rename it.  We can call it "local" re-authentication perhaps.

This sounds like a solution-oriented naming.  I really have a problem
with it, because authorization aspect is totally ignored and it does
not actually solve the contradiction indicated above.  I am unhappy
with calling it using a word (re-)authentication.  This is not an
academic topic, this is architectural discussion.

> hasn't changed.  Was the use of the word re-authentication a misnomer 

Yes, that is a misnomer for HOKEY-capable lower layer.  Without HOKEY,
there is no additional key hierarchy level and the scope of the
authorization is for network access via a specific authenticator,
which is much smaller than that is defined when HOKEY is used.  With
HOKEY, there is actually no need to perform any authentication for
inter-authenticator handover within the HOKEY scope of authorization.
It just needs re-key.  The fact is that the solution that has been
proposed so far is trying to use EAP for this re-key.

> times already, terminology isn't an issue.  We can put an adjective and 

No, terminology is an issue.  There is a key hierarchy issue as well
as I indicated in my previous response.

> best wishes for the weekend,

You too.

Thanks,
Yoshihiro Ohba

---

From: "Charles Clancy" <[email-masked]>
Date: Mon, 29 Jan 2007 18:41:01 -0500 (EST)

I think the following might clarify what Yoshi's talking about...

It might be very useful to attach authorization scopes and context to
everything in our EMSK keying hierarchy, that way we can make sure we're
not extending a derived key past the scope/context of its parent.   I'm
using the notation (X.Y), where X is the service (context) and Y is the
domain (scope).

Also, I'm going to use "re-auth" to refer to a process that derives a new
EMSK, and "re-key" for deriving anything that results from the EMSK.  The
only way to extend the context/scope of your key is to be re-authorized
from scratch, which would require talking to your home EAP server.  Keys
derived via "re-key" have a scope/context equal to or smaller than their
parent key.

Below are my interpretations:

Current EMSK draft:

EMSK (*.*) -+- USRK1 (service1.*)
            +- USRK2 (service2.*)
            \- HOKEY (rekey.*) -+- homeRoot (reauth.home)
                                 +- visitedRoot1 (rekey.domain1)
                                 \- visitedRoot2 (rekey.domain2)

Problem: Keys derived from any HOKEY process cannot be used for anything
other than re-key within a specific domain, because of their scope and
context.  This means that any USRK requests in visited domains would still
have to travel to the home EAP server.

Proposed changes:

EMSK (*.*) -+- home (*.home)
            +- domain1 (*.domain1)
            \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
                                    +- USRK2 (service2.domain2)
                                    \- HOKEY (reauth.domain2)

This approach solves the above problem, but would require the local
domain's AAA server to cache keys for us.  The local HOKEY server would
request a USRK from the local AAA server.  Requests for local USRKs could
be handled by the local AAA server.

Yoshi, it seems to me that in order to have scope/context work, we need to
make the proposed changes to the EMSK hierarchy.  Or, have I completely
misunderstood your point?  If so, could you specify the problem using the
above notation, including scope and context?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Jan 2007 22:20:28 -0500

Hi Charles,

> using the notation (X.Y), where X is the service (context) and Y is the

First of all, I like this notation very much.

> have to travel to the home EAP server.

I am wondering whether this is really a problem.  Is there any
assumption that any USRK requests in visited domains should not have
to travel to the home EAP server?  I think it all depends on the
actual usage of each USRK.  It does not seem to make sense to discuss
"USRK in visited domains" before defining USRK.

In addition, defining "homeRoot (reauth.home)" as a child key of
"HOKEY (rekey,*)" does not make sense to me.  What is the implication
here?  On the other hand, I think that the reverse relationship is
possible, i.e., defining a re-key key as a descendant of a re-auth
key.

Also, "homeRoot (reauth.home)" should read "homeRoot (reauth.*)" since
the scope is for re-authentication to the home domain from any domain.

Also, defining a re-key root key (i.e., HOKEY (rekey.*)) means that
there must be a mechanism to *re-key* per-domain re-key keys (i.e.,
visitedRoot and visitedRoot2) using the re-key root key.

> be handled by the local AAA server.

This seems to assume that any USRK is defined in per-domain basis.  It
does not make sense to me to make such an assumption before defining
the acutal usage for it.  Also, the proposed hierarchy introduces
general purpose per-domain keys.  I believe defining such keys is a
broader topic (this sounds like a general AAA architecture issue) than
the scope of HOKEY WG.

> above notation, including scope and context?

I still do not see a problem with a current EMSK draft.  Each USRK may
or may not be defined in per-domain basis depending on the actual
usage for it, and hence there must be no implication that any USRK is
in per-domain basis.  How each USRK and its child keys is going to be
used and managed should be out of scope of this WG, except for usages
of USRKs for re-auth and re-key, which should be clearly specified in
this WG.

In fact, I have the following hierarchy in my mind, which is 
based on the a current EMSK draft:

EMSK (*.*) -+- USRK1 (service1.*)
            +- USRK2 (service2.*)
            +- HOKEY1(re-auth.*)
            \- HOKEY2(re-key.*)-+- visitedRoot1 (re-key.domain1)
                                \- visitedRoot2 (re-key.domain2)

HOKEY1(reauth.*) is a re-auth key.  Signaling for re-auth ought to be
based on EAP, but in an optimized way than existing ones.  A new EMSK
is generated by this optimized re-auth and becomes the "effective
EMSK" by overriding the original EMSK that was generated by a full EAP
authentication.  Depending on the authorization policy of the home AAA
server (this is actually one important point), a full EAP
authentication may be used for re-auth, instead of optimized re-auth.
If an otimized re-auth is not used, the EMSK generated by a full EAP
authentication becomes the effective EMSK.

HOKEY2(rekey.*) is a re-key root key which generates per-domain re-key
keys.  A re-key root key is derived from the effective EMSK.  On this
key hierarchy branch, we need to have a key distribution mechanism to
distribute re-key keys to each domain and a re-key mechanism in
visited domains.  We can argue whether those mechanisms ought to be
based on EAP and/or AAA or something else.

I would foresee some counter argument on this.  We can discuss.

Best Regards,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 30 Jan 2007 14:08:57 +0100

Hi Yoshi, Charles

First of all I like the idea of the separation between re-auth and
re-key keys...

However, I have a small question inline regarding HOKEY1 key

>From the * in HOKEY1(reauth.*), I understand that this key is not bound
to any specific domain. From your text, it seems to me that the home AAA
server always holds that key (HOKEY1), is that correct?.

Thanks.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 08:29:16 -0500

Yes, that is correct.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 30 Jan 2007 15:18:50 +0100

> Yes, that is correct.
Ok. Then I was wondering if a local EAP server (co-located with the
local AAA server) could make use of a re-auth key to engage a local EAP
(maybe optimized) re-authentication process. In that case a local EMSK
(and underlying key hierarchy) would be generated instead.
Does it make any sense?.

If yes then HOKEY1 could be a re-auth **root** key instead.

Best Regards.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 09:29:15 -0500

I don't see a need for a local re-auth to create a local EMSK.  Why is
another re-authentication needed within the local domain after
re-authentication to the home domain for the local domain has been
completed?  What is the authorization model?

Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 30 Jan 2007 12:49:09 -0800

Rafa Marin Lopez <mailto:[email-masked]> allegedly scribbled on Tuesday,

> First of all I like the idea of the separation between re-auth and

/WG Chair hat OFF
I'm rather uncomfortable with introducing a new (& IMO, spurious)
element into the architecture, at least in this way.  Claiming that
re-keying and re-authentication are different is one thing, but
conflating authentication & authorization is an entirely different one.
Authorization is a function of policy, which can & does change
independently of authentication status or scope (examples are too
numerous to list here).  I think that we need to think very carefully
about this proposal and how the theory (which I think is unnecessarily
limiting) fits with reality.

...

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 31 Jan 2007 11:33:24 -0800

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

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 31 Jan 2007 12:09:56 -0800

Handovers within the local domain, or extending the existing session..

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 6:29 AM
To: Rafa Marin Lopez
Cc: [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 31 Jan 2007 12:06:12 -0800

I agree. I tried to show this in my late emails:)

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 5:29 AM
To: Rafa Marin Lopez
Cc: [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Yes, that is correct.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 31 Jan 2007 12:04:53 -0800

Hi Charles,

First, coming from AAA world and being deep up to my knees on a Dime
discussion on separation of identity authentication and service
authorization, I am not sure what "authorization scope" means. To me
authorization means being allowed to use a service and the related USRK. I
thought we had a discussion on "scope" versus "context". At least
"authorization context" would make better sense:) In a pure sense of
"authorization", the way the key hierarchy is done now, the home domain
gives complete authorization rights away to the visited domain (but only
within that visited domain) and that was my initial concern on putting USRK
below visited-EMSKs, mind you.

Continuing on that note, as far as re-auth, It all depends on what sort of
re-authentications you are allowing in domain2. Intra-domain re-auths are
possible (and btw they don't lead to new EMSKs as you are saying). I think
intra-domain re-auth operations are ok based on the below hierarchy (you can
use reauth.domain2 key), but inter-domain re-auths are not. Inter-domain
re-auths (when you move out of domain 2), need to be done by contacting home
domain (i.e. the domain for initial EAP and EMSK) and use a re-auth key
(domainreauth.home) derived from either EMSK.home directly or from HRK.home,
but not from domain2-emsk
So either of the following should work

					/-HOKEY(HRK.home)
EMSK (*.*) -+- home (*.home)----Home (domainreauth.home)--
            +- domain1 (*.domain1)
            \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
                                    +- USRK2 (service2.domain2)
                                    \- HOKEY (reauth.domain2)

EMSK (*.*) -+- home (*.home)------HOKEY (HRK.home)-HOKEY(domainreauth.home)
            +- domain1 (*.domain1)
            \- domain2 (*.domain2) -+- USRK1 (service1.domain2)
                                    +- USRK2 (service2.domain2)
                                    \- HOKEY (reauth.domain2)

I am still puzzled by "rekey" key as "anything that results from EMSK".

Madjid
-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 3:41 PM
To: [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Current EMSK draft:

Proposed changes:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Jan 2007 15:44:57 -0500

On Wed, Jan 31, 2007 at 12:09:56PM -0800, Madjid Nakhjiri wrote:
> Handovers within the local domain, 

This does not require EAP re-auth.  If EAP re-auth is needed for
intra-domain handver, there must be some implication, but no one has
given a clear answer what the implication is and why.

> or extending the existing session..

If you mean extending the authorization session, this has to go to the
entity that made the authorization decision, which is the home AAA
server.

Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 31 Jan 2007 13:56:33 -0800

Hi Yoshi,

I was just referring to examples of intra-domain re-authentication within
the visited domain. I also said that for inter-domain we need to use a
re-auth key and procedure with home domain. 
As far as intra-domain handover, please see my hokey-hierarchy draft and the
previous handover keying PS, both inter-ADC/authenticator and intra-ADC
handover can be seen as an intra-domain handover. For inter-authenticator
handover, I thought we were discussing the choice of signaling to be hokey
versus EAP. And I thought we agreed on EAP, even though this is being
discussed on the list. 
So in response to your question, I don't understand how come
inter-authenticator handover signaling in home domain is going to use EAP,
but the same in visited domain does not?

I think in the debate of re-auth signaling, people are forgetting the
handover keying signaling.

As far as existing session, I am just talking about EAP session and EMSK and
child keys, I don't want to get into an authorization debate here, since I
find the use of term authorization a bit ambigious.

Madjid

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Wednesday, January 31, 2007 12:45 PM
To: Madjid Nakhjiri
Cc: 'Yoshihiro Ohba'; 'Rafa Marin Lopez'; [email-masked]
Subject: Re: [HOKEY] EMSK Hierarchy Changes

Yoshihiro Ohba