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

[Bernard Aboba (bernard_aboba]

> [Joe] I don't think we have said that the AMSK must be deleted or cannot
> be cached.  It should be the contrary, the AMSK is a quantity that an
> application such as AAA can use for the purpose it has defined.

Agreed.

> Madjid>> AAA can _use_? How about create and keep?

The AAA layer cannot create an AMSK because it does not have access to the 
EMSK. So it can only receive an AMSK.

> [Joe] This depends on how you define your key hierarchy.  If you derive
> your keys directly from the EMSK you have a problem.  If you define your
> keys from an AMSK derive for the purpose of pre-emptive key distribution
> then things work out a bit better.

Right.  This makes sense.

> Madjid>>Are you saying we create our application specific keys out of
> AMSK that is already called application master key?

No.  We are saying that the AMSK is used as the root of a lower layer key 
hierarchy.

> Not sure what "rainy day" we are saving EMSK for? Why have so many key 
> levels, does anybody
> care about the CPU and battery consumptions down at a tiny mobile device
> that may have to do all this?

The EMSK is not cached, so there is no "rainy day" that it is being saved 
for -- it is used to calculate AMSKs passed to the lower layer and then is 
lost.

BTW, a concern about key hierarchy depth and handoff does not appear to be 
shared by the organizations that are designing those protocols.  IEEE 
802.11r, for example, had three layers of key hierarchy last time I looked.
> Madjid>> I gave 3 examples in my previous email. Are we now creating yet
> another entity in the protocol?

No other entities have been discussed so far.

> What is a KDF in relation to EAP server and AAA server?

KDF = Key Distribution Function.   This is a cryptographic function used to 
calculate AMSKs.  It is not an entity.