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

[Joseph Salowey (jsalowey]

I agree with Pasi. 

I think we are getting too far down into how a method is implemented and the
actual requirements are being obscured.

We want methods to have replay protection and we want it to be
computationally infeasible to calculate the keys secret to the EAP method
from keys exported from the EAP method.  This behavior should be maintained
even if cached keying material is used and cached material should be checked
for validity.  I think most of the rest of the section is extraneous. 

Joe

  

eap-admin [at] frascone.com wrote:
>> Bernard Aboba wrote:
>>> "For instance, if a replay counter is used, a mechanism must be in
>>> place to prevent it from wrapping around."
>>> 
>>> The replay counter will wrap when it needs to wrap, this cannot be
>>> prevented.  I think what you mean to say is that the TEKs need to be
>>> refreshed before the counter wraps.
>> 
>> Right :-)
> 
> How about this?
> 
> 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.  TEKs are typically created
> during an EAP conversation, used until the end of the
> conversation and then discarded.  However, methods may rekey TEKs
> during a conversation. 
> 
> When using TEKs within an EAP conversation or across
> conversations, it is necessary to ensure that replay
> protection and key separation requirements are fulfilled.
> For instance, if a replay counter is used, TEK rekey MUST
> occur prior to wrapping of the counter.
> Similarly, TSKs MUST remain cryptographically separate from
> TEKs despite TEK rekeying or caching.  This prevents TEK
> compromise from leading directly to compromise of the TSKs and vice
> versa. 
> 
> EAP methods may cache 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 that the original
> long-term credentials are still in the possession of the
> peer.  For instance, a card hold holding the private key for
> EAP-TLS may have been removed.  EAP servers should verify
> that the long-term credentials are still valid, such as by
> checking that certificate used in the original authentication has not
> yet expired." _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap