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

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Jun 2006 11:00:43 -0700

>    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:[email-masked]] 
> Sent: Monday, June 05, 2006 5:12 AM
> To: [email-masked]
> 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 07 Jun 2006 14:39:34 -0400

> have no control over that lifetime. 

If the EAP server has no control over the lifetime when EMSK is used
for a specific purpose, then it would be the time to think about
possibility to use a mechanism other than EAP for that purpose.

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Jun 2006 12:50:03 -0700

>affecting any keys that may still be in use?

If the EMSK expires and the session is still in progress, presumably the 
result is an EAP re-authentication which results in new child keys.

>If so, I'm wondering how

It can provide a maximum lifetime (Session-Timeout) to the authenticator, 
requesting EAP re-authentication to occur when the maximum lifetime expires.

The distinction we're making here is between maximum lifetime (controlled by 
Session-Timeout) and deletion.  If the EMSK is deleted on the peer or 
server, this doesn't cause child keys to be deleted.  However, expiry of the 
maximum lifetime does result in new child keys.