eap Mailing List: Key caching discussion at IETF 62

[Bernard Aboba (aboba]

At IETF 62, we had a discussion relating to EAP key caching behavior.
This is an attempt to summarize that discussion so as to expose it to
review within the EAP WG.  Once we have consensus on this, a summary will
be put forward for inclusion in the EAP Key Management framework.

According to RFC 3748, EAP methods deriving keys must export the MSK and
EMSK and may optionally provide an IV.  Each of these fields is at least
64 octets in length.

In addition, the key management framework defines other quantities that
may be exported.  This includes the EAP session-ID, the peer-ID and the
server-ID.

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.

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.

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.