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

[henry.haverinen (henry.haverinen]

Jari,

I think your proposal looks very good. There is need to
have a general notion of the trade-off between speed and 
security which is typical to fast reconnect schemes. 
I also think the keying document should highlight the goal 
(replay protection and key separation) rather than a certain 
implementation.

Best regards,
Henry

> -----Original Message-----
> From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com]On Behalf Of
> ext Jari Arkko
> Sent: 24 October, 2004 11:43
> To: Bernard Aboba; Yoshihiro Ohba
> Cc: eap [at] frascone.com
> Subject: Re: [eap] [Issue 278]: lifetimes of keys internal to EAP
> methods
> 
> 
> 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
>