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

[Yoshihiro Ohba (yohba]

An issue would be that it might be difficult to determine how long the
keys should be cached.  The MN may not communicate with the HA until
it needs to start MIPv6.  So probably an additional key hierarchy is
needed with introducing a key holder (or a KDC) which holds an
application-specific root key during authorization lifetime for MIPv6
bootstrapping.

Yoshihiro Ohba


On Tue, Nov 08, 2005 at 05:53:29PM -0500, Vanderveen, Michaela wrote:
> 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.
> ===========================================================
> 
> 
>