Subject: [eap] issue 299: key cache structure

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Jul 2005 17:48:39 +0300

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 Jul 2005 14:58:29 -0700 (PDT)

> from "Some of the implications ..." to end of Section 4.1.

Here is a rewrite of Section 4.1.  What do you think?

"4.1.  Key Caching

Where explicitly supported by the lower layer, the EAP peer and
authenticator lower layers MAY cache the exported EAP keying
parameters and/or TSKs.  The structure of this key cache
is defined by the lower layer.  Unless explicitly specified by
the  lower layer, the EAP peer, server and authenticator MUST assume
that peers and authenticators do not cache exported EAP keying
parameters or TSKs.

Once keying parameters exported by the EAP method are passed down to the
lower layer, they cannot be retrieved or transported to another entity.
This implies that sharing of exported EAP keying parameters between EAP
lower layers is forbidden.  This prevents compromise of one lower layer
from compromising other applications using EAP keying parameters.

The exception to the "no sharing" rule is the AAA layer.  On
EAP server, keying material passed down to the AAA layer may be replicated
to the AAA layer on the authenticator.   On the authenticator, the AAA
layer may provide the replicated keying material to the lower layer
over which the EAP authentication conversation took place.  This
enables "mode independence" to be maintained.

In existing AAA server implementations, all exported EAP keying parameters
(including the MSK, EMSK and IV) as well as derived keys are not
cached and MUST be presumed lost after EAP authentication completes:

[1]  In order to avoid key reuse, on the EAP server, transported keys
     are deleted once they are sent.  An EAP server MUST NOT retain keys
     that it has previously sent to the authenticator.  For example, an
     EAP server that has transported the MSK MUST delete it, and no keys
     may be derived from the MSK from that point forward by the server.

[2]  Keying parameters which are not transported, such as the EMSK, are
     also deleted by existing AAA implementations.

EAP does not support key lifetime negotiation and EAP methods
also may not support this.  As a result, the key lifetime and
key caching behavior is typically defined within the lower layer.
While EAP keying material exported by the EAP peer and server are
not inherently bound to a port, the  lower layer may impose
additional usage restrictions on derived keying material.
For example, a lower layer may require that a peer only use
derived keying material on the interface over which EAP was run."

> >own key naming scheme.> >
> >

I think we need to revisit much of Section 7, but I agree that this text
is suspicious.

> 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.

While the AAA key management document says that key names can't be derived
from the keys themselves, this still leaves other mechanisms for key
naming.  For example, IEEE 802.16e D7 included the Session-ID in its key
naming scheme. D8 removed it (because existing AAA servers do not
replicate this parameter), but as I recall, the new scheme isn't based on
a hash of the key.

> named that, then there is no problem. Makes sense?

The schemes involving AAA key caching that have been suggested so far seem
to all involve a NAS requesting a key from the AAA server.  In "Key
Request" schemes, as I recall the peer contacts a prospective NAS and
indicates a desire to use a key from a previous EAP conversation which is
presumably cached on the AAA server.  In order for such a request to
succeed both the AAA server and EAP peer need to use the same naming
scheme.  While the peer lower layer can devise its own key name, I don't
see how the AAA server could come up with the same name unless it were
modified for each new lower layer that comes along.  This seems like a bad
idea, from a maintenance point of view.  Whereas if both the AAA server
and peer use the Session-ID as the naming mechanism, new applications can
be invented without changing the AAA cache structure.

If applications are using "multiap aaa keys" based on the EMSK
and use the Session-ID to name them, then I think this solves the problem,
assuming that the application is clear about exactly which type of AMSK it
wants retrieved.

In terms of "lower layer key sharing" I think there may be a distinction
between sharing keys on the same entity (e.g. multihomed peer shares keys
between media A and media B) and allowing multiple media to make use of
the AAA server key cache.  As an example, the "pre-emptive keying"
proposal by Bill Arbaugh allowed keying material derived from the same EAP
conversation to be sent to multiple media.  However, the keys were
cryptographically independent, so that compromise over one media would not
lead to compromise over another media.   So if each media uses a different
AMSK, I am not sure that sharing a AAA key cache should be forbidden.

>    authenticator but not on the backend server (except at

The problem here is that the original text is not sufficiently explicit.
Instead of talking about "keying material" it needs to indicate that the
restriction only refers to caching of exported EAP keying parameters
within the lower layer (not to caching of other keying material in the EAP
method layer).
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap