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

[Bernard Aboba (aboba]

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