> > > 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.
>
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?
<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.
> 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.
Vidya
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|