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

[Pascal Urien (Pascal.Urien]

Hi everybody

At 10:23 08/03/2006 -0800, Salowey, Joe wrote:
> 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.

In the last version of 
http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt
it is suggested to securely compute AMSK keys in EAP smartcards, without 
exporting EMSK

see

>>7.16 Get-AMSK
>>
>>   According to [RFC 4017] EMSK is an "additional keying material
>>   derived between the EAP client and server that is exported by the
>>   EAP method. The EMSK is at least 64 octets in length. The EMSK is
>>   not shared with the authenticator or any other third party. The EMSK
 >>  is reserved for future uses that are not yet defined".
>>
>>   It has been suggested in [EAP-EXT] to derive Application-specific
>>   Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be
>>   obtained by a Key Derivation Function (KDF), such as
>>
>>                        AMSK = KDF(EMSK, label, length)
>>
>>   The Get-AMSK(index,label) command is used to compute AMSK key,
>>   identified by an index and optionally associated to a label, needed
>>   to its calculation.

I believe that this functionality should be useful when a high security level
 is required, specially if EMSK controls a critical process like handover

Pascal




> 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
> > >
> >
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap