Re: [Issue 278]: lifetimes of keys internal to EAP methods
From: Bernard Aboba (abobainternaut.com)
Date: Mon, 25 Oct 2004 11:10:38 -0400 (EDT)
"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.

On Sun, 24 Oct 2004, Jari Arkko wrote:

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

Results generated by Tiger Technologies using MHonArc.