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

[Vanderveen, Michaela (MCV]

<snip>

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

MCV>> The nonces are often sent over a wireless link, so
open for anyone (including a devious AAA server) to listen
to. 


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 ? 

MCV>> I don't think there is any useful attack here.
I find it odd that the AAA server is trusted and then
all of a sudden (once keys get derived) becomes
"suspicious". The problem seems to be one of "access"
i.e. need-to-know basis. If the AAA server was truly
trusted, then if it did not need to know the transported
key, then it would be ok to keep the key from it. But
since it already knows it, it doesn't make sense to 
enforce that it deletes this key.

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

_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================