eap Mailing List: RE: Strawman -10/EMSK deletion requirement?

[Avi Lior (avi]

Hi Joe

> -----Original Message-----
> From: Salowey, Joe [mailto:jsalowey [at] cisco.com] 
> Sent: Wednesday, March 08, 2006 8:29 PM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
> I would add that the AMSK for a particular application should 
> be derived such that once the AMSK is derived for that 
> application there is no need to continue to use the EMSK for 
> derivation of additional keys for that application.  

Yes I totally agree.  AMSK derivation happens within the EAP Auth
Server.  Derived keys from AMSK happen within KeyHolder/KeyGenerator
function which is external to the EAP Auth Server.

 
> > -----Original Message-----
> > From: Avi Lior [mailto:avi [at] bridgewatersystems.com]
> > Sent: Wednesday, March 08, 2006 10:24 AM
> > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko
> > Cc: eap [at] frascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > 
> > So there might be reason for caching the EMSKs.  So 
> language like the
> > following:
> > 
> > EMSK is used strictly for generating AMSKs.
> > 
> > EMSK is not transported out of the EAP Authentication Server Layer.
> > 
> > EMSK MUST be deleted when the session for which it was created is 
> > deleted.
> > 
> > EMSK SHOULD be deleted sooner, when it is no longer required.  
> > 
> > > -----Original Message-----
> > > From: Salowey, Joe [mailto:jsalowey [at] cisco.com]
> > > Sent: Wednesday, March 08, 2006 1:23 PM
> > > To: Narayanan, Vidya; Avi Lior; Jari Arkko
> > > Cc: eap [at] frascone.com
> > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > > 
> > > The EMSK is the root of all AMSKs, so a compromise of the EMSK 
> > > compromises all AMSKs.  Therefore I would like to see the EMSK 
> > > protected as much as possible.  Once the EMSK is securely 
> deleted it 
> > > cannot be compromised. I would like to see applications be as 
> > > independent from one another as possible and not have one 
> > > application require the EMSK be cached once its AMSK is 
> generated. 
> > > This implies a deeper key hierarchy than if an 
> application derives 
> > > all of its keys directly from the EMSK.
> > > 
> > > Caching itself is new functionality in the system, but 
> seems to be 
> > > required whether you cache AMSK or EMSK.  I don't really have a 
> > > problem with caching the EMSK if it is required at the 
> system level 
> > > because all applications are not known at the right time. 
>  It think 
> > > it may be OK for an implementation to cache the EMSK for its own 
> > > optimizations, but I would prefer that the caching of the 
> EMSK not 
> > > be required for any particular AMSK usage.  Since an AMSK is 
> > > exportable you have more options on where it can be cached.
> > > 
> > > Hope this helps,
> > > 
> > > Joe
> > > 
> > > > -----Original Message-----
> > > > From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com]
> > > > Sent: Tuesday, March 07, 2006 12:40 PM
> > > > To: Salowey, Joe; Avi Lior; Jari Arkko
> > > > Cc: eap [at] frascone.com
> > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > > > 
> > > > Joe,
> > > > I can see the problem with transporting the EMSK to other
> > > entities -
> > > > however, what really is the concern with caching the EMSK
> > > as long as
> > > > it is never exported? Is it just the concern of having to
> > maintain
> > > > state or is there a security concern here?
> > > > 
> > > > Vidya
> > > > 
> > > > > -----Original Message-----
> > > > > From: Salowey, Joe [mailto:jsalowey [at] cisco.com]
> > > > > Sent: Monday, March 06, 2006 2:04 PM
> > > > > To: Avi Lior; Jari Arkko
> > > > > Cc: eap [at] frascone.com
> > > > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > > > > 
> > > > > Hi Avi,
> > > > > 
> > > > > > 
> > > > > > Perhaps you missed my poorly stated point :-)
> > > > > > 
> > > > > > What if the user is requesting access to a new application? 
> > > > > > which could
> > > > > > also involve the modification of the user's profile. 
> > > > > > If EMSK is not there, then what do I do? Restart the
> > > session? No.
> > > > > > 
> > > > > > At anyrate I belive that there could be other use cases... 
> > > > > I gave two
> > > > > > reason why:
> > > > > > 
> > > > > > Just-in-time;
> > > > > > Dynamic-Application provisioning.
> > > > > 
> > > > > [Joe] Would you agree with the following:
> > > > > 
> > > > > "For any specific application once the AMSK is
> > generated for that
> > > > > application there is no requirement to cache the EMSK 
> for that 
> > > > > application, however there may be a need to cache the
> > EMSK if the
> > > > > system requires other Masks to be generated. "
> > > > > 
> > > > > This makes the caching more of a system issue than an
> > > issue for one
> > > > > particular application.   
> > > > > 
> > > > > 
> > _________________________________________________________________
> > > > > To unsubscribe or modify your subscription options,
> > please visit:
> > > > > http://lists.frascone.com/mailman/listinfo/eap
> > > > > 
> > > > > Arhives: http://lists.frascone.com/pipermail/eap
> > > > > 
> > > > 
> > > 
> > 
>