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

[Jari Arkko (jari.arkko]

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