> -----Original Message-----
> From: Avi Lior [mailto:avi bridgewatersystems.com]
> Sent: Thursday, March 02, 2006 12:16 PM
> To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin
Lopez;
> Bernard Aboba
> Cc: eapfrascone.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. If this is not possible
then caching
of the MSK may be necessary. Do we have examples where the
caching of
the EMSK is necessary. 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.
> 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. 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.
> 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:jsaloweycisco.com]
> > Sent: Thursday, March 02, 2006 2:49 PM
> > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez;
Bernard Aboba
> > Cc: eapfrascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> >
> >
> >
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:Madjid.Nakhjirimotorola.com]
> > > Sent: Thursday, March 02, 2006 8:44 AM
> > > To: Salowey, Joe; Rafa Marin Lopez; Bernard
Aboba
> > > Cc: eapfrascone.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:jsaloweycisco.com]
> > > Sent: Wednesday, March 01, 2006 5:17 PM
> > > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin
Lopez; Bernard Aboba
> > > Cc: eapfrascone.com
> > > Subject: RE: [eap] Strawman -10
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:Madjid.Nakhjirimotorola.com]
> > > > Sent: Wednesday, March 01, 2006 2:38 PM
> > > > To: Rafa Marin Lopez; Bernard Aboba
> > > > Cc: eapfrascone.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
> >
>
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|