eap Mailing List: Re: [Issue 278]: lifetimes of keys internal to EAP methods

[Jari Arkko (jari.arkko]

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

Bernard Aboba wrote:

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