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

[Avi Lior (avi]

Hi,
I would like to modify what you wrote as follows:

> "The EMSK MUST NOT be used to generate any keys other than 
> AMSKs needed for the same EAP peer that owns the EMSK. 

The EMSK MUST NOT be used to generate any keys other than AMSKs needed
for the same session for which the EMSK was generated.

> The 
> EMSK MUST NOT be transported out of the EAP (AAA?) Layer and 
> MUST be deleted when the corresponding EAP session expires.

Replace EAP (AAA?) with EAP Authentication Server; and "corresponding
EAP session expires" with 'corresponding session has ended'.

Motivation for above: Not sure if EAP session is defined; and you delete
the EMSK when the session is terminated either because it expired or
because it was explicitly terminated.
 
> Further, an EMSK MUST NOT be used to generate more than one 
> AMSK for a given application. 

I am not sure that the above does not pose a threat.  Normally we would
think that one Application would require one AMSK.  But since we are not
defining what an application is -- and we shouldn't IMO enter that rat
hole.  Then what if there was some application that requires an two
AMSKs.?  Is there harm?

> If more keys are needed for an 
> application, those may be derived from the AMSK subsequently 
> by the entities sharing the AMSK. 

I don't think you need the 'subsequently by entities sharing the AMSK'.
I can give one example of one application where  there there is only one
entity that receives the AMSK.  That entity generates the keys needed by
the applications and transports those keys to elements that need the
key.  The AMSK is not transported at all.

> It is RECOMMENDED that all 
> necessary AMSKs corresponding to various applications be 
> generated immediately upon EMSK generation and that the EMSK 
> be deleted right away thereafter."  

I prefer:

Once all AMSKs have been derived and the EMSK is not needed it shall be
deleted.



> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com] 
> Sent: Wednesday, March 08, 2006 8:38 PM
> To: Salowey, Joe; Avi Lior; Jari Arkko
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
> 
> Putting all this together, is it fair to say this then? 
> 
> "The EMSK MUST NOT be used to generate any keys other than 
> AMSKs needed for the same EAP peer that owns the EMSK. The 
> EMSK MUST NOT be transported out of the EAP (AAA?) Layer and 
> MUST be deleted when the corresponding EAP session expires. 
> Further, an EMSK MUST NOT be used to generate more than one 
> AMSK for a given application. If more keys are needed for an 
> application, those may be derived from the AMSK subsequently 
> by the entities sharing the AMSK. It is RECOMMENDED that all 
> necessary AMSKs corresponding to various applications be 
> generated immediately upon EMSK generation and that the EMSK 
> be deleted right away thereafter." 
> 
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsalowey [at] cisco.com]
> > Sent: Wednesday, March 08, 2006 5: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.
> > 
> > > -----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
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
>