eap Mailing List: RE: Issue: AAA Key Caching effectively prohibited?

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Keys can't simultaneously be transported and cached.  So either a given
AMSK is cached, or it is transported, not both. Otherwise you end up
with multiple parties in possession of the TSKs -- which violates one of
the fundamental security goals.

Madjid>>Why not both? Please remember that as I said earlier, even if
the AAA server can listen to the exchanges leading to the TSK
generation, AAA server is still considered as the main source of trust
in many network architectures. 
We know that many SDOs and technologies today do key context transfer at
the edge, so I am not worried about keeping the cache at the AAA server,
especially knowing that the AAA server may be asked for it later. I need
a solution that work both mobility and security wise, so if the tradeoff
is to trust a AAA server I will take it.


Can you describe your reservations?  In looking at AAA server caching,
it seems to me like it could open up a lot of new security
vulnerabilities, some of which we may not be able to anticipate.

For example, if a key exists in a AAA server cache, does the EAP peer
know where that key is, and how to reference it?  If the EAP method
doesn't export a Server-ID, I think the answer to this question is "no".

Madjid>> The current specification needs to be clear on the boundaries
of EAP server and AAA server and what is done in EAP layer and what is
done through AAA protocol. Once we have a crisp spec, then we have a
crisp problem definition and such problems are typically easier to solve
and whether layer pollution is a severe violation. This is similar to
the channel binding problem.

Madjid