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

[Yoshihiro Ohba (yohba]

What protocol do we assume for transporting an application-specific
key from the entity that implements KDF (Key Derivation Function) to
application-specific entities?  I think we don't always assume a AAA
protocol for this transport, Kerberos could be used for example and in
that case no key needs to be cached in the AAA server/proxy/client
once the generic AMSK is passed to the entity that implements KDF.

Regards,

Yoshihiro Ohba

On Wed, Nov 02, 2005 at 04:20:26PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> 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
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
> 
>