MSK
Each EAP method specifies (actually may specify) its own way to derive a MSK.
This means you have to look in the specification of the EAP method you are using in order to know of the MSK is derived.
Relevant wording from RFC3748:
Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method.
Here "exported" means that the EAP method produces the MSK value and make it available to the lower-layer protocol (eg. the Wifi stack).
An example: EAP-TLS
For example, let's look at EAP-TLS. EAP-TLS works by conducting a TLS (≤ 1.2) handshake over EAP.
At the end of a standard TLS handshake, a master secret is generated as:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
client.random || server.random)
This key material is a shared secret between the two TLS peers.
When using TLS for tunneling data, this shared secret is used to generate secret keys and initialization vectors for encrypting and authenticating (MAC) the data.
In EAP-TLS, this shared secret is instead used to derive the MSK:
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
MSK = Key_Material(0,63)
RADIUS
Now, when you are using RADIUS, the Wifi AP needs the MSK in order to derive the keys used to secure Wifi communications. However, the EAP actually happens between the EAPOL supplicant and the RADIUS server: the RADIUS server needs to communicate the MSK to the Access Point.
AFAIU, this is done by using the MS-MPPE-Send-Key
and MS-MPPE-Recv-Key
attributes from RFC2548 as explained in RFC5216:
The MSK is divided into two halves, corresponding to the "Peer to
Authenticator Encryption Key" (Enc-RECV-Key, 32 octets) and
"Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets).
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
(MS-MPPE-Recv-Key in [RFC2548]). Also known as the
PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
(MS-MPPE-Send-Key in [RFC2548])