Proposed Resolution of Issue 361: Child Key Expiry

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

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

Proposed Resolution of Issue 361: Child Key Expiry

Thread: Proposed Resolution of Issue 361: Child Key Expiry