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

[Narayanan, Vidya (vidyan]

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

Agreed. 

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

Okay. 


The following text on section 3.5 looks good. 

Vidya
 
> 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."
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>