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

[Bernard Aboba (aboba]

> Bernard Aboba wrote:
> > "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.
>
> Right :-)

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