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

[Narayanan, Vidya (vidyan]

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


In the above, are you talking about an EMSK compromise after expiry
affecting any keys that may still be in use? If so, I'm wondering how
viable that is - basically, the point that I'm not clear on is this - if
the EMSK is used to derive any keys that are handed out to other
entities, depending on the purpose of the key, the EAP server may really
have no control over that lifetime. 

But, if this is a concern, I'm okay with providing guidance for key
expiry in this manner. 

Vidya


> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Monday, June 05, 2006 5:12 AM
> To: eap [at] frascone.com
> Subject: Re: [eap] Proposed Resolution of Issue 361: Child Key Expiry
> 
> 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.
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>