Subject: Re: [HOKEY] Re: Bootstrapping EAP in local domains

From: "M. Vanderveen" <[email-masked]>
Date: Thu, 1 Feb 2007 14:07:08 -0800 (PST)

Thanks, Charles. The MSK is derived from EMSK-SrvN if that key is allowed to be used as a root key to bootstrap a traditional (shared-secret) EAP method in the local domain. That EAP-derived MSK can then be transported to the local Authenticator and used to derive TSKs as usual.  Perhaps what you observed is that it is not necessary per se to derive an MSK if the local domain can do without one, for example if the HOKEY-ReKey can be used for this purpose instead (so no need for a full EAP method); this is correct, I believe.

I don't see how removing it would make the hierarchy like that of the home domain: the home domain has an MSK too, since we assume it uses a traditional, MSK-exporting EAP method. Granted, this MSK can be done without in this context of hokey. But we should not preclude it's existence - doing that would be tantamount to banning traditional EAP methods - correct? Or maybe my assumption about the home domain running an EAP method is wrong...

----- Original Message ----
From: Charles Clancy <[email-masked]>
To: M. Vanderveen <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>; [email-masked]
Sent: Thursday, February 1, 2007 2:01:19 PM
Subject: Re: [HOKEY] Re: Bootstrapping EAP in local domains

Michaela,

I don't see why you would derive an MSK from EMSK-SvrN.  What would this 
be used for?  If it's removed, the visited-domain hierarchy can be 
collapsed to look just like the home-domain hierarchy, and you get 
pretty much exactly what was proposed before.

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

M. Vanderveen wrote:
> Apologies for using a non-standard drawing tool :-) - I for one can't 
> read the ascii art in the yahoo mail very well.
>  
> Here's yet another key hierarchy from the LTC down to (almost) the TSKs, 
> illustrating the same structure for a home and a local domain as well, 
> and in line with the latest "server- before - service" approach to use 
> keys.  I am not sure about the hokey root key placement. Yoshi you 
> should be pleased, I made a distinction between re-auth and re-key :-) . 
>  
> This is meant to illustrate a very useful case whereby EAP, by providing 
> key material to a domain, allows that domain to keep on using the same 
> protocols as it was prior to becoming a "local" domain for the peer in 
> question.
>  
> Michaela
> 
> 
>  
> ----- Original Message ----
> From: Yoshihiro Ohba <[email-masked]>
> To: M. Vanderveen <[email-masked]>
> Cc: Yoshihiro Ohba <[email-masked]>; Rafa Marin Lopez 
> <[email-masked]>; [email-masked]
> Sent: Wednesday, January 31, 2007 9:03:11 AM
> Subject: Bootstrapping EAP in local domains
> 
> Hi Michaela,
> 
> Essentially you are talking about defining a new USRK for
> bootstrapping an EAP method (which method?) in local domains.  To me
> this has nothing to with handover optimization.  It's cleaner to
> separate it from other USRKs such as those for re-key and re-auth.  
> On the other hand, I don't know whether this WG is the right place to
> define such a USRK.
> 
> Yoshihiro Ohba
> 
> On Tue, Jan 30, 2007 at 04:02:54PM -0800, M. Vanderveen wrote:
>  > 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/
> 
> 
> ------------------------------------------------------------------------
> Cheap Talk? Check out 
> <http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com> 
> Yahoo! Messenger's low PC-to-Phone call rates.
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey

____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

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