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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Bernard,

Thanks, Actually this is the very reason I initiated this discussion. So
I think we are now converging our focus on the problem.
We need a key that can be passed to the AAA server, so that the AAA
server can use this key (instead of creating something completely
random, which is expensive) for an application that AAA server has the
right to authorize, without the AAA having to destroy the key after
transporting it.

It seems that the AMSK as an "application master key" is being derived
from EMSK, so unless there is one additional hierarchy level between
EMSK and AMSK, three things are needed:

The EMSK to be exported to AAA server (I am ok if we say EMSK is not
exported to a generic lower layer, but only to the AAA server and not
transported out of AAA server).

The AMSK is generated at the AAA server using EMSK and
application-specific information, if needed (e.g. authorization info)
information. 

The ability for AAA server to cache the AMSK as long as the EMSK is
valid.

This way the AAA server and EAP keying framework can be used in a very
clean way to bootstrap keys for many applications. Ordering the AAA
server to delete the AMSK will prohibit the use of this framework by
many of its current constituencies, examples: 

WiMAX Proxy Mobile IP: needs a Mobile IP key between the authenticator
and the home agent, AMSK can be the PMIP key to be shared between an
authenticator acting as a proxy mobile IP client and the home agent. You
send the key separately to authenticator and to Mobile IP HA. If you
delete it after first transport, how could the HA can come ask for it.

Several EAP methods (EAP-AKA) are adding fast re-authentication
procedures, based on the knowledge of master key (have to read the draft
again, to see which key is needed) after the initial authentication. If
you delete the key, you cannot perform fast re-authentications.

Handover, say another authenticator gets involved after the handover, if
you delete the initial master keys, what would the AAA server do when it
receives a request from the new authenticator?


Madjid



-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Tuesday, November 01, 2005 12:56 PM
To: bernard_aboba [at] hotmail.com; Nakhjiri Madjid-MNAKHJI1;
aboba [at] internaut.com
Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
Subject: Issue: AAA Key Caching effectively prohibited?

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.

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.

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.