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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

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