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

[Bernard Aboba (bernard_aboba]

> I am missing one thing here. Even if we specify that the keys SHOULD be 
> deleted
> after it is transported, how do you prevent a mis-behaving AAA server that 
> does
> not follow this. In other words, if there are mis-behaving/erroneous AAA 
> servers
> out there, there is no way the peer can find out. Does this mean the peer 
> can
> never be sure who he is talking to ?

Actually, the peer does have a mechanism for determining whether keys have 
been spread beyond their intended scope.  This is handled by the explicit 
identification of the parties involved in the key exchange, and by mutual 
authentication, and by the explicit binding of keys to their context (such 
as via Channel Bindings).

For example, if the AAA server does not delete transported keys, and resends 
them to another NAS, if the NAS is properly identified in the SAP exchange, 
then the peer can determine that it has access to keys that it is not 
authorized to possess.  If the keys are bound to their context, then the 
peer can detect a binding mismatch.

For example, on Yoshi's proposed "Channel Bindings" proposal, it is not 
possible for the AAA server to send the same key to multiple NASes and have 
the EAP peer successfully negotiate use of that key, because the key is 
bound only to the NAS that the EAP peer believes it should be communicating 
with.