Subject: [eap] Re: issue 361: child key expiry

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 06:10:55 -0700

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.

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.

----------------------------------------------------------------------------
Issue 361: Child key expiry
Submitter name: Vidya Narayanan
Submitter email address: [email-masked]
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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 02 May 2006 08:24:52 -0700

At 06:10 AM 5/2/2006, Bernard Aboba wrote:
>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

>expires,  all keying material derived from the exported keying 
>material expires, including

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 09:20:51 -0700

>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 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?

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

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

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 02 May 2006 10:52:26 -0700

At 09:20 AM 5/2/2006, Bernard Aboba wrote:
>>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:
>>
>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.

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

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'd also like to make sure that issues 1-3 are addressed adequately 
>in the text.

Agreed!  Thanks Bernard.

regards,
Lakshminath

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 May 2006 12:19:19 -0700

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

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

>That sounds right and the clarification will be good.

Suggestions welcome.

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