The pairwise key hierarchy is the most complicated, so let's review that first. The hierarchy starts at the top with a pairwise master key (PMK) delivered from the upper-layer authentication server or with a preshared key. Let's put preshared keys aside for the moment and look at the server-key approach. The PMK is the top of the pairwise key hierarchy. There is a different PMK for each mobile device, and from this all other pairwise keys are derived. The following paragraphs show how the PMK is created and how it is used to generate the actual keys used in encryption. Creating and Delivering the PMKLet's do a one-paragraph review of IEEE 802.1X. In Chapter 8 we saw that the IEEE 802.1X model has three components: a supplicant, an authenticator, and an authentication server (which we abbreviate just to server here). The mobile device is the supplicant and connects to an access point containing the authenticator. The supplicant uses EAP to communicate, first with the authenticator (in the access point), and then to the server. The server makes a decision to admit (or block) the supplicant and informs both the authenticator and the supplicant. By this method the authentication and authorization is done centrally (at the server). The highest key in the whole security context is held both by the user and the server, or the user's equipment and the server. This "supreme secret" key might be in a smart card, stored on a laptop disk, or remembered in a person's head. During the EAP authentication process, the chosen authentication method proves that both parties know the supreme secret. Chapter 9 outlined several ways to do this authentication. To be useful for RSN or WPA, the authentication method must, as a by-product of the authentication process, generate random-like key material that we can use for our key hierarchies. An authentication method that does this is called key-generating. Methods discussed in Chapter 9, such as TLS (SSL) and Kerberos, are key-generating. When using upper-layer authentication, you use the key material generated during authentication to create the PMK. If, instead of upper-layer authentication, you are using a preshared key, this preshared key is used directly as the PMK. Authentication occurs between the supplicant and the server, and the result is that both the mobile device and the server generate matching PMKs. But in order to use the keys to protect the wireless link, we need also to provide the PMK to the access point. How do we get the PMK from the server to the access point? In corporate networks, the access point(s) are connected to the authentication server by a network connection, usually using TCP/IP protocol, and it is necessary to transfer the PMK across the network. In small systems, it might be that a simple server is actually built into the access point unit. In this case, it is easy to transfer the key material. The IEEE 802.11i specification does not explicitly say how the PMK should be transferred from the server to the access point, although recommendations are given. By contrast, WPA specifies transfer of the PMK to the access point using the RADIUS protocol. The RADIUS attribute MS-MPPE-Recv-key (vendor_id=17) is used for this purpose. More details of RADIUS are provided in Chapter 8. At the end of the upper-level authentication phase and after completion of the key transfer, both the mobile device and the access point will have a copy of the PMK. The process of obtaining the PMK ends with the EAP-Success message being sent by the authentication, as described in Chapter 8. In the IEEE 802.1X model of the world, the EAP-Success message results in opening of the data port and data starting to flow. However, in WPA/RSN, this is not the case. There are further hurdles to clear before data is allowed. We need to derive keys for encryption between the access point and the mobile device. We need to verify that the keys are matching and we need to distribute a group key for use in broadcasts. If you are using preshared keys, none of the upper-layer authentication process is required and the value of the PMK is programmed directly into the mobile device and access point independently. The PMK is required to be 256 bits long that is, 32 bytes. Because 32 bytes would be a very long password to remember, systems using preshared keys may allow users to enter a shorter password, which the system then expands to 256 bits. IEEE 802.11i has a suggested method for generating a key from a shorter pass phrase. This allows users to enter memorable text strings and have then converted into a preshared master key in a consistent manner. Computing the Temporal KeysIn your enthusiasm to get encryption turned on, you might think at this stage that we are ready to slot the PMK into the encryption engine and get going. But we have a long way to go yet before we reach that stage. That is why it is called a hierarchy! The PMK is not used directly for any security operations. Instead it is used to derive a separate set of keys that will be used in protecting a link between two devices (for example, between the access point and a mobile device). Four separate keys are needed to do the job because there are two layers to protect the EAPOL handshake and the user's data and two cryptographic functions at each layer: encryption and integrity.[1]
These are referred to as the temporal keys because they are recomputed every time a mobile device associates to the access point. The collection of all four keys together is referred to as the pairwise transient key (PTK). For RSN/TKIP and WPA, each of these keys must be 128 bits long so that the PTK is a total of 512 bits long. The first two temporal keys sound familiar. They are the ones used to encrypt the data and protect it from modification. The second two we have not seen before. These are used to protect the communications between the access point and mobile device during the initial handshake.[2] For the moment, just accept that these EAPOL keys are needed; we will discuss them again shortly.
Because the temporal keys are recomputed each time a mobile device connects, there has to be something that changes when the computation is done; otherwise, you'd end up with the same temporal keys every time. This is called adding liveness to the keys, ensuring that old keys no longer work. Liveness is achieved by including a couple of special values called nonces in the computation. The value of the nonce is quite arbitrary except in one respect: a nonce value is never used twice[3] with the same key. The word "nonce" can be thought of as "N once" in other words, a value (N) only used once.[4] They say lightning never strikes in the same place twice (which is not true) and similarly nonces never come up with the same value twice (which should be true by design).
The temporal keys are effectively shared between the two devices because both ends of the link compute an identical copy. It is not enough for one device to include its own nonce value. Each device must generate a nonce, pass its nonce to the other device, and then derive the temporal keys by including both nonces in the computation. Also, to make sure the identity of the two devices is bound into the keys, the MAC address of each is included in the computation. Figure 10.2 summarizes the process and shows the inputs to the temporal key computation and the four output keys. The inputs are the PMK, a nonce from each side, and the MAC address of each side. The outputs are four 128-bit keys. How the "key computation block" is implemented is described later. Figure 10.2. Temporal Key ComputationExchanging and Verifying Key InformationWe have described how the authentication server and the mobile device mutually prove their identity and how key information must be derived by the mobile device and distributed to the access point. We have seen how the PMK is used to generate a set of temporal keys. However, one important step is missing: The mobile device has not yet verified that the access point is legitimate. Because we were able to talk to the server through the access point, it seems reasonable to assume it is trusted. However, it could be an access point that some hacker planted in the office and hooked up to the internal network. Maybe your janitor is a master hacker! Okay, maybe not, but the principle of security is trust no one so the access point must prove its credentials. This is where the requirement for a secure connection between the authentication server and the access point is important. A secure connection requires that the server and the access point share their own secret so the janitor's AP cannot establish such a connection unless it knows the server's secret, even though it is connected inside the office. The access point can only receive the PMK from the server through the secure connection. So if the access point can prove to the mobile device that it possesses the PMK, then it proves that it is trusted by the authentication server, which is master of all security. So this defines the test: The access point and the mobile device must prove to each other that they both possess a copy of the secret PMK. This idea of mutually proving possession of a secret key was also part of WEP but, as we saw in Chapter 6, the method used was completely broken and was easily tricked. In WPA/RSN the processes of proving key ownership is combined with the process of deriving the temporal keys using a key message exchange before the connection can be opened for business. There are four steps to the process, giving the name "four-way exchange," and the exchange is done using EAPOL-Key messages. First we will look at the four-way exchange in overview and then drill down in more detail. The four-way exchange occurs between the access point and the mobile device. However, for consistency with IEEE 802.1X, these are referred to as the authenticator and the supplicant respectively. Remember, Authenticator = Access Point.
The first step is for both the supplicant and authenticator to generate a nonce value. There is no connection between the two values they are independent however, there are specific rules about how the values are generated that are covered later in this chapter. The nonce selected by the authenticator is called ANonce and that of the supplicant is the SNonce. This is followed by the exchange of four messages that we refer to as A, B, C, and D. Message (A): Authenticator |