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

[Jari Arkko (jari.arkko]

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.