Subject: RE: [eap] RE: Issue: AAA Key Caching effectively prohibited?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 3 Nov 2005 17:02:59 -0500

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:[email-masked]] 
Sent: Wednesday, November 02, 2005 6:49 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; Bernard Aboba; [email-masked]; [email-masked]
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:[email-masked]]
> Sent: Tuesday, November 01, 2005 2:41 PM
> To: Bernard Aboba
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
> 
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 03 Nov 2005 18:18:23 -0500

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 03 Nov 2005 16:18:16 -0800

>good to put the KDF in a separate entity from the AAA server.

How could an entity other than the EAP peer or server gain access to the 
EMSK in order to generate AMSKs?  The EMSK cannot be transported, so only 
the EAP peer and server can have access to it.   An entity must have access 
to the EMSK to apply a Key Distribution Function (KDF) to it in order to 
produce an AMSK.  So therefore only the EAP peer and the EAP server can 
apply a KDF to the EMSK to produce AMSKs.

Of course, a KDF is just a cryptographic function, not anything magic, so 
any entity (EAP peer, authenticator, server) can call the function.  They 
just can't use the EMSK as an input to it.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 03 Nov 2005 19:13:32 -0500

> apply a KDF to the EMSK to produce AMSKs.

If we use generic AMSK to derive other AMSKs, the EAP server can
derive the generic AMSK from the EMSK and give it to the entity
providing KDF (and I think the generic AMSK should be
cryptographically bound to the identity of the KDF entity which could
be the AAA server or something else in general).  Once it is done, the
generic AMSK can be deleted from the EAP server and no entity needs to
access the EMSK and the generic AMSK.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Nov 2005 16:29:45 +0200

>>>good to put the KDF in a separate entity from the AAA server.
I am confused by this. KDF is a function, not an entity. Every we subdivide
the key hierarchy in some manner we need a function to do this... this
happens in different places in the network, depending on what level of
keys we are talking about.

>>apply a KDF to the EMSK to produce AMSKs.
Agreed.

>access the EMSK and the generic AMSK.
We can have lower layer ask for AMSKs. Such AMSKs can have further
hierarchy. But I don't think we should have a generic AMSK in the
sense that its used for multiple applications. One per app, be it
mobile ipv6 with ha x, or handoffs within this domain, or...

--Jari