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

[Pasi.Eronen (Pasi.Eronen]

Hi,

I think the proposed text looks very good (it's much more clearer 
what is just description of how "typical" EAP methods operate, 
and what is absolutely required).

However, I'm not so sure about the ast lsentence ("TSKs must 
remain cryptographically separate from TEKs"). This requirement 
is also repeated in Section 6.4, but I think it should actually 
say that "it must not be possible to calculate TEKs from TSKs".

The current text essentially prohibit EAP methods that use key
wrapping (e.g., server generates a random key, encrypts it with
a TEK, and sends it to the client). In this case, knowing the 
TEK (and all information sent over the wire) allows you to 
calculate the MSK. And knowing the MSK allows you to calculate 
the TEKs in e.g. 802.11i), so they're not cryptographically
separate (at least according to definition in Section 5.1).

So, I'd propose replacing the last sentence with "Similarly, 
it must not be possible to calculate TEKs from keys exported 
outside the EAP method." (and also changing Section 6.4
accordingly).

Best regards,
Pasi

> -----Original Message-----
> From: Jari Arkko
> Sent: Sunday, October 24, 2004 11:43 AM
> 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.
>