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."
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.
> -----Original Message-----
> From: Salowey, Joe [mailto:jsalowey cisco.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
|
1. Ccan you explain what specific technical
problem do you encounter with the proposal that I outlined
in
my e-mail, namely that you generate the AMSKs that you need,
and that those AMSKs can be kept around and used for further
generation of keys when the application in question needs
more
than one?
Is it just the need to do unnecessary work for keys that
may not be needed for this session? Or is there some
functional difference?
2. Do you have a plan how to manage the cache at the AAA
server side, if there is no agreement a priori that EMSKs
and specific AMSKs are going to be needed?
3. Also, you wrote:
>I do agree that EMSK MUST ONLY BE USED for key
derivation (AMSKs) and
>
>
What specific purpose did you have in mind for the EMSK? Do
you plan
to use the entire EMSK for some specific application you had
in
mind? What if other applications want to use it too?
4. And you wrote
>MUST NOT be transported out of the EAP Authentication
Server layer.
>
Ok. This is the issue that I wrote another e-mail about (the
one with
choices 1a, 1b, 2a, and 2b) -- can you comment on that
e-mail what
you want along with the rationale for your choice?
Thanks,
--Jari
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit: