Subject: [eap] Proposed Resolution of Issue 361: Child Key Expiry

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Jun 2006 20:04:09 -0700

In looking at the discussion of this issue, and reviewing the text, it is 
not clear
how useful it is to have EAP methods export the Key-Lifetime parameter.  
Today no EAP
methods export this parameter, and the text in Section 1.4 suggests that 
this
is not very useful anyway:

   Key-Lifetime

      While EAP itself does not support key lifetime negotiation, it is
      possible to specify methods that do.  However, systems that rely
      on such negotiation for exported keys would only function with
      these methods.  As a result, it is NOT RECOMMENDED to use this
      approach as the sole way to determine key lifetimes.

Similarly, Section 3 states:

   Existing EAP methods do not export the Key-Lifetime
   parameter; in the interest of method independence, key management of
   exported or derived keys SHOULD NOT be provided within EAP methods.

As a result, it may make sense to remove discussion of the Key-Lifetime 
parameter
from the document.

The text of Issue 361 is enclosed below.  The proposed resolution is as 
follows:

In Section 1.4, delete:

"   Key-Lifetime

      While EAP itself does not support key lifetime negotiation, it is
      possible to specify methods that do.  However, systems that rely
      on such negotiation for exported keys would only function with
      these methods.  As a result, it is NOT RECOMMENDED to use this
      approach as the sole way to determine key lifetimes."

Also, delete the Key-Lifetime parameter from Figure 2.

In Section 3, change:

"Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods."

To:

"Existing EAP methods do not manage the lifetime of exported EAP
keying material;  in the interest of method independence, key management of
exported or derived keys SHOULD NOT be provided within EAP methods."

Change Section 3.3 to the following:

"3.3.  Parent-Child Relationships

   When an EAP re-authentication takes place, new keying material is
   derived and exported by the EAP method, which eventually
   results in replacement of TSKs, regardless of the way they
   are derived (see Section 2.1).  Thus in practice replacement of
   TSKs is implied by EAP re-authentication.

   As a result, it is not possible for TSKs or other keying material
   derived from the MSK/EMSK to have a longer lifetime than the
   exported EAP keying material.  This is true even where exported
   EAP keying material is only used for entity authentication and is
   not used for key derivation (such as in IKEv2), so that compromise
   of exported EAP keying material does not imply compromise of the TSKs
   or child keys.  However, where child keys are derived from or are
   wrapped by EAP keying material, compromise of the MSK/EMSK does
   imply compromise of the child keys.

   While the lifetime of TSKs or child keys can be less than or
   equal that of the exported keying material they are derived from, it
   cannot be greater.  Child keys that are used frequently (such as TSKs
   which are used for traffic protection) can expire sooner than the
   exported EAP keying material from which they are derived, so that it
   is advantageous to support re-key of child keying material prior to
   EAP re-authentication.

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

Change Section 3.5 to the following:

"3.5.  Exported and Calculated Key Lifetimes

   All EAP methods generating keys are required to generate the MSK and
   EMSK, and may optionally generate the IV.  However, EAP, defined in
   [RFC3748], does not itself 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 [RFC4072] support the Session-Timeout attribute.  The
     Session-Timeout attribute represents the maximum lifetime of the
     exported keying material, and all keys calculated from it, on the
     authenticator.  Since existing backend authentication servers do
     not cache keys exported by EAP methods, or keys calculated from
     exported keys, the value of the Session-Timeout attribute has no
     bearing on the key lifetime within the backend authentication
     server.

     On the authenticator,  where EAP is used for authentication the
     Session-Timeout attribute represents the maximum session time prior
     to re-authentication.  As described in [RFC3580] Section 3.17, when
     sent in an Access-Accept along with a Termination-Action value of
     RADIUS-Request, the Session-Timeout attribute specifies the maximum
     number of seconds of service provided prior to re-authentication.

     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 maximum time after which
     transported EAP keying material, 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, by default keys transported by AAA and all keys
     calculated from them will be expired by the authenticator prior to
     the future time indicated by Session-Timeout; this feature is
     utilized by [IEEE-802.11i].  Note that in future additional
     attributes may be specified to control the lifetime of cached keys;
     these attributes may modify the meaning of the Session-Timeout
     attribute in specific circumstances.

     Since the TSK lifetime is often determined by authenticator resources,
     and the backend authentication server has no insight into the
     TSK derivation process, by the principle of ciphersuite independence,
     it is not appropriate for the backend authentication 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.  It is RECOMMENDED that lower layer mechanisms
     such as the Secure Association Protocol 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 support for TSK re-key.  Where the TSK is taken
     directly from the MSK, there is no need to manage the TSK lifetime
     as a separate parameter, since the TSK lifetime and MSK lifetime
     are identical.

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

[d]  Method specific negotiation within EAP.  While EAP itself does not
     support lifetime negotiation, it would be possible to specify
     methods that do.  However, systems that rely on such negotiation
     for exported keys would only function with these methods.  As a
     result, it is NOT RECOMMENDED to use this approach as the sole way
     to determine key lifetimes."

----------------------------------------------------------------------------------------------------------------------------------
Issue 361: Child key expiry
Submitter name: Vidya Narayanan
Submitter email address: [email-masked]
Date Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '2' May fix
Section: 3.3
Rationale/Explanation of issue:

This section states "When keying material exported by EAP methods
expires,  all keying material derived from the exported keying material 
expires, including
the TSKs." This seems to indicate that the keys derived from the EMSK
will also be expired when the EMSK expires. It is not yet clear if this
would apply to all kinds of keys derived from the EMSK. There may be
classes of keys derived from the EMSK for which different lifetime
guidelines apply. So, it may be good to clarify that the EMSK usage
documents will specify the guidelines for EMSK-based child keys.

Requested change:

Change

"When keying material exported by EAP methods expires,  all keying
material derived from the exported keying material expires, including
the TSKs."

to

"When keying material exported by EAP methods expires,  all keying
material derived from the exported keying material expires, including
the TSKs. Note that different lifetime guidelines may be specified in
future specifications for EMSK-based child keys."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Jun 2006 20:14:33 -0700

To better capture the dependency issue, the following revision of Section 
3.5 is proposed:

     exported keying material, and all keys depending on it, on the

     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 maximum time after which
     transported EAP keying material, and all keys dependent on 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, by
     default keys transported by AAA and all keys dependent on them be
     expired by the authenticator prior to the future time indicated by
     Session-Timeout; this feature is utilized by [IEEE-802.11i].  Note
     that in future additional attributes may be specified to control
     the lifetime of cached keys; these attributes may modify the
     meaning of the Session-Timeout attribute in specific circumstances.

     Since the TSK lifetime is often determined by authenticator
     resources, and the backend authentication server has no insight
     into the TSK derivation process, by the principle of ciphersuite
     independence, it is not appropriate for the backend authentication
     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 such as the Secure
     Association Protocol can then be used to enable the lifetime of
     exported and calculated keys to be negotiated between the peer and
     authenticator.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Jun 2006 05:12:15 -0700

Here is an update to Section 3.3, which better captures the distinction 
between maximum lifetime and actual lifetime:

3.3.  Parent-Child Relationships

   When an EAP re-authentication takes place, new keying material is
   derived and exported by the EAP method, which eventually results in
   replacement of TSKs, regardless of the way they are derived (see
   Section 2.1).  While the maximum lifetime of TSKs or child keys can
   be less than or equal to that of the MSK/EMSK, it cannot be greater.
   This is true even where exported EAP keying material is only used for
   entity authentication and is not used for key derivation (such as in
   IKEv2), so that compromise of exported EAP keying material does not
   imply compromise of the TSKs or child keys.  However, where child
   keys are derived from or are wrapped by EAP keying material,
   compromise of the MSK/EMSK does imply compromise of the child keys.

   Child keys that are used frequently (such as TSKs which are used for
   traffic protection) can expire sooner than the exported EAP keying
   material they are dependent on, so that it is advantageous to support
   re-key of child keys prior to EAP re-authentication.  Note that
   deletion of the MSK/EMSK does not necessarily imply deletion of TSKs
   or child keys.

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