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

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Feb 2005 22:42:04 +0200

Florent Bersani wrote:

> 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

Yes.

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

This would work for me.

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Feb 2005 22:49:22 +0200

Oops, responded to an old e-mail. Nevertheless, it
does not seem to appear in the history of issues in
the issue file nor do I see a fix in the latest
keying draft. So maybe we forgot this one, or
I'm missing something obvious why it isn't an issue...

--Jari