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

[Mohan Parthasarathy (mohanp]

--- Bernard Aboba <bernard_aboba [at] hotmail.com> wrote:

> >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).
> 
Sure, but we are talking about the AAA server and the 
authenticator involved in the exchange. We can
find whether the key has been spread to other
authenticators. But can the peer tell the difference
between the authenticator and the AAA server ? 
Does it matter ? In your other response you said:

> Also by deleting the transported 
>keys, the EAP authenticator and peer can derive other
>keys (the TSKs) 
>known 
>only to those parties and not to the AAA server

AAA server cannot derive TSKs even if it did not
delete the transported key because the secure
association protocol exchange involves other
parameters e.g. nonce, in the exchange that is known
just to the authenticator and the peer.

So, what useful attack can the AAA server (which the
peer has a trust relationship with) do by holding
on to the transported key ? Even if it holds on to it
(erroneous or deliberate), but can never derive any
keys that will be used in the commuication between the
authenticator and the peer, would it not be okay ?
I understand that from security point of view, it
makes
no sense for three parties hold on to the same key.
But here the AAA server cannot do much with it
i guess. At least, it cannot send it to other NASes
as the peer can find it out as you have explained
below. Are there any other attacks we are concerned
about ? 

-mohan


> 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.
> 
> 
>