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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

I am not sure I understand this security model, if we are not trusting
EAP server or AAA server with not sniffing TSK derivation, or we have
issues with the server knowing the TSKs, how could we trust it to
actually go ahead and delete the keys?? 

What kind of security model is it that instead of hiding a secret to
begin with, ask the untrusted party to create it first and then delete
it really quickly??

Now all that aside, are we saying have an AMSK generated from EMSK, and
then pass AMSK down to the AAA server and then derive all application
keys from AMSK? 
Can the AAA server still keep the AMSK? What about the application keys?
Can it keep them even after sending them away, or the same security
philosophy applies here?

-----Original Message-----
From: Bernard Aboba [mailto:aboba [at] internaut.com] 
Sent: Tuesday, November 01, 2005 3:07 PM
To: Jari Arkko
Cc: Bernard Aboba; Nakhjiri Madjid-MNAKHJI1; eap [at] frascone.com
Subject: Re: Issue: AAA Key Caching effectively prohibited?

> 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, then that same key cannot also continue to be held by
the EAP server, or the fundamental security assumption is no longer
valid.  

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.  

In this situation, the security model of EAP falls apart -- the EAP peer
and authenticator no longer demonstrate authorization; the keys are not
uniquely held;  Channel Bindings are subject to forgery;  the scope of
transported keys and TSKs is undefined.  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.