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

[Avi Lior (avi]

See inline....
 

> -----Original Message-----
> From: Salowey, Joe [mailto:jsalowey [at] cisco.com] 
> Sent: Friday, March 10, 2006 12:43 AM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
>  
>  
> > > > > 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.
> > > > 
> > > 
> > > [Joe] I think we will probably need mopre definition around this. 
> > 
> > [Avi] Okay.
> > 
> > > > > 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?
> > > > 
> > > 
> > > [Joe] If they are generated at the same time I don't think
> > there is a
> > > problem.  If there is a delay in generation where the application 
> > > requires the EMSK to be cached it is less than optimal.
> > > 
> > [Avi] In another email thread we explored this further and 
> the way I 
> > understand it is that an Application can have one AMSK key because:
> > 
> > FOO-AMSK = KGF(EMSK,"FOO" | ... | ...)
> > 
> > "FOO" is a the Key Lable and it must be unique.
> > 
> > FOO-A-AMSK = KGF(EMSK,"FOO-A" |  ... | ...) FOO-B-AMSK = 
> > KGF(EMSK,"FOO-B" |  ... | ...)
> > 
> > Are really two differnet AMSKs and this is legal because these are 
> > viewed as two separate applications.
> > 
> > And
> > FOO-A-AMSK = KGF(EMSK,"FOO" | "A" | ...) FOO-B-AMSK = 
> KGF(EMSK,"FOO" | 
> > "B" | ...)
> > 
> > Generates two distinct keys but SHOULD not be legal. 
> > 
> > I am not sure if this is defined correctly.
> > 
> 
> [Joe] I'm not sure the last has to be illegal but it calls 
> into question the "M" in AMSK.  It would be better to derive 
> these two keys off an AMSK for FOO.  

FOO-A-AMSK and FOO-B-AMSK are not intended to be subkeys for FOO -- they
are two AMSKs for FOO.  The original context was whether or not an
Application can have two or more AMSKs.
 
> > Finally,  I am not sure how this has to do with EMSK caching or not.
> 
> [Joe] Any one application should not introduce a requirement 
> to cache the EMSK. If you are going to derive keys at 
> different times for an application this should be done off an 
> AMSK not the EMSK.  
>