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

[Bernard Aboba (bernard_aboba]

> [Joe] Mostly I have reservations about caching the EMSK.  The EMSK is
> the root of a hierarchy and if you can obtain that then all uses derived
> from it are compromised.  Therefore it would be good to destroy it as
> soon as possible.  AMSKs should be cryptographically independent and it
> should not be computationally feasible to get the EMSK from and AMSK.
>
>
> I agree.
>
> Note: "destroy EMSK as soon as possible" can be
> interpreted in various ways. I don't think it would be appropriate
> for the EAP server to get rid of the EMSK problem by delivering
> it to the lower layer and forgetting about it. Essentially, the
> EMSK needs to stay in the physical box where the EAP method
> runs, but we have had troubly defining what that exactly
> means. Also, it only needs to exist while there's a possibility that
> AMSKs can be requested. This is another hard-to-specify part -
> when can AMSKs be requested?

I think the way that the architecture is specified now, it is not possible
to cache the EMSK.  Only lower layers are allowed to cache, and the lower
layer (including AAA) never obtains the EMSK, only AMSKs.

My assumption has been that AMSKs can only be requested by the lower layer
while the EAP method is running.  As Joe suggested, if there is a need for
*on demand* keys, this can be satisfied by deriving them from an AMSK.
Since the EAP layer does not cache keys, there is no way for a lower layer
to request an AMSK at some other time, since the EAP layer will not have
any keying material with which to carry out the request.

My own reservations with AAA server caching derive from the issues
surrounding "on demand" key creation:

a. Presumably keys are created "on demand" only when requested by either
the EAP peer or authenticator.  This implies that the EAP peer or
authenticator keep track of which AAA server is caching which keys, so
that they can direct subsequent requests to a server capable of answering
them.

b. However, all EAP methods do not provide the Server-ID, which uniquely
identifies the EAP server which has produced a given key.  Also, an EAP
authenticator/AAA client may not necessarily control which AAA server it
is talking to; it just sends an Access-Request with an NAI in the
User-Name attribute and it is routed to a destination.  The Access-Accept
may not identify the originating AAA server well enough to allow the AAA
client to go back to that same AAA server again to request an "on demand"
key from it.  Given this, it is not clear to me how a "Key Request" mode
could be made to work with all EAP methods or AAA configurations.