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

[Yoshihiro Ohba (yohba]

I think it makes sense to have the KDF in the AAA server only when (1)
such an entity resides in the same domain as the AAA server and (2)
use of the AAA protocol for distributing application-specific keys to
application-specific entities is assumed.  For other cases (i.e.,
bootstrapping applications in visiting domain or using non-AAA
protocol for distributing application-specific keys), it might be
good to put the KDF in a separate entity from the AAA server.

Yoshihiro Ohba

On Thu, Nov 03, 2005 at 05:02:59PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> I tend to think of AAA protocol as a horizontal protocol (i.e. between
> AAA server and AAA client) and that is btw why I have problem with the
> word export. The only reason I am striving for a clarity between EAP
> server and AAA server is to have a spec that always further use of the
> keys generated by a heavy EAP-XXX authentication. So I am saying if EAP
> server has throws the keys away to not overload itself, fine lets AAA
> server handle the authorization and key management issues for "at-the
> time of EAP-unknown" applications. I was not necessary advocating for a
> physical separation of the EAP and AAA server. Given I tend to read the
> specs as if AAA layer is a layer below the EAP layer (I Know Joe does
> not agree with this), I think this is a vertical layer separation, so
> you can't use a AAA protocol here. I do think that this "API" may need
> to be defined. 
> All that being said, I think the AAA servers of today or immediate
> future have the capability of doing key generation as long as a initial
> key with good entropy is provided to them by an EAP method, so even if
> there is a KDF, I tend to think it is "co-located" with AAA server. I am
> not sure how adding a KDF helps the problem I am trying to solve: I am
> saying somebody needs to create keys and not throw them away after it is
> transported, not sure how KDF versus AAA server separation helps that
> cause.
> 
> Madjid
> 
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com] 
> Sent: Wednesday, November 02, 2005 6:49 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Jari Arkko; Bernard Aboba; aboba [at] internaut.com; eap [at] frascone.com
> Subject: Re: [eap] RE: Issue: AAA Key Caching effectively prohibited?
> 
> 
> 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
> > 
> > 
> 
>