Subject: [eap] issue: lifetimes of keys internal to EAP methods

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2004 16:23:07 +0300

Description of issue
Submitter name: Jari Arkko
Submitter email address: [email-masked]
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.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Oct 2004 21:55:04 -0400

> but its implications should be documented.

I agree.

> of information. But it shouldn't be disallowed either.

OK.  But where is "changing TEKs" mentioned in your proposed text?

> protected by EAP and algorithms such as AES.

I agree.  Also, I am not sure whether even EAP-TLS follows the TEK
definition of the EAP keying draft.  Doesn't EAP-TLS session
resumption need to use the TEK of the previous EAP conversation to
compute TLS change_cipher_spec while the TLS finished needs to be
protected with the newly derived TEK?

>    the EAP conversation, and are lost once the EAP conversation

I am wondering if EAP-TLS is really such a *typical* method in which
TEKs remain valid only for the duration of the EAP conversation.

>    ensuring that the original certificate lifetime has not yet

Regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2004 22:47:05 +0300

> OK.  But where is "changing TEKs" mentioned in your proposed text?

It wasn't directly, but I added "typically" so we still leave
some space for this to happen:

   "They typically remain valid only for the duration of
   the EAP conversation, and are lost once the EAP conversation
   completes."

Do you think it should be more explicit?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Oct 2004 23:41:25 -0400

> Do you think it should be more explicit?

I see.  If there is a typical existing EAP method that does this
"typical" thing, I think the proposed text is ok.  But it there such a
typical EAP method?  (I may be wrong)

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Sun, 24 Oct 2004 10:58:05 +0300

> typical EAP method?  (I may be wrong)

I meant that most of the time, the TEKs are created for exactly the
duration of one EAP run. However, since the text does not require
this (it just says "typically"), some methods could, for instance,
could rekey to new TEKs during the same run, or use the TEKs for
fast reconnect.

But I'll try to come up with better text.

--Jari