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

From: <[email-masked]>
Date: Mon, 25 Oct 2004 11:37:54 +0300

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: [email-masked]
> 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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 12:40:05 +0300

> say that "it must not be possible to calculate TEKs from TSKs".

This seems to be the main requirement, yes. And doesn't it
hold for MSK too? That is,

   Must not be possible to calculate TEKs from MSK
   Must not be possible to calculate MSK from TSKs

(But 802.11i might not qualify for the latter? If so,
I'm ready to make this:

   Must not be possible to calculate TEKs from MSK
   Must not be possible to calculate TEKs from TSKs)

> TEK (and all information sent over the wire) allows you to calculate the MSK. 

Yes, I don't think there's anything fundamentally wrong with this.

> And knowing the MSK allows you to calculate 

Now I'm missing something. Perhaps you meant to say that knowing
the MSK allows you to calculate the TSKs in 802.11i? No fault
in the lower layer can let you calculate TEKs, assuming your requirement
in the first paragraph above holds.

> outside the EAP method." (and also changing Section 6.4

This is good enough for me.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 12:59:30 +0300

Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: 10/25/2004
Reference: http://mail.frascone.com/pipermail/eap/2004-October/002971.html
Document: Keying Framework
Comment type: T
Priority: 1
Section: 2.3.1 and
Rationale/Explanation of issue:

Pasi argues that it is only necessary to prevent computation
of TEKs from TSKs and not the other way around. Jari argues
that it is also useful to prevent computation of TEKs from
MSK and EMSK. Preventing computation of MSKs from TSKs was
also mentioned, but that may not fit what current link layers
do (?).

Suggested correction: In 2.3.1, change

   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.

=>

   Similarly, Similarly, it must not be possible to calculate
   TEKs from keys exported outside the EAP method. This prevents
   TSK compromise from leading directly to compromise of the TEKs.

In Section 6.4, change

   In addition, the TSKs MUST be cryptographically separate from
   the TEKs.

=>

   In addition, it MUST NOT be possible to calculate TEKs from
   MSK and EMSK. (From this it also follows that it is not possible
   to calculate TEKs from TSKs or AMSKs.)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap