Subject: [eap] [Issue 278]: lifetimes of keys internal to EAP methods

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Oct 2004 10:10:05 -0700 (PDT)

The resolution to Issue 261 involved distinguishing between
transient EAP keys used directly to protect the EAP conversation
(to be known as Transient EAP Session Keys or TESKs) and other
keying material internal to the EAP method.  So I think we need
to use the new language.

I think the issue is not necessarily the lifetime of the key material, but
session key reuse.  Note that the definition of "session" typically
relates to when a replay counter can wrap, which could encompass multiple
EAP sessions.

Here is a proposed resolution:

In Section 2.3.1, change:

"   The Transient EAP Keys (TEKs) are session keys used to protect the
    EAP conversation.  The TEKs are internal to the EAP method and are
    not exported.  They remain valid only for the duration of the EAP
    conversation, and are lost once the EAP conversation completes.

    EAP methods may also implement a cache for other local keying
    material which may persist for multiple EAP conversations.  For
    example, EAP methods based on TLS (such as EAP-TLS [RFC2716]) derive
    and cache the TLS Master Secret, typically for substantial time
    periods.  The lifetime of other local keying material calculated
    within the EAP method is defined by the method."

To:

"   The Transient EAP Session Keys (TESKs) are session keys used to
    protect the EAP conversation.  The TESKs are internal to the EAP
    method and are not exported.  EAP methods MUST ensure that TESKs used
    to protect the EAP conversation are fresh for each session, so that
    they are not reused.

    Note that this does not imply a prohibition against caching of
    cryptographic state within EAP methods, as long as caching
    does not result in TESK reuse.

    EAP methods may cache local keying material which may persist
    for multiple EAP conversations when fast reconnect is used
    [RFC 3748]. For example, EAP methods based on TLS (such as
    EAP-TLS [RFC2716]) derive and cache the TLS Master Secret,
    typically for substantial time periods.  The lifetime of
    other local keying material calculated within the EAP
    method is defined by the method. Note that in general,
    when using fast reconnect, there is no guarantee to the
    EAP server that the original long-term credentials are
    still in the possession of the peer, as a card hold holding the
    private key for EAP-TLS may have been removed, for instance.
    In any case, EAP servers should verify that the
    long-term credentials are still valid, such as by checking
    that certificate used in the original authentication has not yet
    expired."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sat, 23 Oct 2004 20:33:26 +0300

> keying material internal to the EAP method.  So I think we need

I do not see a reason to distinguish between the different
types of keys internal to a method beyond what we have already
done, such as making a difference between the long-term
credential and TEKs. If either endpoint of the EAP conversation
is compromised, a method with a fast reconnect support will
be compromised, no matter how many levels of key derivation
are used between the "semi-long term key" and the TEKs.

> relates to when a replay counter can wrap, which could encompass multiple

Is this reflected somewhere in your proposed text? Perhaps
we could avoid making a new requirement on the separation
of TEKs and fast reconnect keys, but instead have a requirement
that fast reconnect and other usage of TEKs should have
means for avoiding replay counter wraparound.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 24 Oct 2004 11:43:12 +0300

Here's my second attempt for the text to resolve
this issue. I'm taking into account Yoshi's concern
as well as Bernard's replay protection issue:

Change the current text in 2.3.1 to

    The Transient EAP Keys (TEKs) are session keys used to
    protect the EAP conversation. The TEKs are internal
    to the EAP method and are not exported. The lifetimes
    of these internal keys are defined by the method.
    They are typically created in the EAP conversation,
    used until the end of the conversation, and then
    discarded. Methods are, however, allowed to replace
    these keys to new ones even during a conversation.

    EAP methods may also implement a cache of some of the internal
    keying material which may persist for multiple EAP conversations
    when fast reconnect is used [RFC 3748]. For example, EAP methods
    based on TLS (such as EAP-TLS [RFC2716]) derive and cache
    the TLS Master Secret, typically for substantial time
    periods. Note that in general, when using fast reconnect, there
    is no guarantee to the EAP server that the original long-term
    credentials are still in the possession of the peer, as a card
    hold holding the private key for EAP-TLS may have been removed,
    for instance. In any case, EAP servers should attempt to verify
    that the long-term credentials would still be valid at this time,
    by ensuring that the original certificate lifetime has not yet
    expired, for instance.

    When using internal keys within an EAP conversation or across
    a number of conversations, it is necessary to ensure that
    replay protection and key separation requirements are fulfilled.
    For instance, if a replay counter is used, a mechanism must
    be in place to prevent it from wrapping around. Similarly,
    TSKs must remain cryptographically separate from TEKs even
    despite TEK rekeying or caching.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Oct 2004 07:14:24 -0400

Hi Jari,

Thank you for revising the text.  I agree on the text.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 Oct 2004 08:10:12 -0700 (PDT)

"For instance, if a replay counter is used, a mechanism must
be in place to prevent it from wrapping around."

The replay counter will wrap when it needs to wrap, this cannot be
prevented.  I think what you mean to say is that the TEKs need to be
refreshed before the counter wraps.

With repect to cryptographic separation of TEKs and TSKs, I think the
requirement is that the TSKs not be derivable from the TEKs as well as
vice versa. This implies that they are not on the same branch of the key
hierarchy.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Oct 2004 18:49:31 +0300

> refreshed before the counter wraps.

Right :-)

> vice versa. This implies that they are not on the same branch of the key

Yes. Although Pasi's last e-mail seemed to say something
else -- I think he wanted to require only the latter
condition, i.e.,  that TEKs not be derivable from TSKs.
Opinions on that?

(In all current methods that I know of, both conditions
are true. But we shouldn't specify what current methods
do, we should specify what is necessary.)

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 Oct 2004 09:47:04 -0700 (PDT)

> > refreshed before the counter wraps.

How about this?

The Transient EAP Keys (TEKs) are session keys used to
protect the EAP conversation.  The TEKs are internal to the EAP
method and are not exported.  TEKs are typically created
during an EAP conversation, used until the end of the
conversation and then discarded.  However, methods may
rekey TEKs during a conversation.

When using TEKs within an EAP conversation or across conversations,
it is necessary to ensure that replay protection and key separation
requirements are fulfilled.  For instance, if a replay counter is used,
TEK rekey MUST occur prior to wrapping of the counter.
Similarly, TSKs MUST remain cryptographically separate from TEKs
despite TEK rekeying or caching.  This prevents TEK compromise from
leading directly to compromise of the TSKs and vice versa.

EAP methods may cache local keying material which may persist
for multiple EAP conversations when fast reconnect is used
[RFC 3748]. For example, EAP methods based on TLS (such as
EAP-TLS [RFC2716]) derive and cache the TLS Master Secret,
typically for substantial time periods.  The lifetime of
other local keying material calculated within the EAP
method is defined by the method. Note that in general,
when using fast reconnect, there is no guarantee to
that the original long-term credentials are
still in the possession of the peer.  For instance, a
card hold holding the private key for EAP-TLS may have
been removed.  EAP servers should verify that the
long-term credentials are still valid, such as by checking
that certificate used in the original authentication has not yet
expired."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 25 Oct 2004 16:42:54 -0700

I agree with Pasi. 

I think we are getting too far down into how a method is implemented and the
actual requirements are being obscured.

We want methods to have replay protection and we want it to be
computationally infeasible to calculate the keys secret to the EAP method
from keys exported from the EAP method.  This behavior should be maintained
even if cached keying material is used and cached material should be checked
for validity.  I think most of the rest of the section is extraneous. 

Joe

[email-masked] wrote:
>> Bernard Aboba wrote:
>>> "For instance, if a replay counter is used, a mechanism must be in
>>> place to prevent it from wrapping around."
>>> 
> protect the EAP conversation.  The TEKs are internal to the
> EAP method and are not exported.  TEKs are typically created
> conversation and then discarded.  However, methods may rekey TEKs
> during a conversation. 
> 
> When using TEKs within an EAP conversation or across
> conversations, it is necessary to ensure that replay
> protection and key separation requirements are fulfilled.
> For instance, if a replay counter is used, TEK rekey MUST
> occur prior to wrapping of the counter.
> Similarly, TSKs MUST remain cryptographically separate from
> TEKs despite TEK rekeying or caching.  This prevents TEK
> compromise from leading directly to compromise of the TSKs and vice
> versa. 
> 
> other local keying material calculated within the EAP method
> is defined by the method. Note that in general, when using
> fast reconnect, there is no guarantee to that the original
> long-term credentials are still in the possession of the
> peer.  For instance, a card hold holding the private key for
> EAP-TLS may have been removed.  EAP servers should verify
> that the long-term credentials are still valid, such as by
> checking that certificate used in the original authentication has not
> yet expired." _______________________________________________
> eap mailing list
> [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 12:43:42 +0300

I'm fine with this with the exception of the bidirectional
separation requirement between the TEKs and TSKs. I think
Pasi's arguments make sense, and the requirement should only
be about not being able to compute TEKs if you are given
either the MSK or the TSKs. But maybe we should open
another issue # for this part, as it seems different from
the original lifetime issue. So my proposal is that we
close #278 now with your text below and then I'll post
another issue which has to do with the cryptographic
independence of TEKs from MSKs and TSKs.

--Jari