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

[Bernard Aboba (bernard_aboba]

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

"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 depending on 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 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.

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