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

From: <[email-masked]>
Date: Thu, 25 Sep 2003 13:06:51 +0300

Bernard Aboba wrote:
> > 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.
> 
> 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]."

Hmm, does this create a dependency to the keying framework?
I'm not sure; but it's not possible to actually implement 
a working system without knowing how this derivation is done...

Also, since many deployed systems just use AAA-Key==MSK, this
certainly should be documented somewhere... how about this?

"The AAA-Key is derived from the keying material exported by the 
EAP method (MSK and EMSK). This derivation occurs on the AAA server.
In many existing protocols that use EAP, the AAA-Key and MSK 
are equivalent, but more complicated mechanisms are possible
(see [KEYFRAME] for details)."

> 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."

This works for me (except that I'm not sure if the 
last sentence is actually necessary).

<snip>

> 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
> 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."

Looks ok!
 
<snip>

> > 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?
> 
> 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."

Ok.

> > 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).
> 
> Yes, that's definitely true. Do you have any text to recommend?

Hmm... I'm not sure if we actually need any text about this. 
Presumably the "security considerations" section for the EAP
method should discuss any known weaknesses, and the yet-unknown
weaknesses we by definition don't about yet :-) And I really
wouldn't like to see a requirement saying that "EAP methods
must have formal security proofs" or anything like that.

So, the recommendation to reuse existing work as 
much as possible might be sufficient here?

Best regards,
Pasi
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Sep 2003 20:58:34 +0300

> certainly should be documented somewhere... how about this?

Yes, this is important.

> (see [KEYFRAME] for details)."

Works for me.

> must have formal security proofs" or anything like that.

Agree.

--Jari