Subject: [eap] Issue: exagerate claim in appendix C & B of eap-keying about EAP-TLS

From: Florent Bersani <[email-masked]>
Date: Wed, 06 Oct 2004 11:22:04 +0200

Description of issue: exaggerate claim in appendix B of eap-keying about 
EAP-TLS

   Submitter name: Florent Bersani

   Submitter email address: [email-masked]

   Date first submitted: 10/06/2004

   Document: Keying Framework

   Comment type: 'E'ditorial

   Priority: 1 should fix

   Section: appendix C &B

   Rationale/Explanation of issue:

Appendix C claims that EAP-TLS RFC 2716 is very explicit on its key 
derivation:

"As described in [RFC2716], the formula for the derivation of the MSK,
   EMSK and IV from the MK is as follows:

   MSK           = TLS-PRF-64(MK, "client EAP encryption",
                      client.random || server.random)
   EMSK          = second 64 octets of:
                   TLS-PRF-128(MK, "client EAP encryption",
                      client.random || server.random)
   IV            = TLS-PRF-64("", "client EAP encryption",
                      client.random || server.random)"

How, I find section 3.5 of RFC 2716 less straight-forward. In 
particular, there is no occurrence in RFC 2716 of MSK nor any of EMSK

Requested change

Either write an update of RFC 2716 that makes things more precise on its 
key derivation part
Or make things more honest in eap-keying by saying sth like:

"The key derivation scheme specified in RFC 2716 that was specified 
prior to the introduction of the terminology MSK and EMSK MUST be 
interpreted as follows:
  MSK           = TLS-PRF-64(MK, "client EAP encryption",
                      client.random || server.random)
   EMSK          = second 64 octets of:
                   TLS-PRF-128(MK, "client EAP encryption",
                      client.random || server.random)
   IV            = TLS-PRF-64("", "client EAP encryption",
                      client.random || server.random)"
(also note issue 257 and the deprecation of MK)

Additionally, things could be similarly clarified regarding the TEK 
derivation of EAP-TLS presented in Appendix B by saying:
"The key derivation scheme specified in RFC 2716 that was specified 
prior to the introduction of the terminology TEK MUST be interpreted as 
follows:
TEK           = TLS-PRF-X(master_secret, "key expansion",
                   server.random || client.random)"

but who is eap-keying to impose normative text on EAP-TLS?

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