Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 8 Mar 2006 17:38:19 -0800

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:[email-masked]] 
> Sent: Wednesday, March 08, 2006 5:29 PM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, March 08, 2006 10:24 AM
> > To: Salowey, Joe; Narayanan, Vidya; Jari Arkko
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > Sent: Wednesday, March 08, 2006 1:23 PM
> > > To: Narayanan, Vidya; Avi Lior; Jari Arkko
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Tuesday, March 07, 2006 12:40 PM
> > > > To: Salowey, Joe; Avi Lior; Jari Arkko
> > > > Cc: [email-masked]
> > > > 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:[email-masked]]
> > > > > Sent: Monday, March 06, 2006 2:04 PM
> > > > > To: Avi Lior; Jari Arkko
> > > > > Cc: [email-masked]
> > > > > 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
> > > > > 
> > > > 
> > > 
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 09 Mar 2006 14:04:05 +0200

>immediately upon EMSK generation and that the EMSK be deleted right away
I think I can live with this text. As I said in a previous e-mail, I have
been convinced that we need to support some form of dynamic
generation of AMSKs.

We also seem to be coming to a consensus on keeping the EMSK
at the server side.

But I still have a few nagging thoughts:

1. In order to avoid a situation that suddenly all AAA servers need to start
    keeping state, do we need  to require an authorization profile
    flag, configuration knob, or attribute to signal the need for
    keeping state?

2. The text does not tell us how to determine when all necessary
    AMSKs have been generated.

--Jari