eap Mailing List: issue 299: key cache structure

[Jari Arkko (jari.arkko]

Another open issue:

> Currently, EAP lower layers such as 802.11i implement a key cache on the
> EAP peer and authenticator.  No current AAA server implementation includes
> support for a key cache.
>
> At IETF 62 we discussed some of the implications of this.  In particular,
> was it a good thing for EAP lowers to maintain their own key caches, or
> should a cache also exist within the EAP layer?
>
> During the meeting, Sam Hartman suggested that there were significant
> security advantages to the existing architecture.  In today's
> implementations, there is no key cache in the EAP layer.  Once the EAP
> method completes and passes up exported keys, they are provided to the
> lower layer and are no longer available to the EAP layer.
>
> Some of the implications of this include the following:
>
> a. EAP does not support sharing of keys between lower layers.  In the
> existing architecture once keys are passed down to the lower layer they
> cannot be retrieved.  This implies that keys are provided to the lower
> layer over which EAP runs, and no other application can obtain them. This
> prevents compromise of one lower layer from compromising other
> applications using EAP keying material.
>
> b. The cache structure is defined by the lower layer.  As has been
> discussed, EAP itself does not negotiate a key lifetime and EAP methods
> also may not negotiate this.  As a result, the key lifetime and key
> caching behavior will typically be handled solely within the lower layer.
> While keys derived between the EAP peer and server are not inherently
> bound to a particular interface, the lower layer may impose additional
> usage restrictions on keys.  For example, it may state that a peer may
> only use derived keys on the interface over which EAP was run.
This all makes sense. I would suggest adding text starting
from "Some of the implications ..." to end of Section 4.1.

> One additional issue to think through is the implication for EAP key
> naming.  If only the lower layer obtaining the keys can use them, then
> there may be no reason why the lower layer can't implement its
> own key naming scheme.
>  
Right, and they have. This puts the following text under
suspicion:

(Section 7.2)
Key naming
    In order to ensure against confusion between the appropriate keying
    material to be used in a given Secure Association Protocol
    exchange, the AAA-Token SHOULD include explicit key names and
    context appropriate for informing the authenticator how the keying
    material is to be used.
And Section 1.3.2 may need a note saying that the suggested
key naming scheme for other quantities than the EMSK
is provided as an example, and lower layers may employ
other means of key identification.

> The only issue that might arise is if the AAA server needs to maintain its
> own key cache in a future extension.  In terms of key management, AAA
> functions like another EAP lower layer, so that it can maintain its own
> cache.  However, AAA may be used by multiple applications so that the peer
> might have lower layer specific caches and key names while the server
> would have a single unified cache and therefore might require a unified
> key name.  This seems like it could become a problem.
As far as I can see, the interoperability requirements for
this dictate that either (a) the lower layers are sharing
the same key, which would be bad, or (b) everyone's aware
that they are using the "multiapp aaa keys". If the latter
are based on quantities such as the EMSK and we have
named that, then there is no problem. Makes sense?

Btw, parts of the document talk about key caching without taking
into account that we can have methods that do fast reconnect
and other things that require caching state at the method
layer. For instance, in Section 4.1:

  In existing implementations, key caching may be supported on the EAP
  peer and authenticator but not on the backend server.

should probably read

  Key caching may be supported on the EAP peer and
  authenticator but not on the backend server (except at
  the EAP method layer).

--Jari