Exactly my point. Thank you.
-----Original Message-----
From: Avi Lior [mailto:avi bridgewatersystems.com]
Sent: Sunday, March 05, 2006 9:09 AM
To: Nakhjiri Madjid-MNAKHJI1; Salowey, Joe; Rafa Marin
Lopez; Bernard
Aboba
Cc: eapfrascone.com
Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
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.
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1
[mailto:Madjid.Nakhjirimotorola.com]
> Sent: Friday, March 03, 2006 6:21 PM
> To: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard
Aboba
> Cc: eapfrascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
>
> Hi Avi,
>
> -----Original Message-----
> From: Avi Lior [mailto:avibridgewatersystems.com]
> Sent: Thursday, March 02, 2006 2: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.
>
> Madjid>> Thank you for clarification. Another
example may be
> roaming to
> another access technology!!
>
> 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?
>
> Madjid>>i.e. keep EMSK for future AMSK
generation. The first
> option will
> create the need for running EAP again.
>
> > -----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
|