eap Mailing List: Issue: exagerate claim in appendix C & B of eap-keying about EAP-TLS

[Florent Bersani (florent.bersani]

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

  Submitter name: Florent Bersani

  Submitter email address: florent.bersani [at] francetelecom.com

  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?