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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Exactly my point. Thank you. 

-----Original Message-----
From: Avi Lior [mailto:avi [at] bridgewatersystems.com] 
Sent: Sunday, March 05, 2006 9:09 AM
To: Nakhjiri Madjid-MNAKHJI1; Salowey, Joe; Rafa Marin Lopez; Bernard
Aboba
Cc: eap [at] frascone.com
Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

Hi Madjid 

Seems that there a lot of good reasons for keeping EMSK around after it
is used to generate AMSKs.  Hopefully everyone gets that.


> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com]
> Sent: Friday, March 03, 2006 6:21 PM
> To: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
> Hi Avi,
> 
> -----Original Message-----
> From: Avi Lior [mailto:avi [at] bridgewatersystems.com]
> Sent: Thursday, March 02, 2006 2:16 PM
> To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard 
> Aboba
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
> Hi Joe and Madjid,
> 
> The only reason for caching the EMSK is if you have to generate an 
> AMSK for another application associated with the current session.
> 
> Madjid>> Thank you for clarification. Another example may be
> roaming to
> another access technology!!
> 
> So the question is do you have to generate all possible AMSKs and then

> delete the EMSK or can you generate the AMSKs as needed?
> 
> Madjid>>i.e. keep EMSK for future AMSK generation. The first
> option will
> create the need for running EAP again.
> 
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsalowey [at] cisco.com]
> > Sent: Thursday, March 02, 2006 2:49 PM
> > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba
> > Cc: eap [at] frascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjiri [at] motorola.com]
> > > Sent: Thursday, March 02, 2006 8:44 AM
> > > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba
> > > Cc: eap [at] frascone.com
> > > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > > 
> > > Hi Joe,
> > > 
> > > Thanks for the email. I think you responded to the old
> piece of the
> > > email from Rafa and I am to blame for causing that
> confusion, as I
> > > kept that part to provide context.
> > > Again, my question was why an entity needs to delete EMSK after 
> > > generating the first AMSK (or first set of AMSKs?)? This
> > seems to be
> > > the requirement regardless of two options:
> > > 
> > > 1) keep EMSK at EAP layer, create AMSK at EAP layer based
> > request from
> > > AAA layer, delete EMSK Immediately (this means EAP layer
> must have
> > > KDFs for AMSK=KDF(EMSK, etc)
> > > 2) push EMSK down to AAA layer at backend server, create
> > AMSK at AAA
> > > layer and delete EMSK immediately (this means AAA layer must have
> > > KDFs)
> > >
> > [Joe] If the AAA layer contains the AAA client and AAA
> server then the
> 
> > EMSK should not be available to this layer, if the AAA layer means 
> > something else then I don't know about (1).
> > The AMSK should be generated in the EAP and exported, option (2).
> >  
> > > 
> > > In both cases we require deletion of EMSK after
> generation of AMSK,
> > > why?
> > > 
> > [Joe] To minimize the chance of exposure of the EMSK.  Why
> do you need
> 
> > to cache it? Could you generate and cache an AMSK instead?
> > 
> > 
> > > Thanks,
> > > 
> > > Madjid
> > > 
> > > -----Original Message-----
> > > From: Salowey, Joe [mailto:jsalowey [at] cisco.com]
> > > Sent: Wednesday, March 01, 2006 5:17 PM
> > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba
> > > Cc: eap [at] frascone.com
> > > Subject: RE: [eap] Strawman -10
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:Madjid.Nakhjiri [at] motorola.com]
> > > > Sent: Wednesday, March 01, 2006 2:38 PM
> > > > To: Rafa Marin Lopez; Bernard Aboba
> > > > Cc: eap [at] frascone.com
> > > > Subject: RE: [eap] Strawman -10
> > > > 
> > > > Madjid>>Again, why is deletion of EMSK after generation of
> > > > one AMSK is a
> > > > requirements. What if we need to create multiple AMSKs
> > and that at
> > > > multiple occassions?
> > > > 
> > > > 
> > > > 
> > > > Well, actually, lower layer authenticator implementation
> > > should expect
> > > > (MSK,EMSK) in the case EAP method is executed by the standalone 
> > > > authenticator or (MSK,AMSK) in the case EAP method is
> executed by
> > > > backend authentication server. If it receives (MSK,EMSK)
> > > should create
> > > 
> > > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's
> > > all, correct?
> > > 
> > > [Joe] Not really, strictly speaking the lower layer
> > shouldn't expect
> > > to receive the EMSK as that would break mode independence.  An 
> > > architectural description should not have the lower layer
> receiving
> > > the keys. From a supplicant perspective it must appear the same 
> > > whether an external EAP-Server or a collocated EAP server is used.
> > > Now I don't know what is going on inside your box, it
> could all be
> > > monolithic when a internal EAP server is used but that
> shouldn't be
> > > visible to the external world.  If I was interested in
> > cryptographic
> > > module separation I might not be too happy if you shared
> > the EMSK with
> > > the lower layer.
> > > 
> > > > 
> _________________________________________________________________
> > > > 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
> > 
>