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

[Lakshminath Dondeti (ldondeti]

At 06:10 AM 5/2/2006, Bernard Aboba wrote:
> One of the unstated threat model assumptions is that any key can be 
> compromised over a sufficient period of time.  This includes the 
> exported keys (MSK, EMSK).  So the question is: if the MSK or EMSK 
> are considered "stale" should the TSKs also be considered stale?
>
> In a previous comment, it was noted that TSK derivation techniques 
> differ, so that a TSK could be compromised even if the MSK/EMSK was 
> not.  Similarly, in protocols such as IKEv2, it might be possible to 
> derive a TSK that would not be compromised even if the EMSK/MSK was 
> compromised.  For example, consider a 4096-bit DH used for IKEv2 TSK 
> generation while the EAP method uses a 512-bit DH.  Since EAP keys 
> are used in IKEv2 only for authentication, as long as IKEv2 does not 
> reuse the MSK after it becomes stale (which it doesn't, because 
> IKEv2 does not support caching), the TSK is not compromised.

We hope no one is using a 512-bit DH in an EAP method, considering 
that EAP key derivation requirements (lengthwise, i.e., 64 octets of 
MSK, 64 octets of EMSK etc.) are as demanding as IKEv2's are.  But, 
sure, the concern is valid.  Some EAP methods use the PSK directly 
for key derivation whereas IKEv2 doesn't.

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).

> Given this, I think the problem is with the words "including the 
> TSKs."  If the TSKs are not derived from the MSK/EMSK, then I don't 
> think they should be considered stale once the MSK/EMSK is considered stale.
>
> However, if a key is derived from the MSK/EMSK, then if the MSK/EMSK 
> is compromised, then presumably the derived key is compromised as 
> well, even if it is derived via PRF, mixing with nonces, etc.  If 
> the attacker has obtained the MSK/EMSK, then it can also obtain the 
> derived keys.

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.

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).

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.

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.

I think Vidya was referring to #4 with her last statement (not mind 
reading; that came up in our previous discussions on the topic :-) ).

regards,
Lakshminath




> ----------------------------------------------------------------------------
> Issue 361: Child key expiry
> Submitter name: Vidya Narayanan
> Submitter email address: vidyan [at] qualcomm.com
> Date Submitted: May 1, 2006
> Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
> Document: KEYING-12
> Comment type: 'T'echnical
> Priority: '2' May fix
> Section: 3.3
> Rationale/Explanation of issue:
>
> This section states "When keying material exported by EAP methods
> expires,  all keying material derived from the exported keying 
> material expires, including
> the TSKs." This seems to indicate that the keys derived from the EMSK
> will also be expired when the EMSK expires. It is not yet clear if this
> would apply to all kinds of keys derived from the EMSK. There may be
> classes of keys derived from the EMSK for which different lifetime
> guidelines apply. So, it may be good to clarify that the EMSK usage
> documents will specify the guidelines for EMSK-based child keys.
>
> Requested change:
>
> Change
>
> "When keying material exported by EAP methods expires,  all keying
> material derived from the exported keying material expires, including
> the TSKs."
>
> to
>
> "When keying material exported by EAP methods expires,  all keying
> material derived from the exported keying material expires, including
> the TSKs. Note that different lifetime guidelines may be specified in
> future specifications for EMSK-based child keys."
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap