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

[Yoshihiro Ohba (yohba]

Hi Jari,

Thank you for revising the text.  I agree on the text.

Yoshihiro Ohba


On Sun, Oct 24, 2004 at 11:43:12AM +0300, Jari Arkko wrote:
> Here's my second attempt for the text to resolve
> this issue. I'm taking into account Yoshi's concern
> as well as Bernard's replay protection issue:
> 
> Change the current text in 2.3.1 to
> 
>    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. The lifetimes
>    of these internal keys are defined by the method.
>    They are typically created in the EAP conversation,
>    used until the end of the conversation, and then
>    discarded. Methods are, however, allowed to replace
>    these keys to new ones even during a conversation.
> 
>    EAP methods may also implement a cache of some of the internal
>    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. 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.
> 
>    When using internal keys within an EAP conversation or across
>    a number of conversations, it is necessary to ensure that
>    replay protection and key separation requirements are fulfilled.
>    For instance, if a replay counter is used, a mechanism must
>    be in place to prevent it from wrapping around. Similarly,
>    TSKs must remain cryptographically separate from TEKs even
>    despite TEK rekeying or caching.
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap