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

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Avi Lior [mailto:avi [at] bridgewatersystems.com] 
> Sent: Monday, March 06, 2006 10:36 AM
> 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,
> 
> I have something to say about both your replies to I included them
> together.
> 
> 
> > 
> > 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.
> > 
> [Joe] No. After the AMSKs are generated what are you going to do with
> the EMSK?  The purpos of the EMSK is to generate AMSKs.   
> 
> I think it is sufficient to say that exactly what you said: 
> "The purpose
> of the EMSK is to generate AMSKs."
> 
[Joe] OK great. SO in the above you meant keeping the EMSK around to
generate AMSKs after the EAP authentication transaction has completed. 

> Why should we generate all the AMSKs at once?  A session may have
> several applications that may require AMSK.  Some applications will be
> used 100% of the time, some application will be used rarely.  
> Why should
> an implmeentation genrate an AMSK and cache it just in case 
> it will need
> the key?  That doesn't make sense.
> 
[Joe] OK so as an optimization an entity can cache the EMSK so it could
generate the AMSK "just in time". I'm not sure how much of an
optimization would be, but I suppose there could be a few applications
that use this mechanism. If we do this we need to manage the cache, how
are entries identified, so they can be retrieved and deleted. We have a
key name so the key can be identified, although there may be an issue if
there are multiple caches as to which cache contains the right keys. 

> 
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsalowey [at] cisco.com] 
> > Sent: Monday, March 06, 2006 12:46 PM
> > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; 
> > Bernard Aboba
> > Cc: eap [at] frascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Avi Lior [mailto:avi [at] bridgewatersystems.com]
> > > Sent: Thursday, March 02, 2006 12: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.
> > > 
> > > 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?
> > > 
> > [Joe] I understand that there may be need for caching of 
> > certain quantities.  I think Jari explained it well in a 
> > separate message.  In my opinion you should try to identify 
> > the applications in use and the keys needed as early as 
> > possible.  
> I disagree.  I think from a resource point of view we should 
> not genrate
> keys for something that we may not be using.  At any rate 
> this needs to
> be an implmeentation choice and we should not prohibit this 
> choice in a
> standard.
> 
> > If this is not possible then caching of the MSK 
> > may be necessary.  
> 
> I think you mean EMSK not MSK. Right?
> 
> If yes, we agree then caching of EMSK may be necessary.  Great!!!
> 
> I don't think we should write a specification that MUST require an
> implmeentation to dervie all the keys that it is necessary on 
> the chance
> that the keys may be needed.  
> 
> I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and
> MUST NOT be transported out of the EAP Authentication Server layer.
> 
> > Do we have examples where the caching of 
> > the EMSK is necessary.  
> 
> What if I don't have an example today?  Does that mean that in the
> future I won't? or that somewhere in the world someone does 
> have such a
> need?
> 
> > In the case where key caching is used 
> > the cache needs to be managed.  If we are caching EMSKs then 
> > the document that describes EMSK usage must describe how key 
> > cache can be managed. 
> 
> I agree.
>  
> > 
> > > Finally I have an slight issue with the statement that a 
> > KEY should be 
> > > deleted so that it wont be used for other purposes.  I find that 
> > > statements like that are an over specification.  What 
> makes anyone 
> > > think that making a statement that "X should/must be 
> > deleted" is going 
> > > to be taken more seriously then "X should/must only be used for 
> > > purpose X and should/must not be transported out of Y"?
> > > 
> > > I think that whether it gets deleted or not is an implementation 
> > > issue.
> > > 
> > 
> > [Joe] The goal of the architecture is to prevent the re-use 
> > of keys for multiple different purposes.  I agree that this 
> > is not necessarily the same a deletion.  It is very important 
> > that keys derived from the EMSK don't collide purposes across 
> > applications.  
> 
> I agree and therefore lets stick to the important issue and drop the
> deletion argument.  The important issue being that EMSK shall be used
> for AMSK derivation and for no other purpose.
> 
> > What happens in a particular AMSK branch of 
> > the key hierarchy is not necessarily as important since this 
> > branch is cryptographically separated from the rest of the 
> > system through the AMSK derivation.  I think the current text 
> > could probably do better in motivating why it is good 
> > practice to delete keys.  
> 
> I don't think we need to talk about key deletion at all, 
> except when it
> comes to the key's end-of-life or end of session.  I think we need to
> stress exactly what you said.
> 
>  
> > > Finally if we insist on saying that X must be deleted we 
> > should really 
> > > say that X must be securely deleted.  There is a difference.
> > > When a key
> > > is securely deleted the software takes extra care that the memory 
> > > location containing the key is first erased before the 
> > memory location 
> > > is freed to the heap.  Perhaps we can state that somewhere.
> > > 
> > > > -----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
> > > > 
> > > 
> > 
>