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

[Avi Lior (avi]

Hi 

Please see inline... 

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com] 
> Sent: Thursday, March 09, 2006 10:43 AM
> To: Avi Lior; Salowey, Joe; Jari Arkko
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
> Hi 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.
> > 
> 
> Sounds good. 
> 
> > > 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'.
> > 
> 
> I guess when you say EAP Authentication Server, it is a bit 
> vague about whether that is the EAP layer or AAA layer. I'm 
> not sure if there is value in clarifying this or if it makes 
> more sense to leave it to implementation.  

Well it is not happening in the AAA layer.  My understanding is that the
EAP Method executes within the EAP Auth Server.  EAP Auth Server may or
may not be colocated with the AAA server.

> > 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.
> >  
> 
> Could we say "corresponding session has either expired or 
> been terminated"? 

Sounds good.
> 
> > > 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?
> > 
> 
> Hmmm. If an application requires more than one key, would 
> there really be a case where creation of a root AMSK and 
> subsequent keys from that root AMSK not work? I'm wondering 
> why you need to create multiple AMSKs for the same 
> application directly from the EMSK. I'd personally like to 
> have no more than one key coming out of the EMSK for the same 
> key label (unique per application) in AMSK derivation. 

Lets get to right down to the label(s).  If I have an application called
foo, can I generate two AMSKs as follows:

AMSK-FOO-A = KGF(EMSK,"FOO-A" | ......)
AMSK-FOO-B = KGF(EMSK,"FOO-B" | ......)

I don't know why an application FOO would like to do this.  Maybe FOO
application is really two applications.    

But the point is, from a security perspective why does it matter?

> > > 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.
> > 
> 
> Fair enough. I was trying to get at the fact that subsequent 
> keys should not be derived for entities other than the ones 
> the AMSK was meant for - maybe that restriction itself isn't 
> really needed. 
> 
> > > 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.
> > 
> 
> To Joe's earlier points (about trying to keep the EMSK as 
> secure as possible and delete it as quickly as possible), I 
> would like to see this recommendation. Maybe appending the 
> former text with "When this is not feasible, the EMSK MUST be 
> deleted once all the AMSKs have been derived"
> makes sense? 

I think my statement addresses Joe's concern.  But I find the whole
concept of immediacy silly especially when EAP does not concern itself
with key lifetimes etc....

Why are we all of a sudden concerned about timelyness?

> 
> -Vidya
> 
> > 
> > 
> > > -----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
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
>