eap Mailing List: Use of KDCs and AAA

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

I would like to call this KDC (center rather than function) to avoid
confusion between a logical entity and a mathematical function.  I am
not sure if it is up to EAP WG to design AAA server architecture. All
that aside, 
If people feel it is more appropriate to have that separation, fine. I
suggested separation of AAA client from a local key distribution center,
so separation of AAA server from a central KDC is along at line.
 
The other issue is that the KDC must have a key available from EAP
keying hierarchy that it can use to generate keys for applications that
AAA server has authorized.  So I can see the following model

                                EAP server
                                        | XMSK keys
                                        V
App ----->authorization------> AAA server-------key request----->KDC
Agent           request

This is pretty much in line with one of sequences in authorization
framework of RFC 2904.

Madjid

                                
-----Original Message-----
From: eap-admin [at] lists.frascone.com [mailto:eap-admin [at] 
lists.frascone.com]
On Behalf Of Yoshihiro Ohba
Sent: Thursday, November 03, 2005 5:18 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Yoshihiro Ohba; Jari Arkko; Bernard Aboba; aboba [at] internaut.com;
eap [at] frascone.com
Subject: Re: [eap] RE: Issue: AAA Key Caching effectively prohibited?

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
> > 
> > 
> 
> 
_______________________________________________
eap mailing list
eap [at] lists.frascone.com
http://lists.frascone.com/mailman/listinfo/eap