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

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Wed, 8 Mar 2006 16:27:07 -0800

Joseph Salowey (jsalowey) <> supposedly scribbled:

> 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. 

OK, but is that not equally true of Jari's proposed AMSK_root_0 approach?

> 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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel
_________________________________________________________________
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 13:21:17 +0200

>OK, but is that not equally true of Jari's proposed AMSK_root_0 approach?
The problem is that since EMSK is the root, its compromise will
lead to the compromise of all derived keys. This also holds
locally for the AMSK_root_0 approach. That is, if AMSK_root_0
is compromised then any keys derived from that root are
compromised (but not keys in other apps).

--Jari