eap Mailing List: RE: Re: issue 361: child key expiry

[Narayanan, Vidya (vidyan]

Bernard, Lakshminath,
While this is an interesting discussion, I feel that the EMSK specifics
with respect to caching and lifetime as well as child key properties
need to be discussed in the EMSK usage document. We can continue having
this discussion in light of the EMSK usage document. 

For the purpose of EAP keying document, can we not add that sentence
about a future EMSK usage document and leave it at that? 

However, if there are things that need to be clarified here with respect
to the MSK, we should certainly do that in this document. 

Thanks,
Vidya 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Tuesday, May 02, 2006 12:19 PM
> To: Dondeti, Lakshminath; eap [at] frascone.com
> Subject: Re: [eap] Re: issue 361: child key expiry
> 
> >I wasn't thinking about PANA, but thinking about the use 
> case of client 
> >authentication in IPsec remote access using EAP.  Whereas EAP can be 
> >used every time, it is plausible that the MSK is cached as the IKEv2 
> >Preshared key for future authentication to avoid EAP latency.
> 
> Perhaps we can say that RFC 4306 does not support key 
> caching?  It seems that an extension to IKEv2 would be 
> required to support this, since otherwise the IKE initiator 
> and responder couldn't negotiate whether cached EAP keys are 
> to be used, and if so, which ones.
> 
> >>Are you suggesting that there might be situations in which EAP keys 
> >>aren't used for key derivation, but compromise might still 
> be possible?
> >
> >No.  I am asking if the MSK/EMSK figures into the key 
> derivation, say 
> >only partially (say along with DH), compromise of MSK/EMSK means 
> >compromise of derived keys.  I was then saying perhaps that is too 
> >restrictive, but I'd contend not, unless there is a strong 
> case made for the alternative.
> 
> OK.  If the MSK/EMSK were mixed into the key derivation, then 
> there might be some weakening of the key derivation.  How 
> much depends on the algorithm.
> 
> >If that's confusing too, please let me know.
> 
> I understand the point.... question is how we make it clear 
> in the text.
> 
> >>Right.  And by the same logic, the MSK and EMSK might expire at 
> >>different times.  I'm not sure that the key lifetime section takes 
> >>that into account adequately.
> >
> >That sounds right and the clarification will be good.
> 
> Suggestions welcome.
> 
> >>This makes sense assuming that the entity authentiation keys aren't 
> >>themselves derived from the EMSK.
> >
> >Even if entity authentication keys are derived from the EMSK, the 
> >guideline applies, I think.  Suppose the EMSK supports 
> derivation of a 
> >traffic key and a separate entity authentication key, 
> wouldn't it make 
> >sense to say that, all other things being equal, the traffic 
> key will 
> >have a shorter lifetime than the entity authentication key, 
> based on key usage?
> 
> Yes, it would make sense.   I guess I'd distinguish between a 
> key calculated 
> from the EMSK (e.g. AMSK) and a TSK.  The AMSK formulas that 
> have been suggested so far are static -- that is, they are 
> based on a key-label, but do not generate a fresh key every 
> time they are invoked on the same EMSK, in the way that some 
> TSK derivations do (e.g. 802.11i 4-way handshake).
> 
> Unless there is an ability to generate fresh keys without an 
> EAP re-authentication, then when the derived keyexpires it is 
> necessary to do an EAP re-authentication.  With TSKs it may 
> be possible to do a re-key independent of EAP (e.g. 802.11i 
> 4-way handshake).
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>