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-ur
ien-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 qualcomm.com]
> > Sent: Tuesday, March 07, 2006 12:40 PM
> > To: Salowey, Joe; Avi Lior; Jari Arkko
> > Cc: eapfrascone.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:jsaloweycisco.com]
> > > Sent: Monday, March 06, 2006 2:04 PM
> > > To: Avi Lior; Jari Arkko
> > > Cc: eapfrascone.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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|