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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Wednesday, November 02, 2005 11:52 AM
To: Nakhjiri Madjid-MNAKHJI1; jsalowey [at] cisco.com; aboba [at] internaut.com
Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
Subject: RE: [eap] Issue: AAA Key Caching effectively prohibited?

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

Madjid2>> Say, I need two keys for two authenticators, do I create a K1
and K2 from AMSK at the AAA layer?
If yes, then do I have to delete K1 after sending it to authenticator 1?

If no, and K1 and K2 are considered AMSK1 and AMSK2, do I have to send a
request for two keys to EAP server, before it deletes the EMSK?
On the top of all this,last time I looked at extensions draft,
definition of AMSK includes both EMSK and AAA key, 
>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.

Madjid2>> See previous question, please

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

Madjid2>> The word of "Pre-emptive" is dangerous here? Does it mean the
AAA server pre-emptively asks for multiple AMSKs from EMSK? 
For Handover, this will not work, you have to anticipate all the
moves... 

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

Madjid2>> By "rainy day", I was referring to "for future use" in 
        "The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived;"
In the 08 draft. And by the way this conflicts "deleting EMSK right
away..."

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.

Madjid2>>Well, I am advocating for several layers as well, that is why I
am asking for AMSK clarfications and delete requirements. May your
latest look was later than mine and 11r is a happier family than
WiMAX/16e:) but at least in WiMAX, nobody knew about the latest "delete
key" requirements until very recently and that is why I started my
review. I don't want to deal with a hierarchy that chops itself off
prematurely..

>Madjid>> I gave 3 examples in my previous email. Are we now creating 
>Madjid>> 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.

Madjid2>> I think people have already started inserting a Kerberos into
the mix, so KDF is more than a function ;)