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

[Vanderveen, Michaela (MCV]

We are running into the problem that the keys necessary for fast handoff though 
derived with no problems, are not ready to be transported until the HA asks for 
them. Thus since it has been agreed last night that AMSKs can be transported to 
more than one entity, the AAA server should be able to cache these keys for a 
(short) while, until all entities that need the key have obtained them.

Michaela

-----Original Message-----
From: eap-admin [at] lists.frascone.com [mailto:eap-admin [at] 
lists.frascone.com]On Behalf Of Yoshihiro Ohba
Sent: Tuesday, November 08, 2005 2: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
> 
> 
_______________________________________________
eap mailing list
eap [at] lists.frascone.com
http://lists.frascone.com/mailman/listinfo/eap

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================