Subject: Re: [HOKEY] EMSK Hierarchy Changes

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 30 Jan 2007 16:02:54 -0800 (PST)

Thanks, Yoshi, here are some clarifications, Rafael can chime in too.

> The reason to me is as follows: the local domain may have its own authentication/authorization policy that the home domain need not know about, 

>>This is already doable.  The visited domain can modify the
authorization result came from the home domain to reflect its
authorization policy.  Also, I don't understand how authentication in
the local domain can work without the home domain's knowledge about it
unless authentication in the local authentication is totally
independent of authentication in the home domain (at least there is a
dependency in the key hierarchy).

MCV>> Correct, the authentication in the local domain SHOULD have the option of being "totally independent of authentication in the home domain", except for the dependency in the key hierarchy, which we can't do without (assume the user shares LTC with only one domain, the home domain).

>and may want to have control over derivation of service keys, as needed. 

Isn't it just a matter of how we define each USRK usage?  In any case,
without home domain's authorization, the local domain cannot take the
control of service key derivations, because everything being discussed
here is associated with LTC managed by the home domain.

MCV>>> Yes, it's a matter of how we define each USRK usage. The local domain can obey all the USRK usage rules down to the prf if you wish, but it should do that based on an RFC such as the one we are trying to produce here, which makes no assumption whether this USRK derivation happens in a home or visited domain. I believe we can allow the local domain to take control of the service keys derivation for services in its own domain, w/o breaking any current RFCs. The one branch of the hierarchy would be  LTC -> EMSK -> EMSK-domain1:= root key domain 1 --> EMSK --> USRK1,2,etc.

>Giving the local domain a key scoped to be a root for a "traditional" (i.e. currently 3847 + eap-keying compliant) EAP processes (methods, method indep, etc). would achieve a desired separation of the security architecture between domains.

I don't understand this, because the reason explained above seems
doable without authentication in the local domain.
MCV>> If the EMSK-domain1 derived by the home domain for local domain use can be used as a root key to bootstrap traditional EAP methods, then it can (indirectly) be used to derive USRKs, based on EMSKs derived in the local domain, as the flat hierarchy above tries to describe.

> 
> A domain that is currently running EAP to fulfil its authentication needs, and possibly re-auth and re-key according to whatever we decide, should not suddenly become non-compliant when it takes the label "local". The now-local domain should be able to continue to act like a home domain, so that the Peer behavior is not radically different when roaming. 

Can you elaborate on why it becomes non-compliant?

MCV>> Assume a domain A runs EAP-X for authentication and possibly key derivation. Now it wants to enter into a business relationship with domain B. Let's put Peer support of EAP methods aside for now. Then users who share LTCs with domain B and who would like to roam into domain A should be able to do so without going to domain B for each and every authentication; they should be able to have access to domain A just like the existing Peers, who run EAP-X for auth and re-auth  in this domain. Now by mandating that a certain EAP *procedure* or hierarchy be attached to the key material that domain B gives to domain A for a user, domain A becomes non-compliant if it insists on running EAP-X with its roaming users as well.  

HTH,
Michaela

Regards,
Yoshihiro Ohba

> 
> Michaela
> 
> 
> ----- Original Message ----
> From: Yoshihiro Ohba <[email-masked]>
> To: Rafa Marin Lopez <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, January 30, 2007 6:29:15 AM
> Subject: Re: [HOKEY] EMSK Hierarchy Changes
> 
> 
> 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
> 
> On Tue, Jan 30, 2007 at 03:18:50PM +0100, Rafa Marin Lopez wrote:
> > Yoshihiro Ohba escribio':
> > > 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.
> > > Yoshihiro Ohba
> > >
> > >
> > > On Tue, Jan 30, 2007 at 02:08:57PM +0100, Rafa Marin Lopez wrote:
> > >   
> > >> 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
> > >>
> > >>     
> > >>> 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.
> > >>>   
> > >>>       
> > >> 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]
> > >> ------------------------------------------------------
> > >>
> > >>
> > >>     
> > >
> > >
> > >   
> > 
> > 
> > -- 
> > ------------------------------------------------------
> > 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]
> > ------------------------------------------------------
> > 
> > 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
> 
> 
>  
> ____________________________________________________________________________________
> Sucker-punch spam with award-winning protection. 
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html

____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

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