eap Mailing List: issue: lifetimes of keys internal to EAP methods

[Jari Arkko (jari.arkko]

Description of issue
Submitter name: Jari Arkko
Submitter email address: jari.arkko [at] piuha.net
Date first submitted: Oct 22, 2004
Reference:
Document: Keying Framework
Comment type: T
Priority: 1
Section: 2.3.1
Rationale/Explanation of issue:

This came up originally in Yoshi's review of EAP-AKA. I have
been thinking about this for a while now, and I'd like to
suggest that the requirements in Section 2.3.1 of keying-03
are partially unnecessary and partially insufficient.

Section 2.3.1 says that TEKs are lost after the EAP
conversation completes. Then it goes on to say that
other keying information may be cached (such as the
TLS master secret in EAP TLS). I have several problems
with this:

(1) It seems that this capability, retaining a key for
fast reauthentication, fundamentally implies a couple
of things. First of all, a key needs to be kept and reused
on the next run. Secondly, some parts of the "full
authentication" are not being done. This may have security
implications -- such as not going to the smart card to
fetch the long-term key, not having the user type in a PIN,
not doing a full certifiate revocation check, etc. I think
this would have to be pointed out somewhere. I think fast
reauthentication is a reasonable security/speed tradeoff,
but its implications should be documented.

(2) The text does not cater for changing TEKs during an
EAP method run. I know its far-fetched given that EAP is
not the world's best protocol transporting large quantities
of information. But it shouldn't be disallowed either.

(3) I wonder what the real difference is between the TEKs
and the "other local keying material" that the current text
talks about. Seems like vulnerabilities related to storing
either one are the same; if the keys are used in some insufficiently
protected way, such as input to ROT13, they will be discovered.
If the keys are used for too long, they need to be changed.
But the latter is unlikely to happen with the amount of data
protected by EAP and algorithms such as AES.

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

=>

   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 typically 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 of some 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 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.