eap Mailing List: Pre-issue discussion: Key-caching and Key Request interactions

[Bernard Aboba (aboba]

In going over Section 4, I came across an area which we have not discussed
very much:  key caching on the backend server.

Some proposals seem to assume that the keys exported by EAP methods remain
on the AAA server for some time after their creation.  For example, the
pre-emptive handoff proposals appear to assume that the exported keys
remain on the AAA server, where they can be used to generate additional
AMSKs, based on the EMSK.

It also seems that proposals for "Key Request" functionality
assume the existence of a key cache on the backend server.  After all, for
a "Key Request" to be honored, there has to be keying material present on
the AAA server that can generate the requested key.

One question about such a cache, if it exists, is what exactly is cached.
Since the AAA server does not produce TSKs directly, and does not have
access to EAP method internal state, TSKs and TEKs cannot be cached on the
AAA server.

Since keys transported by the AAA server are deleted, such a key cache
cannot include the AAA-Key.  Once the AAA-Key is sent, it is deleted from
the AAA server, in order to prevent the transported key from being
replayed.  If the AAA-Key was based on the MSK, the MSK is gone too.
However, since the EMSK is never transported, this can be cached, and
serves as the root of the hierarchy of AMSKs.

Based on this, my conclusion is that the AAA-Key cache, if it exists,
consists of EMSKs.  AMSKs are not cached because they are created
on demand and are deleted once they are transported.

The next question is:  how long do the cached EMSKs live?  My answer is
that they are kept by the AAA server until Session-Time after the EAP
authentication that generated them.  Once the EAP authentication completes and 
the
AAA-Key is sent a timer is set to Session-Time, and after it runs out, the
EMSK and all derived keys are deleted.  The timer does not stop if the
session ends.  Also, the timer starts when the AAA-Key is sent, not when the
session starts, because in some cases the session might start considerably
after the AAA-Key is sent (e.g. pre-authentication).

However, the value of Session-Time is not communicated to the peer either
by AAA or EAP.  So how does the EAP peer know when an EMSK/AMSK has
expired?  I think the answer is that the EAP peer needs to be informed by
the lower layer, otherwise its key cache cannot be synchronized with the
authenticator and backend server.

So we've talked about how the key cache on the AAA server might work, and
what is in it (EMSKs).  Given this, how does a "Key Request" work?

As I understand it, a peer uses a protocol other than EAP (e.g. a lower
layer) to request that the authenticator retrieve a key, naming that key
according to the EAP Key Naming scheme.  Since we've already said that the 
backend
server does not cache MSKs (since they're deleted after transport), and
the EMSK is not transportable, the key name must be the name of an AMSK.

That's well and good, but how does the authenticator know which backend
server to request the key from?  Typically an authenticator is configured
with multiple AAA servers, or sometimes with one or more proxies which can
route to multiple home AAA servers.  So there may be quite a few choices.

Some ideas come to mind:

a. The peer may know the name of the AAA server with which it completed
the EAP exchange (deriving the MSK and EMSK), and can tell the
authenticator using a lower layer protocol.  The authenticator can then
send an Access-Request containing a Key-Request attribute to the AAA
server named by the peer.

However, there are problems with this.  While some EAP methods provide
the server name, some methods do not.  Thus, such an approach is not
method independent.  Also, some reflection on the operation of a
directed "Key Request" attribute discloses that it introduces
operational issues.  The problem is that a directed "Key Request"
attribute must cause the authenticator to direct an Access-Request to a
specific AAA server.  However in practice this is very difficult.

The authenticator may not be set up to speak to the AAA server, it may
only talk to a AAA agent who will route the request.  This implies that a "Key
Request" attribute needs to be placed in the Access-Request that can be
interpretted by a proxy so as to cause the message to be routed
appropriately.  No proxies do this today, so there is a backwards
compatibilty issue.  Plus, what happens if the proxy isn't set up to talk
to the requested destination?  What error message is sent back?

b. Proxies along the path route the Key Request based on the NAI in some
way that guarantees that the request goes to the same server as the one
that generated the exported keys, without explicitly naming it.  For
example, if the EAP session-id space were partitioned, then it might be
possible to route the key request appropriately based on that alone.

However, I don't think this works either because the Session-Id has no
hierarchy, being based on nonces or counters.  Also, this approach again
assumes that proxies interpret the Key Request attribute in order to route
packets.

c. The AAA servers share a unified key cache.  This allow for proxies to
operate normally, since all they have to do is route the Access-Request
based on the NAI.  Since any server within a realm can access the unified
key cache, it doesn't matter which server receives it.