eap Mailing List: Proposed Resolution of Issue 361: Child Key Expiry

[Bernard Aboba (bernard_aboba]

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: vidyan [at] qualcomm.com
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."