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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Jari, 

Ok, if people feel strongly about not exporting the EMSK to the lower
layer. Then it would seem that a generic AMSK needs to be generated and
passed down to the lower layer (AAA server). The AAA server then should
be able keep the AMSK and to generate other application-specific keys
from the AMSK. 
Furthermore, it should be possible for the AAA server to not to delete
every key it has transported to the pass-through authenticator

Madjid

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

Bernard Aboba wrote:

> I would like to point out one other consequence of preventing lower 
> layers (including AAA) from accessing the EMSK.  It appears to me that

> this severely restricts implementation of a key cache on the AAA
server.
>
> 1. We've talked about deletion of transported keys from the AAA 
> server.  So if an MSK (or AMSK) is calculated within the AAA layer and

> subsequently transported, that key is destroyed and cannot be cached.

 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.

> 2. We've talked about how the EMSK cannot be passed down to the lower 
> layer (including AAA).  Therefore the EMSK also cannot be cached by 
> the AAA layer.

This I still think should apply.

>
> 3. Given 1) and 2) what keys *can* be cached in the AAA layer?  
> Limited answers appear to be available.  Caching of MSKs does not make

> much sense, even if they are not transported in a particular 
> application, because some applications *do* transport MSKs.
>
> It would be possible for the AAA layer to request more than one AMSK, 
> then cache the AMSKs that are not transported.
>
> However, this approach does not appear to enable implementation of 
> schemes such as "Key Request" and "Pre-emptive Key Distribution", both

> of which appear to require the AAA layer to calculate AMSKs *on
demand*.
>
> To be able to do this, it would seem like the AAA server would need to

> have access to the EMSK -- since the EAP layer doesn't cache EMSKs, 
> how else could AMSKs be calculated once EAP authentication completes?
> In the case of roaming systems it is not feasible to ask the EAP layer

> to calculate every conceivable AMSK that could be useful -- there 
> could be thousands of them.

I think the answer lies in where the hierarchy is split. I still believe
EAP server should hold to EMSK and calculate AMSKs on demand.
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.

--Jari