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

[Lakshminath Dondeti (ldondeti]

At 09:20 AM 5/2/2006, Bernard Aboba wrote:
> > I am not sure we can safely say that no IKEv2 implementation will 
> > cache the EAP MSK as the PSK.  After all, the PSK is only used for 
> > entity authentication and not for key distribution, and therefore, 
> > can be used for a decent amount of time without any issues.  Recall 
> > also that an alternative might be password based PSKs which may not 
> > always be as strong as those coming from an EAP method (assuming 
> > one of the newer methods).
>
> In this particular case, we are talking about caching of EAP keying 
> material within the IKEv2 lower layer.  Caching of EAP keying 
> material within the PANA lower layer is a separate issue.   How 
> should we clarify that?

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.


> > I think there are several notes here, I think you captured most, 
> > but here is a list:
> >
> > Compromise:
> >
> > 1. If an MSK/EMSK is compromised, all derived keys are assumed to 
> > have been compromised, as long as any nonces exchanged are in the 
> > clear or protected with the MSK/EMSK, or keys derived thereof.
>
> Yup.
>
> > 2. MSK/EMSK compromise does not necessarily impact child key 
> > derivation iff the MSK/EMSK (or keys derived thereof) only serve as 
> > entity authentication keys and are not used for key 
> > derivation.  (Perhaps the latter -- and are not used for key 
> > derivation -- is too restrictive).
>
> 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.

If that's confusing too, please let me know.


> > Lifetime:
> >
> > Lifetime, as far as I understand, is set due to two 
> > considerations.  Let's consider confidentiality.  As soon as a 
> > block of ciphertext is transmitted, we can assume that an adversary 
> > has started a brute-force attack to guess the key.  With the most 
> > powerful adversary's capabilities that we want to protect against 
> > in mind, we make an estimate of how long it might take for the 
> > computation to complete and can set a lifetime.  The other 
> > consideration is that the amount of traffic encrypted with a given 
> > key may provide hints to reduce the computation needed by the 
> > brute-force attack.
> > With those considerations in mind,
> >
> > 3. Keys that are used frequently, for instance, for traffic 
> > protection expire sooner.  We might say those MUST NOT used beyond 
> > the EMSK's lifetime.  They may expire sooner than the EMSK, however.
>
> 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.


> > 4. Keys used less frequently, say, for entity authentication need 
> > not expire with the EMSK.  We might allow, for instance, local 
> > policy to set the lifetime on such keys.  That lifetime MAY be 
> > beyond EMSK's lifetime.
>
> 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?


> > I think Vidya was referring to #4 with her last statement (not mind 
> > reading; that came up in our previous discussions on the topic :-)
>
> I'd also like to make sure that issues 1-3 are addressed adequately 
> in the text.

Agreed!  Thanks Bernard.

regards,
Lakshminath