How does the EAP-TLS handshake work, exactly?

Question

I'm trying to understand EAP-TLS authentication, but I'm struggling to understand a few bits:

1. Before the supplicant sends any certificates to the server, it usually verifies the server's identity.

After it does, how can it ensure that it's talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity?

2. If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext?
3. After the client has been authorized, what happens exactly? How is the shared symmetric key derived? How is it passed along to the Access Point so that it can receive/send data from/to the supplicant (since the RADIUS server's part ends after doing the authentication)?

Answer 1

In EAP-TLS, the peer (supplicant) and the authenticator do a TLS handshake. In practice, the authenticator usually relays the EAP mesages to an authentication (RADIUS) server which means that the TLS handshake is actually done between the supplicant and the authorization server.

[ TLS   ]<--------------------->[ TLS    ]
[ EAP   ]<--------------------->[ EAP    ]
[ EAPOL ]<->[ EAPOL | RADIUS]<->[ RADIUS ]
[ Wifi  ]<->[ Wifi  | ...   ]<->[  ...   ]
Supplicant    Authenticator      Authentication Server
(Wifi Client)  (Wifi AP)          (RADIUS server)

The TLS communication between the supplicant and the authorization server works as expected but usually mutual authentication is used:

1. server sends its certificate chain
2. client validate certificate chain against server name
3. client sends its certificate chain
4. server validate certificate chain
5. further crypto magic happens

Once the TLS handhsake is finished, the TLS session is not used anymore: it is not used to transport encrypted data.

If the handshake succeeds, the RADIUS server send a "RADIUS Access-Accept/EAP-Message/EAP-Success" message to the authenticator.

At the end of the TLS handshake, both the supplicant and the authentication server derive a "TLS master secret". This TLS master secret is used to derive a Master Session Key (MSK), see RFC5216:

In EAP-TLS, the MSK, EMSK, and Initialization Vector (IV) are derived from the TLS master secret via a one-way function.

This MSK is sent by the authentication server to the authenticator as part of the "RADIUS Access-Accept/EAP-Message/EAP-Success" RADIUS message. As far as I know (?), the MSK is in practice sent using the following RADIUS Attributes, RFC2548:

• MS-MPPE-Send-Key
• MS-MPPE-Recv-Key

See the StrongSwan wiki on this topic:

For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys [...]

See this Security StackExchange answer on this topic.

See RFC5216:

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

Once the authenticator has the MSK, both supplicant and authenticator can use the MSK has a PSK to secure the communication. In practice, the Wifi Pairwwise Master Key (MPK) is derived from the EAP MSK.