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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Michaela,

Yes, specifically with RADIUS that is a problem. During Hokey meeting, I
think Jari agreed that we may be able to lax that requirement (deletion
of a key immediately after transport).

Madjid 

-----Original Message-----
From: Vanderveen, Michaela [mailto:MCV [at] flarion.com] 
Sent: Tuesday, November 08, 2005 4:53 PM
To: Yoshihiro Ohba; 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

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