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

[Yoshihiro Ohba (yohba]

On Wed, Jun 07, 2006 at 11:00:43AM -0700, Narayanan, Vidya wrote:
>  
> >    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. 

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


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