> -----Original Message-----
> From: Avi Lior [mailto:avi bridgewatersystems.com]
> Sent: Monday, March 06, 2006 10:36 AM
> To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin
Lopez;
> Bernard Aboba
> Cc: eapfrascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
>
> Hi Joe,
>
> I have something to say about both your replies to I
included them
> together.
>
>
> >
> > 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.
> >
> [Joe] No. After the AMSKs are generated what are you
going to do with
> the EMSK? The purpos of the EMSK is to generate AMSKs.
>
> I think it is sufficient to say that exactly what you
said:
> "The purpose
> of the EMSK is to generate AMSKs."
>
[Joe] OK great. SO in the above you meant keeping the EMSK
around to
generate AMSKs after the EAP authentication transaction has
completed.
> Why should we generate all the AMSKs at once? A
session may have
> several applications that may require AMSK. Some
applications will be
> used 100% of the time, some application will be used
rarely.
> Why should
> an implmeentation genrate an AMSK and cache it just in
case
> it will need
> the key? That doesn't make sense.
>
[Joe] OK so as an optimization an entity can cache the EMSK
so it could
generate the AMSK "just in time". I'm not sure
how much of an
optimization would be, but I suppose there could be a few
applications
that use this mechanism. If we do this we need to manage the
cache, how
are entries identified, so they can be retrieved and
deleted. We have a
key name so the key can be identified, although there may be
an issue if
there are multiple caches as to which cache contains the
right keys.
>
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsaloweycisco.com]
> > Sent: Monday, March 06, 2006 12:46 PM
> > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin
Lopez;
> > Bernard Aboba
> > Cc: eapfrascone.com
> > Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> >
> >
> >
> > > -----Original Message-----
> > > From: Avi Lior [mailto:avibridgewatersystems.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.
> I disagree. I think from a resource point of view we
should
> not genrate
> keys for something that we may not be using. At any
rate
> this needs to
> be an implmeentation choice and we should not prohibit
this
> choice in a
> standard.
>
> > If this is not possible then caching of the MSK
> > may be necessary.
>
> I think you mean EMSK not MSK. Right?
>
> If yes, we agree then caching of EMSK may be necessary.
Great!!!
>
> I don't think we should write a specification that
MUST require an
> implmeentation to dervie all the keys that it is
necessary on
> the chance
> that the keys may be needed.
>
> I do agree that EMSK MUST ONLY BE USED for key
derivation (AMSKs) and
> MUST NOT be transported out of the EAP Authentication
Server layer.
>
> > Do we have examples where the caching of
> > the EMSK is necessary.
>
> What if I don't have an example today? Does that mean
that in the
> future I won't? or that somewhere in the world someone
does
> have such a
> need?
>
> > 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.
>
> I agree.
>
> >
> > > 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.
>
> I agree and therefore lets stick to the important issue
and drop the
> deletion argument. The important issue being that EMSK
shall be used
> for AMSK derivation and for no other purpose.
>
> > 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.
>
> I don't think we need to talk about key deletion at
all,
> except when it
> comes to the key's end-of-life or end of session. I
think we need to
> stress exactly what you said.
>
>
> > > 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
|