Subject: Re: [HOKEY] EMSK Hierarchy Changes

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 30 Jan 2007 11:49:15 -0800 (PST)

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, and may want to have control over derivation of service keys, as needed. 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.

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. 

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

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 Jan 2007 17:23:48 -0500

Hi Michaela,

On Tue, Jan 30, 2007 at 11:49:15AM -0800, M. Vanderveen wrote:
> 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).

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

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

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

Can you elaborate on why it becomes non-compliant?

Regards,
Yoshihiro Ohba