Hi
Please see inline...
> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan qualcomm.com]
> Sent: Thursday, March 09, 2006 10:43 AM
> To: Avi Lior; Salowey, Joe; Jari Arkko
> Cc: eapfrascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
>
> Hi Avi,
>
> > Hi,
> > I would like to modify what you wrote as follows:
> >
> > > "The EMSK MUST NOT be used to generate
any keys other than AMSKs
> > > needed for the same EAP peer that owns the
EMSK.
> >
> > The EMSK MUST NOT be used to generate any keys
other than
> AMSKs needed
> > for the same session for which the EMSK was
generated.
> >
>
> Sounds good.
>
> > > The
> > > EMSK MUST NOT be transported out of the EAP
(AAA?) Layer
> > and MUST be
> > > deleted when the corresponding EAP session
expires.
> >
> > Replace EAP (AAA?) with EAP Authentication Server;
and
> "corresponding
> > EAP session expires" with 'corresponding
session has ended'.
> >
>
> I guess when you say EAP Authentication Server, it is a
bit
> vague about whether that is the EAP layer or AAA layer.
I'm
> not sure if there is value in clarifying this or if it
makes
> more sense to leave it to implementation.
Well it is not happening in the AAA layer. My understanding
is that the
EAP Method executes within the EAP Auth Server. EAP Auth
Server may or
may not be colocated with the AAA server.
> > Motivation for above: Not sure if EAP session is
defined; and you
> > delete the EMSK when the session is terminated
either because it
> > expired or because it was explicitly terminated.
> >
>
> Could we say "corresponding session has either
expired or
> been terminated"?
Sounds good.
>
> > > Further, an EMSK MUST NOT be used to generate
more than one
> > AMSK for a
> > > given application.
> >
> > I am not sure that the above does not pose a
threat.
> > Normally we would think that one Application would
require
> one AMSK.
> > But since we are not defining what an application
is -- and we
> > shouldn't IMO enter that rat hole. Then what if
there was some
> > application that requires an two AMSKs.? Is there
harm?
> >
>
> Hmmm. If an application requires more than one key,
would
> there really be a case where creation of a root AMSK
and
> subsequent keys from that root AMSK not work? I'm
wondering
> why you need to create multiple AMSKs for the same
> application directly from the EMSK. I'd personally
like to
> have no more than one key coming out of the EMSK for
the same
> key label (unique per application) in AMSK derivation.
Lets get to right down to the label(s). If I have an
application called
foo, can I generate two AMSKs as follows:
AMSK-FOO-A = KGF(EMSK,"FOO-A" | ......)
AMSK-FOO-B = KGF(EMSK,"FOO-B" | ......)
I don't know why an application FOO would like to do this.
Maybe FOO
application is really two applications.
But the point is, from a security perspective why does it
matter?
> > > If more keys are needed for an
> > > application, those may be derived from the
AMSK
> subsequently by the
> > > entities sharing the AMSK.
> >
> > I don't think you need the 'subsequently by
entities sharing the
> > AMSK'.
> > I can give one example of one application where
there
> there is only
> > one entity that receives the AMSK. That entity
generates the keys
> > needed by the applications and transports those
keys to
> elements that
> > need the key. The AMSK is not transported at all.
> >
>
> Fair enough. I was trying to get at the fact that
subsequent
> keys should not be derived for entities other than the
ones
> the AMSK was meant for - maybe that restriction itself
isn't
> really needed.
>
> > > It is RECOMMENDED that all
> > > necessary AMSKs corresponding to various
applications be
> generated
> > > immediately upon EMSK generation and that the
EMSK be
> deleted right
> > > away thereafter."
> >
> > I prefer:
> >
> > Once all AMSKs have been derived and the EMSK is
not needed
> it shall
> > be deleted.
> >
>
> To Joe's earlier points (about trying to keep the EMSK
as
> secure as possible and delete it as quickly as
possible), I
> would like to see this recommendation. Maybe appending
the
> former text with "When this is not feasible, the
EMSK MUST be
> deleted once all the AMSKs have been derived"
> makes sense?
I think my statement addresses Joe's concern. But I find
the whole
concept of immediacy silly especially when EAP does not
concern itself
with key lifetimes etc....
Why are we all of a sudden concerned about timelyness?
>
> -Vidya
>
> >
> >
> > > -----Original Message-----
> > > From: Narayanan, Vidya [mailto:vidyanqualcomm.com]
> > > Sent: Wednesday, March 08, 2006 8:38 PM
> > > To: Salowey, Joe; Avi Lior; Jari Arkko
> > > Cc: eapfrascone.com
> > > Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
> > >
> > >
> > > Putting all this together, is it fair to say
this then?
> > >
> > > "The EMSK MUST NOT be used to generate
any keys other than AMSKs
> > > needed for the same EAP peer that owns the
EMSK. The EMSK
> > MUST NOT be
> > > transported out of the EAP (AAA?) Layer and
MUST be deleted
> > when the
> > > corresponding EAP session expires.
> > > Further, an EMSK MUST NOT be used to generate
more than one
> > AMSK for a
> > > given application. If more keys are needed
for an
> > application, those
> > > may be derived from the AMSK subsequently by
the entities
> > sharing the
> > > AMSK. It is RECOMMENDED that all necessary
AMSKs corresponding to
> > > various applications be generated immediately
upon EMSK
> > generation and
> > > that the EMSK be deleted right away
thereafter."
> > >
> > > > -----Original Message-----
> > > > From: Salowey, Joe [mailto:jsaloweycisco.com]
> > > > Sent: Wednesday, March 08, 2006 5:29 PM
> > > > To: Avi Lior; Narayanan, Vidya; Jari
Arkko
> > > > Cc: eapfrascone.com
> > > > Subject: RE: [eap] Strawman -10/EMSK
deletion requirement?
> > > >
> > > > I would add that the AMSK for a
particular application
> should be
> > > > derived such that once the AMSK is
derived for that
> > > application there
> > > > is no need to continue to use the EMSK
for derivation of
> > additional
> > > > keys for that application.
> > > >
> > > > > -----Original Message-----
> > > > > From: Avi Lior [mailto:avibridgewatersystems.com]
> > > > > Sent: Wednesday, March 08, 2006
10:24 AM
> > > > > To: Salowey, Joe; Narayanan, Vidya;
Jari Arkko
> > > > > Cc: eapfrascone.com
> > > > > Subject: RE: [eap] Strawman
-10/EMSK deletion requirement?
> > > > >
> > > > > So there might be reason for
caching the EMSKs. So
> > > > language like the
> > > > > following:
> > > > >
> > > > > EMSK is used strictly for
generating AMSKs.
> > > > >
> > > > > EMSK is not transported out of the
EAP Authentication
> > > Server Layer.
> > > > >
> > > > > EMSK MUST be deleted when the
session for which it was
> > created is
> > > > > deleted.
> > > > >
> > > > > EMSK SHOULD be deleted sooner, when
it is no longer
> required.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Salowey, Joe
[mailto:jsaloweycisco.com]
> > > > > > Sent: Wednesday, March 08,
2006 1:23 PM
> > > > > > To: Narayanan, Vidya; Avi
Lior; Jari Arkko
> > > > > > Cc: eapfrascone.com
> > > > > > Subject: RE: [eap] Strawman
-10/EMSK deletion requirement?
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Hope this helps,
> > > > > >
> > > > > > Joe
> > > > > >
> > > > > > > -----Original
Message-----
> > > > > > > From: Narayanan, Vidya
[mailto:vidyanqualcomm.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
|