eap Mailing List: RE: Issue 176: Sync on key framework reqts

[Pasi.Eronen (Pasi.Eronen]

Hi,

I have a couple of comments to your proposed text:

> Add to Section 7.2.1:
> 
> Session independence
> The demonstration that passive attacks (such as capture of the
> EAP conversation) or active attacks (including compromise of the
> MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent
> or prior MSKs, EMSKs, TSKs or TEKs.

Currently 2284bis doesn't specify what a TEK is, and I fear
that specifying it would unnecessarily rule out perfectly ok
key agreement protocols. But if we haven't defined what a TEK 
is, we probably shouldn't have requirements about it!

So, I propose that we remove the TEKs from the paragraph above
(and all other references to them); IMHO they're an internal
protocol detail, and not all protocols will have similar internal 
structure--if they did, we wouldn't need this Extensibility thing 
in the first place :-)

<snip>

> The MSK and EMSK MUST NOT be used directly to protect data;
> however, they are of sufficient size to enable derivation
> of a AAA-Key subsequently used to derive Transient Session
> Keys (TSKs) for use with the selected ciphersuite.
> Each ciphersuite is responsible for specifying how to
> derive the TSKs from the AAA-Key.

BTW, currently the text doesn't say who exactly is 
responsible for specifying how to derive the AAA-Key from 
the MSK. This should probably be clarified.

> In order to ensure freshness of Transient Session Keys
> (TSKs) even in cases where one party may not have a high
> quality random number generator, EAP methods generating
> keys MUST support a two-nonce exchange in the derivation
> of the MSK and EMSK, using nonces of at least 128-bits.

I think this is an unnecessary implementation detail; there
are other perfectly valid ways to ensure that your keys are
fresh. Besides, some algorithms simply can't be made to work
without both parties having good RNGs (e.g. EAP-TLS/PEAP 
when used with DHE_DSS ciphersuites).

We might leave it there with a "SHOULD" or "RECOMMENDED"
text, though. In addition, the text probably should refer to 
freshness of MSK/EMSK, since e.g. in 802.11i the TSKs are 
always fresh even when the MSK isn't. Proposed replacement:

  "EAP methods SHOULD ensure the freshness of MSK and EMSK
  even in cases where one party may not have a high quality 
  random number generator. A RECOMMENDED method is to include
  a two-nonce exchange in the derivation of the MSK and EMSK,
  using nonces of at least 128 bits."

<snip>

> The strength of Transient Session Keys (TSKs) and
> Transient EAP Keys (TEKs) used to protect data is
> ultimately dependent on the strength of keys generated
> by the EAP method. If an EAP method does not produce keying
> material of sufficient strength, then the TSKs and TEKs
> may be subject to brute force attack. EAP methods
> supporting key derivation MUST be capable of generating
> an MSK and EMSK, each with an effective key strength
> of at least 128 bits.

Appropriate key strength is IMHO a deployment issue, not 
something that needs to be fixed here. I think it's enough
to require methods to disclose their effective key strength
(as is already required), and let the administrators
decide what is an acceptable length for their environment.

For instance, to fullfill the above requirement, EAP-TLS
and PEAP would have to prohibit the use of 1024-bit RSA 
keys--something quite common today, and definitely 
"secure enough" for this purpose.

Proposed replacement: delete the whole paragraph (we already
have a requirement to disclose key strength elsewhere).

<snip>

> The development and validation of key derivation algorithms is
> difficult, and as a result EAP methods SHOULD reuse existing key
> derivation algorithms (such as those specified in IKE [RFC2409], or
> TLS [RFC2246]), rather than inventing new ones.  EAP methods
> requesting publication as an RFC MUST provide citations to
> literature justifying the security of the chosen algorithms.  EAP
> methods SHOULD also utilize well established and analyzed mechanisms
> for MSK, EMSK, TSK and TEK derivation."

While I can't disagree about the recommendation to reuse existing
work as much as possible, why are we adding a new "MUST" level 
requirement here? What exactly is the existing literature required
to justify? 

For instance, just pointing out that e.g. some particular PRF
or encryption algorithm is OK doesn't guarantee that a protocol 
composed from them is OK. Similarly, just pointing out that 
TLS itself is OK doesn't guarantee that an EAP method using 
TLS is ok (like we saw with the MitM attack against PEAP 
and EAP-TTLS).

I'm also a bit worried that we might be placing unnecessary burden 
on authors of EAP methods. IMHO it's better to see the methods
published at IETF than not published all (and the process of 
getting something published at IETF is slow enough as it is).

Best regards,
Pasi