eap Mailing List: Re: Strawman -10/EMSK deletion requirement?

[Jari Arkko (jari.arkko]

Madjid, Avi,

> The only reason for caching the EMSK is if you have to generate an AMSK
> for another application associated with the current session.
>
> Madjid>> Thank you for clarification. Another example may be roaming to
> another access technology!!
>
> 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?
>
> Madjid>>i.e. keep EMSK for future AMSK generation. The first option will
> create the need for running EAP again.
>
>  
We have discussed this before... I do not see an issue for handoffs
to another access. If your AAA server supports this then it derives
AMSK_ho_root from EMSK, deletes EMSK but keeps the derived
key. Once a need to do a handoff arrives, you derive AMSK_ho_key1
from AMSK_ho_root, next time you will derive AMSK_ho_key2, etc.

Having said that, I do agree with Avi that there's really no substantial
difference between "<x> MUST be deleted after <y>" and "<x> MUST
be only used for <y>", except maybe some implementation note describing
that it would be a good idea to securely delete the value once you
know that <y> is done.

But part of this debate is really not about whether the key should
be deleted, but rather about whether we know the applications
a priori. I think there are practical and security reasons why it
is a good idea to set a requirement that the applications are known
a priori. First of all, there are no surprises to the AAA server; it
needs have specific authorization to serve a particular
application. (Possibly even specific code.) Secondly, as we
are currently in a world where the AAA servers cache no
keys at all, we need to avoid a situation where AAA servers
end up storing a lot of key state and have no way of knowing
when it is needed. Finally, security-wise I want to know what
my EAP authentication somewhere means. I, as the end user,
do not want surprises. It is better to limit the set of applications
of the keys at the beginning. Note that if you want, you can
set up state for handoff/SIP/MIP even if you do not know they
will actually be used; you set the state and keys based on
the user's authorization profile.

Based on the above, I still like the design where we know
the possible applications (and AMSKs) at the first authentication.
But we could write the text slightly differently, based on what
you Avi suggested.

--Jari