Subject: RE: [eap] Issue 176: Sync on key framework reqts

From: <[email-masked]>
Date: Wed, 24 Sep 2003 14:35:18 +0300

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Sep 2003 06:53:35 -0700 (PDT)

> structure--if they did, we wouldn't need this Extensibility thing

OK.

> the MSK. This should probably be clarified.

Yes.  How about:

"The AAA-Key is derived from the keying material exported by the EAP
method (MSK and EMSK).  This derivation occurs on the AAA server.  For
details, see [KEYFRAME]."

>   using nonces of at least 128 bits."

Another concern that motivated this reqts was  EAP SA naming. For that
purpose I'm not sure that a two-nonce exchange is required, just a
quantity from each side that together are very likely to be
temporally unique.  So maybe it is:

"EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases
where one party may not have a high quality random number generator. A
RECOMMENDED method is for each party to provide a nonce of at
least 128 bits, used in the derivation of the MSK and EMSK.  The
combination of the peer and server nonce uniquely identifies the
exchange."

> decide what is an acceptable length for their environment.

I think this requirement is about being capable of generating a strong key
if it is desired.  If it is desired to deploy using a strong key, then the
method needs to support that mode of operation.  So perhaps this should
be:

"The strength of Transient Session Keys (TSKs) used to protect
data is ultimately dependent on the strength of keys generated
by the EAP method.  If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force attack.
In order to enable deployments requiring strong keys,  EAP methods
supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128 bits."

> "secure enough" for this purpose.

This requirement is about what should be implemented not what should be
used.

> requirement here? What exactly is the existing literature required

If a mechanism is well established and analyzed, presumably literature
citations are not an issue.  So I think this is redundant.  Also,
EAP methods do not derive TSKs.  Perhaps it should be:

"The development and validation of key derivation algorithms is difficult,
and as a result EAP methods SHOULD reuse well established and analyzed
mechanisms for key derivation (such as those specified in IKE [RFC2409] or
TLS [RFC2246]), rather than inventing new ones.  EAP methods SHOULD also
utilize well established and analyzed mechanisms for MSK and EMSK
derivation."

> TLS is ok (like we saw with the MitM attack against PEAP

Yes, that's definitely true. Do you have any text to recommend?

> getting something published at IETF is slow enough as it is).

I'd agree.

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 24 Sep 2003 10:52:49 -0700

> 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:
> >
> Another concern that motivated this reqts was  EAP SA naming. 
> For that purpose I'm not sure that a two-nonce exchange is 
> required, just a quantity from each side that together are 
> very likely to be temporally unique.  So maybe it is:
>
> "EAP methods SHOULD ensure the freshness of the MSK and EMSK 
> random number generator. A RECOMMENDED method is for each 
> party to provide a nonce of at least 128 bits, used in the 
> derivation of the MSK and EMSK.  The combination of the peer 
> and server nonce uniquely identifies the exchange."

[Joe] Is this the only way we are specifying names?  It seems that this
should be up to the EAP-method to define how an identifier is derived
for the exchange.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Sep 2003 16:20:44 -0700 (PDT)

> should be up to the EAP-method to define how an identifier is derived

I don't think this paragraph should be talking about naming (since there
is no other discussion in RFC 2284bis about this.  Maybe just delete the
last sentence.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap