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

[Yoshihiro Ohba (yohba]

On Fri, Oct 22, 2004 at 04:23:07PM +0300, Jari Arkko wrote:
> 
> 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.

I agree.

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

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

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

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?

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

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.

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

Regards,

Yoshihiro Ohba