Chapter 4: Improving security
4. TKIP
5.8. EAP keying framework
We’ve seen that a lot of problems in WEP came from the absence of dynamic key management. Dynamic key management in 802.1x rectifies the drawbacks in the WEP security mechanism by deploying per-user session keys. Though 802.1x supports per-session keys (one session key for each user per session), most of the implementations only support global keys. But the difference is that if global keys are supported (WEP), the session key is only used to encrypt the global key and thus keeps the confidentiality of global keys unlike WEP.
EAP authentication involves the supplicant (EAP client), the access point and optionally the authentication server. We will describe the case where the authentication server is present (three-party exchange). When the authentication server is not present (two-party exchange), the EAP authentication method is implemented locally in the access point. This mode of exchange (called SOHO - Small Office Home office) is used in small networks. We will first describe the three- party exchange. In the next section, we will briefly describe SOHO.
There are 3 steps in the EAP keying framework [14][16]. They are: 802.1x authentication (EAP authentication protocol):
(Between the client and the authentication server)
During this phase, the EAP method is negotiated between the EAP client (supplicant) and the EAP server (authentication server).
An EAP master key (EMK) is derived between those two entities. Since this key is only held by the EAP client and EAP server, proof of possession of the EMK is a proof of mutual authentication and maybe used for fast reauthentication. This key must not be shared since it would enable a third party (e.g. access point) to impersonate the EAP client or server. To protect the EMK against compromising, EMK is not used directly (that’s why TEKs are used to protect data) and should not be derivable from other keys like the MSK.
Transient EAP Keys (TEKs) are derived from EMK and are used to protect the EAP exchange itself.
EAP methods generate a master session key (MSK) directly from a successful EAP authentication. The MSK is either exported by the EAP method to the EAP client within the CS-Token28 or is derived from the EMK, via a one-way function. This depends of the EAP method. For instance, EAP-TLS uses a one-way function. Whether the MSK is derived or transported, possession of the MSK must not provide information useful in determining the EMK and used in derivation of TSK.
RADIUS-based key distribution – Token distribution (AAA29 protocol) (Between the access point and the authentication server)
Between the access point and the authentication server, a mutual authentication must be ensured to avoid rogue access points or rogue authentication server.
The communication channel between the access point and the authentication server must provide per-packet integrity protection, authentication and confidentiality. For example, RADIUS uses a static key to protect this channel. However, a session key is more secure like in RADIUS over IPSec [16]. The authentication server transports the MSK to the access point within the AN-Token30.
802.1x key management (4-way handshake): TSK derivation (Between the client and the access point)
28 Package that provides integrity, authentication and encryption, in order to protect the MSK from
compromise. Support for the CS-Token is optional and most current EAP methods do not support it, since they derive the MSK as part of the EMK (like EAP-TLS)
29 Authentication, Authorization and Accounting
30 Package within which the MSK and one or more AAA attributes (client MAC address, access point
MAC and IP addresses, MSK lifetime etc...) is transported between the Authentication Server and the access point. [28]
After successful authentication and generation of the MSK, Both the client and the access point are supposed to possess the MSK. Transient Session Keys (TSKs) are derived from the MSK by a 4-way handshake: the 4-way handshake confirms that both the access point and the station possess the MSK. The TSK derivation should support mutual authentication so that the client will have the assurance that it is connected to the right access point.
The MSK is 192 bytes long. The first 32 bytes are called PMK (or pairwise master
key). The MSK is ciphersuite independent. So that the MSK is usable with any
ciphersuite (WEP-40, WEP-128, TKIP, CCMP etc…), it is often longer than necessary. So, it is cut to fit. For instance, TKIP and CCMP ciphersuites derive their TSK exclusively from the PMK.
The ciphersuite is negotiated between the EAP client and the access point using the link layer. The authentication server is not supposed to know the ciphersuite that will be used since it is not a party of the ciphersuite negotiation. So, the key generation in EAP methods should not be ciphersuite specific. This is the reason why the MSK is ciphersuite independent.
Figure 20 sums up the EAP keying framework.
EAP client (supplicant) AAA server (RADIUS server) NAS (access point) TSK derivation Protocol Mutual authentication Key: TSK EAP Protocol Mutual authentication Keys: EMK, /\ TEKs, MSK AAA Protocol Mutual authentication
Key: AAA session key (MSK) Distributes AN-Token to NAS
CS- Tok en (M SK ) AN-Token (MSK) TEK s
Shared secret (if RADIUS)
Figure 20: The 3 steps of EAP keying framework: The EAP authentication protocol, the AAA protocol and the TSK derivation protocol (adapted from [16])
framework [17]:
During the EAP authentication, an EAP Master key (MK) is derived between the EAP client (station) and EAP server (AS). This key is kept local and is never exported to a third party. This key may be useful during fast resume. That is, since the MK
possession is a proof of successful authentication, providing this key could shorten future EAP exchanges.
A Master session key (MSK) is derived between the EAP client and the
authentication server. The MSK is chosen as the keying material (AAA-key) and the AAA-Key is transported to the authenticator (access point) (phase 1-b). The MSK is exported by the EAP method to the supplicant. The MSK is at least 64 bytes long and the first 32 bytes is called Pairwise Master Key (PMK). Another key is derived between the EAP client and server: the Extended Master Session Key (EMSK). Like the MSK, the EMSK is exported by the EAP method but it is not transported to the authenticator. So, this key is only known by the supplicant and the authentication server. EMSK is not currently defined. It is reserved for future uses. For example, it could be used to derive additional keying material necessary against man-in-the- middle attack, or for fast handoff purposes.
Transient session keys (TSKs) are keys that are used by the ciphersuites (WEP-40, WEP-128, TKIP, CCMP etc...) 802.11i derive TSKs from the PMK only (first 32 octets of the MSK) where as WEP derive TSKs from the whole AAA-Key.
Transient EAP keys (TEKs) are used to establish a secure channel between the EAP client and server during the EAP authentication.
5.8.2. Two-party exchange (SOHO mode - without authentication server)
We’ve just seen that in a three-party exchange, an authentication server is present and there is a sophisticated authentication and distribution of keys. But in a two-party exchange (SOHO mode – Small Office Home office), a pre-shared key is entered manually. It is either entered as a stream of 256 bits or as a pass phrase. In the former case, those 256 bits correspond directly to the master key. In the latter case, the passphrase goes through an algorithm to convert the pass phrase into the master key: Master key = Hash (pass phrase, SSID, SSID length) [13]The output of this function is 256 bits corresponding to the master key.
The 4-way handshake (which occurs after a successful authentication and generation of the MSK in a three-party exchange) happens at the start of each session in a SOHO mode.
5.8.3. Advantage of using transient keys:
The keys generated by the authentication procedures or the pass phrase entered manually are not directly used for the TKIP encryption process. The master key is used to generate transient keys that will then be used in the negotiated cipher suite. For TKIP, we need one key for encryption function (cf. section 5.3) and one key for MIC computation (cf. section 5.1). For CCMP, only one key is needed for encryption and integrity. (Cf. section 7 below). Those transient keys help thwart any weak key attacks.