>
> >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."
> >
> >
> I think I can live with this text. As I said in a
previous
> e-mail, I have been convinced that we need to support
some
> form of dynamic generation of AMSKs.
>
> We also seem to be coming to a consensus on keeping the
EMSK
> at the server side.
>
> But I still have a few nagging thoughts:
>
> 1. In order to avoid a situation that suddenly all AAA
> servers need to start
> keeping state, do we need to require an
authorization profile
> flag, configuration knob, or attribute to signal
the need for
> keeping state?
>
I wonder if this could be handled by policy alone. A flag or
signal
would be better and more explicit - did you think this would
be signaled
by the peer? The authenticator will not have sufficient
knowledge about
the applications that the peer is interested in and hence
this should
probably come from the peer - now, we are talking about
introducing this
into EAP messaging - right?
> 2. The text does not tell us how to determine when all
necessary
> AMSKs have been generated.
>
Maybe the text should also say "The server may have
policies to indicate
the number of AMSKs a peer is authorized for - once those
are derived,
the EMSK is deleted" - ?
-Vidya
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|