eap Mailing List: RE: Re: Eap keying review: use of MSK/ EMSK for AMSK creation

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

 Yoshihiro,

I did not say I agree with that philosophy. I also think that is not
very practical to assume that the AAA layer knows about all the upcoming
applications or authorization a'priori. One example being may be you
want to move from one access technology to the next, both under the same
AAA server, and the second one suddenly with a lot more bandwidth than
the first (thanks Glen, for that example), so there are a lot of
practical implications to the existing assumptions.

Having said all that I think the HA-specific key can be derived from a
previously derived MIP-AMSK root, if we have to, assuming that our AAA
server was smart enough to ask for a MIP-AMSK when it had a chance
(certain amount of cynicism intended :)).
 
Madjid
-----Original Message-----
From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com] 
Sent: Tuesday, November 08, 2005 4:42 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; Bernard Aboba; eap [at] frascone.com
Subject: Re: [eap] Re: Eap keying review: use of MSK/ EMSK for AMSK
creation

On Tue, Nov 08, 2005 at 04:57:29PM -0500, Nakhjiri Madjid-MNAKHJI1
wrote:
> I think at least for handover or for MIP type applications we can work

> with this comfortably, i.e. have an HO-AMSK and a PMIP-AMSK and so on.
> And for HO, I will derive all the keys that are needed for HO-AMSK.
> 
> However, as we discussed during HOKEY meeting last night, this makes 
> the assumption that the AAA nows at the time authentication, about all

> the applications for which it needs AMSKs for.

I think this assumption has a limitation for MIPv6 bootstrapping.  In
some case, the AAA server may not know which HA is to be chosen by the
MN until an explicit request comes from HA x chosen by the MN.  In this
case, a key for HA x should be generated on-demand basis (but I am not
sure whether use of AMSK or MSK is appropriate for this case).

Yoshihiro Ohba


> This works for now, since we
> can say that a well designed system should make all AAA decisions 
> (especially authorization ones) at once. Still it would be nice if do 
> not add the limitation that prevents the AAA layer/ server to later 
> ask for another keys, to be exact, if we do not require deletion of 
> EMSK immediately after AMSK creation. I cannot come of a specific 
> example right now.
> 
> Madjid
> 
> 
> >So this prohibits the AAA server to take EMSK and create new keys
> >  
> >
> We may have discussed this already, but this is I believe correct. The

> EMSK should not be handed to the lower layer. But see below:
> 
> >(AMSKs) for new applications or services.  This means the EAP layer 
> >must itself authorize each service application and calculate any AMSK

> >that are needed for that application. Not only we are including a 
> >role of authorization into an EAP server, but also we are saying the 
> >EAP layer must anticipate all applications that need to derive their 
> >keys based on the EAP keying process. Should not be the AAA server to

> >make
> >  
> >
> I think we can easily arrange things so that the AAA layer asks for 
> AMSKs 1, 2, and 3, which fulfils security requirements (EMSK is not
> exposed) and does not require application knowledge from EAP layer. 
> Does this work for you?
> 
> --Jari
> 
> _______________________________________________
> eap mailing list
> eap [at] lists.frascone.com
> http://lists.frascone.com/mailman/listinfo/eap
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] lists.frascone.com
> http://lists.frascone.com/mailman/listinfo/eap
> 
>