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

[Mohan Parthasarathy (mohanp]

Bernard,

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

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 ? 

-mohan

> 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.
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap