Hi,
> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan qualcomm.com]
> Sent: Thursday, March 09, 2006 6:53 PM
> To: Avi Lior; Salowey, Joe; Jari Arkko
> Cc: eapfrascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion
requirement?
>
>
<snip>
> > 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.
> >
>
> I wonder if this is a problem - if we want the EAP AS
to
> generate the EMSK/AMSK and cache it for an entity (such
as a
> MIP HA) to fetch the AMSK later upon receiving a BU or
> something, the HA will only contact the AAA server. Or,
do
> you envision the AMSK in such cases to be sent to the
AAA
> server for caching?
We don't want the EAP AS to cache the AMSK.
The AAA isnt responsible for caching either. If we consider
RADIUS,
RADIUS is stateless, it has no caching capabilites at all.
Diameter
does (however).
So AMSK is cached outside the EAP AS and outside AAA - I
belive the AMSK
is cached in another functional entity called a
KeyHolder/KeyGenerator.
That solves the problem for RADIUS.
> <snip>
>
> > > 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"
> > | ......)
> >
>
> As far as the EAP server is concerned, I'd argue that
FOO-A
> and FOO-B are different applications. So, we could just
say
> that no more than one EMSK for a given key label is
allowed.
Fine with me. Its not about defining an application but
rather the
important piece is defining the concept of a label.
Because you have this possiblity as well and sounds like a
lable needs
to be precisely defined.
FOO-A = KGF(EMSK,"FOO" | "A" |
....);
FOO-B = KGF(EMSK,"FOO" | "B" |
....);
So the first part "FOO" is the lable and it is
the key name and
therefore must be unique within each session. Therefore,
although FOO-A
<> FOO-B, the above is illegal.
>
> > I don't know why an application FOO would like to
do this.
> Maybe FOO
> > application is really two applications.
> >
>
> <snip>
>
>
> > >
> > > > > 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?
> >
>
> I'd personally be okay with leaving this out - even if
it is
> recommended to be deleted, implementations are likely
to
> cache it for practical reasons anyway.
I agree.....but I am easy going about this either way.
> Vidya
>
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|