issue 361: child key expiry

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

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

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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

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

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


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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




____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

>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