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

[Bernard Aboba (bernard_aboba]

> From what I can recall, our earlier discussions about this focused on
> the MSK. I'm not sure the same should apply on AMSKs, particularly
> when we haven't defined what they are used for.

The principle is a general one -- if a key that is transported is to be  
used for derivation of TSKs that are only to be known to the EAP peer and 
authenticator who need to be able to mutually authorize each other, then 
that same key cannot also continue to be held by the  AAA server.   If the 
AAA server continues to hold the key, then the TSKs will also be known by 
the AAA server;  also, the peer cannot know whether the entity proving 
possession of keying material is the EAP authenticator, or an imposter such 
as the AAA server.

As an example, the Secure Association Protocol relies on mutual proof of
possession of keying material to enable the EAP peer and authenticator to
determine that they are mutually authorized.  If the keying material used
for proof could also possessed by other parties then mutual
authorization is not demonstrated -- the EAP peer could be talking
to the AAA server or a proxy instead of the EAP authenticator.

As a result, without key deletion, the EAP peer and authenticator no longer 
demonstrate authorization; neither the transported keys nor the derived TSKs 
are uniquely held;  the scope of
transported keys and TSKs is undefined; even Channel Bindings become open to 
forgery.  About the only thing that can still be asserted about the exchange 
is that the TSKs are fresh -- although it's questionable how valuable this 
is if the other properties are absent.

> But it seems possible to hand keys to lower layers (e.g. AAA server
> side logic) that are themselves branching of to number of subkeys.
> E.g. "the master handoff key for session xyz". The entity holding
> such an AMSK can then branch it to, e.g., "the i:th handoff key
> for NAS abc". There's a lot of room to do various designs, including
> proxy, AAA-server etc. based caching.

Right.  I think this solves the problem.