Subject: [eap] Proposed Resolution to Issue 254: Key Lifetime Issues

From: Bernard Aboba <[email-masked]>
Date: Sun, 14 Nov 2004 17:31:53 -0800 (PST)

The EAP Issues web page is available at:
http://www.drizzle.com/~aboba/EAP/eapissues.html

The proposed resolution of Issue 254: Key Lifetime Issues is as
follows:

Change Section 2.3 to the following:

"2.3.  Key Lifetimes

   Key lifetime issues are discussed in the sections that follow.
   Issues include:

[a]  Key lifetime negotiation.  Where key lifetimes cannot be assumed,
     it may be necessary to negotiate them.  Where negotiation is
     supported, it is RECOMMENDED that the negotiation be secured.  Note
     that key lifetime negotiation may not always be required.  A
     difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
     were negotiated. In IKEv2, each end of the SA is responsible for
     enforcing its own lifetime policy on the SA and rekeying the SA
     when necessary.

[b]  Key resynchronization.  It is possible for the peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all of the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the key cache will remain synchronized, and the peer
     may not be able to determine before attempting to use it whether a
     particular key exists within the authenticator cache.  It is
     therefore RECOMMENDED for the lower layer to provide a mechanism
     for key state resynchronization.  Since in this situation one or
     more of the parties initially do not possess a key with which to
     protect the resynchronization exchange, securing this mechanism may
     be difficult.

2.3.1.  Parent-child relationships

   When keying material exported by EAP methods expires,  all keying
   material derived from the exported keying material, (including the
   AAA-Key, AMSKs and TSKs) also expires.

   Similarly, when an EAP reauthentication takes place, new keying
   material is derived and exported by the EAP method, which eventually
   results in replacement of calculated keys, including the AAA-Key,
   AMSKs, and TSKs.

   As a result, the lifetime of keys calculated from the exported keying
   material can be no longer than the lifetime of the exported keying
   material itself.  However, the lifetime of calculated keys can be
   less than that of the exported keys.  For example, TSK rekey may
   occur prior to EAP reauthentication.

   Note that deletion of the AAA-Key does not necessarily imply deletion
   of the corresponding TSKs.  Replacement or deletion of TSKs only
   implies replacement of the AAA-Key when the TSKs are taken from a
   portion of the AAA-Key.

   Failure to mutually prove possession of the AAA-Key during the Secure
   Association Protocol exchange need not be grounds for deletion of the
   AAA-Key by both parties; rate-limiting Secure Association Protocol
   exchanges could be used to prevent a brute force attack.

2.3.2.  Local Key Lifetimes

   The Transient EAP Keys (TEKs) are session keys used to protect the
   EAP conversation.  The TEKs are internal to the EAP method and are
   not exported.  TEKs are typically created during an EAP conversation,
   used until the end of the conversation and then discarded.  However,
   methods may rekey TEKs during a conversation.

   When using TEKs within an EAP conversation or across conversations,
   it is necessary to ensure that replay protection and key separation
   requirements are fulfilled.  For instance, if a replay counter is
   used, TEK rekey MUST occur prior to wrapping of the counter.
   Similarly, TSKs MUST remain cryptographically separate from TEKs
   despite TEK rekeying or caching. This prevents TEK compromise from
   leading directly to compromise of the TSKs and vice versa.

   EAP methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and cache the TLS Master Secret, typically for substantial
   time periods.  The lifetime of other local keying material calculated
   within the EAP method is defined by the method.  Note that in
   general, when using fast reconnect, there is no guarantee to that the
   original long-term credentials are still in the possession of the
   peer.  For instance, a card hold holding the private key for EAP-TLS
   may have been removed. EAP servers should verify that the long-term
   credentials are still valid, such as by checking that certificate
   used in the original authentication has not yet expired.

2.3.3.  Exported and Calculated Key Lifetimes

   All EAP methods generating keys are required to generate the MSK and
   EMSK, and may optionally generate the IV.  Existing EAP methods do
   not negotiate the lifetime of the exported keys.  EAP, defined in
   [RFC3748], also does not support the negotiation of lifetimes for
   exported keying material such as the MSK, EMSK and IV.

   Several mechanisms exist for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865] and
     Diameter [DiamEAP] support the Session-Timeout attribute.  The
     Session-Timeout value represents the maximum lifetime of the
     exported keys, and all keys calculated from it, in all
     circumstances.  The AAA server MUST expire the exported keys, and
     all keys calculated from them, prior to the future time indicated
     by Session-Timeout.  On the authenticator,  where EAP is used for
     authentication, the Session-Timeout value represents the maximum
     session time prior to re-authentication, as described in [RFC3580].
     Where EAP is used for pre-authentication, the session may not start
     until some future time, or may never occur.  Nevertheless, the
     Session-Timeout value represents the time after which the AAA-Key,
     and all keys calculated from it, will have expired on the
     authenticator.  If the session subsequently starts, re-
     authentication will be initiated once the Session-Time has expired.
     If the session never started, or started and ended, the AAA-Key and
     all keys calculated from it will be expired by the authenticator
     prior to the future time indicated by Session-Timeout.

     Since the TSK lifetime is often determined by authenticator
     resources, the AAA server has no insight into the TSK derivation
     process, and by the principle of ciphersuite independence, it is
     not appropriate for the AAA server to manage any aspect of the TSK
     derivation process, including the TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can communicate the
     maximum exported key lifetime, this only serves to synchronize the
     key lifetime between the backend authentication server and the
     authenticator.  Lower layer mechanisms can then be used to enable
     the lifetime of exported and calculated keys to be negotiated
     between the peer and authenticator.

     Where TSKs are established as the result of a Secure Association
     Protocol exchange, it is RECOMMENDED that the Secure Association
     Protocol include secure negotiation of the TSK lifetime between the
     peer and authenticator.  Where the TSK is taken from the AAA-Key,
     there is no need to manage the TSK lifetime as a separate
     parameter, since the TSK lifetime and AAA-Key lifetime are
     identical.

[c]  System defaults.  Where the EAP method does not support the
     negotiation of the exported key lifetime, and a negotiation
     mechanism is not provided by the lower lower, there may be no way
     for the peer to learn knowledge of the exported key liftime.  In
     this case it is RECOMMENDED that the peer assume a default value of
     the exported key lifetime; 8 hours is suggested.  Similarly, the
     lifetime of calculated keys can also be managed as a system
     parameter on the authenticator.

2.3.4.  Key cache synchronization

   Issues arise when attempting to synchronize the key cache on the peer
   and authenticator.  Lifetime negotiation alone cannot guarantee key
   cache synchronization.

   One problem is that the AAA protocol cannot guarantee synchronization
   of key lifetimes between the peer and authenticator.  Where the
   Secure Association Protocol is not run immediately after EAP
   authentication, the exported and calculated key lifetimes will not be
   known by the peer during the hiatus.  Where EAP pre-authentication
   occurs, this can leave the peer uncertain whether a subsequent
   attempt to use the exported keys will prove successful.

   However, even where the Secure Association Protocol is run
   immediately after EAP, it is still possible for the authenticator to
   reclaim resources if the created key state is not immediately
   utilized.

   The lower layer may utilize Discovery mechanisms to assist in this.
   For example, the authenticator manages the AAA-Key cache by deleting
   the oldest AAA-Key first (LIFO), the relative creation time of the
   last AAA-Key to be deleted could be advertised with the Discovery
   phase, enabling the peer to determine whether a given AAA-Key had
   been expired from the authenticator key cache prematurely."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Nov 2004 11:01:01 +0200

Hi Bernard,

>      enforcing its own lifetime policy on the SA and rekeying the SA

The reader may wonder why we suddenly talk about
IKE. Suggest s/A difference/To take an example from IKE,
the difference/

>    implies replacement of the AAA-Key when the TSKs are taken from a

I do not understand this paragraph. The first part appears to claim
that TSKs can break the death-of-the-parent rule. The second part
appears to claim that AAA-Key gets changed because it is used twice.
Or maybe the latter is something that we do want to mandate, but
the text still reads funny, it sounds like the requirement only
exists if we take a part of AAA-Key, not all of it. Or did you
want to say that when TSKs are bit-by-bit copies of the AAA-Keys
parts, then we throw that part away?

>      all keys calculated from them, prior to the future time indicated

Is it really "prior to"? Not "latest at"?

>      peer and authenticator.  Where the TSK is taken from the AAA-Key,

Why do we recommend this? What if the lower layer uses the IKEv2
principle?

>    been expired from the authenticator key cache prematurely."

--Jari