IEEE 802.11 i Robust Security Network
IEEE 802.11i Robust Security NetworkOnce the IEEE 802.11i draft standard is complete, there will be a total of three authentication and key management architectures in IEEE 802.11, namely the two that were originally defined for use in the context of WEP in IEEE 802.11-1997 (i.e., "Open System" and "Shared Key"), and the newer IEEE 802.1X-based authentication mechanisms that are defined for use in the context of an IEEE 802.11i RSN. In fact, the term "RSN" is synonymous with "an IEEE 802.11 LAN that uses an IEEE 802.1X-based Authentication and Key Management Protocol." The terms "RSN" and "IEEE 802.1X" are effectively synonymous, since an RSN is defined in the IEEE 802.11i draft as "An IEEE 802.11 ESS relying on IEEE 802.1X for its authentication and key management services." There are two different RSN ciphersuites, one based on AES (CCMP), and one based on RC4 (TKIP). TKIP is a significant improvement over WEP, and is designed to be implementable on most hardware platforms that already support WEP. This allows an upgrade path for end users who have already made substantial investments in WLAN technology, since TKIP can be installed in many older devices by simply upgrading the firmware and/or driver software. However, despite the fact that TKIP is a massive improvement over WEP, it is not the best available security solution. To achieve this level of security, end users must purchase and deploy new AP hardware that includes support for AES encryption. The new hardware will probably support both TKIP and CCMP, so that STAs can support either type of encryption. In fact, the IEEE 802.11i draft includes support for what it calls "transition security networks" or TSNs, in which APs may support a mix of WEP and RSN STAs. This is horrifically insecure (in fact, it is no better than WEP, since every frame that is super-encrypted by RSN between an RSN STA and the AP is then only WEP-encrypted to a legacy STA). If an attacker can crack WEP (and we know that tools to do that are readily available), then the attacker can intercept traffic that an RSN STA sends to a pre-RSN STA. The benefits of RSN do not begin to accrue until the entire LAN is migrated to RSN-capable status. RSN Authentication and Key Management MechanismsIEEE 802.1X "Port-Based Network Authentication" was originally designed for bridged (i.e., layer-2 switched) networks, in which eavesdropping is infeasible (or at least somewhat challenging) due to the fact that each station is endowed with a dedicated link to a bridge (i.e., layer-2 switch). The original IEEE 802.1X standard was designed based on the assumption that tapping into the communication link between the station and the bridge/switch was nontrivial, and would be relatively easy to detect. By the time that implementations of the IEEE 802.1X-2001 standard first appeared, networks had been rapidly adopting bridged (i.e., layer-2 switched) topologies for quite some time, rapidly moving away from shared-media hubs, so there was no strong demand for IEEE 802.1X-2001 to support shared-media LANs, although the standard does not prohibit operation over shared LAN topologies. As IEEE 802.11 LANs increased in popularity, the need for a properly designed authentication and key management protocol manifested itself. It was natural for the IEEE 802.11i TG to want to leverage mechanisms that had already been defined in another IEEE 802 standard, rather than inventing something that was totally specific to IEEE 802.11. However, in shared-medium networks such as those based on IEEE 802.11, extensions to IEEE 802.1X needed to be defined such that its network authentication services could be provided securely, because eavesdropping was not only possible, it was easy. IEEE 802.1X-2001 defines a framework based on operating the Extensible Authentication Protocol (EAP)[41] over LANs, via a protocol known as EAPoL (or EAPOL). IEEE 802.11 is an example of the cryptographer's worst-case threat model: the adversary is the channel, in that an attacker can choose to deliver or block any frame, misroute frames, corrupt and modify frames, or even create forged frames from scratch (given sufficient information). The implication of this is that no shortcuts to security are possible. The wireless environment is, if not inherently hostile toward valid users then at least it is inherently friendly toward malicious users.
Because the original IEEE 802.1X was unsuitable for use in the IEEE 802.11 environment, extensions to IEEE 802.1X were defined to ensure that the network authentication services provided by the extended IEEE 802.1X would be as secure in IEEE 802.11 wireless shared-medium networks as the IEEE 802.1X procedures that are used in dedicated-media networks such as bridged (switched) IEEE 802.3 LANs. The EAP is not tied to any particular authentication algorithm, hence its extensibility (and hence also why it cannot define a secure keying scheme[42] ). The EAP defines a small number of messages that are used to communicate between the EAP Client (in the device seeking to be authenticated) and the AS. This design allows the two peer EAP entities to mutually determine whether the device seeking to be authenticated should be granted access to the network (based on the algorithm-specific authentication credentials, such as the user's identification and password). In IEEE 802.11i, there is a strong preference for choosing EAP methods that provide for strong mutual authentication, so that both sides know that they are communicating with the intended party, and not an impersonator implementing a man-in-the-middle attack. The EAPoL Authenticator (resident within the AP in the case of IEEE 802.11, or in an Ethernet bridge (switch) in the case of IEEE 802.3) is only required to interpret the outcome of the negotiation without being required to participate in the negotiation itself.
EAPoL is used to exchange the EAP messages that are actually performing the authentication between the STA that is seeking to be authenticated (the EAP Client) and an EAP "server" entity known as the Authentication Server (AS). The EAPoL Supplicant is an EAP and EAPoL "client." The Authentication Server is not an EAPoL entity, unless it is embedded in the same machine as the EAPoL Authenticator. The station seeking to be authenticated uses EAPoL to communicate across its local LAN segment with a device that enforces the authentication; for example, an Ethernet bridge (i.e., layer-2 switch) or an IEEE 802.11 AP. Again, the EAPoL exchange takes place between two entities, one associated with the station desiring to be authenticated, an EAPoL entity known as the "Supplicant," and the other associated with the device that enforces the access to the network (e.g., the bridge (i.e., layer-2 switch) or AP, an EAPoL entity known as the "Authenticator." Besides restricting network access only to authenticated stations, the Authenticator also acts as a mediator in the EAP conversation between the EAP Client and the AS. Table 7-2 lists the five types of EAPoL packets that may be sent, according to IEEE 802.1X-2001.
EAP packets are encapsulated in EAP-Packet frames to enable them to cross the LAN segment between the Supplicant and the Authenticator. EAPoL also provides some control features; for example, an EAPoL-Start message was defined to initiate the EAPoL exchange; similarly, an EAPoL-Logoff message was defined to terminate a connection. Even though these two control messages are part of IEEE 802.1X-2001, the IEEE 802.11i draft does not require them. IEEE 802.1X-2001 also defined an optional capability to use the EAPoL-Key [Descriptor] message[43] to exchange cryptographic keys, but no mechanism was defined to enable keys to be exchanged securely. Note that the format of the EAPoL-Key [Descriptor] message in IEEE 802.11 is different from that in IEEE 802.1X-2001. The format of the EAPoL-Key Descriptor that is used in IEEE 802.11i is shown in Figure 7-18.
Figure 7-18. Format of the EAPoL-Key Descriptor
Figure 7-19 depicts the protocol relationships among the Supplicant (associated with the EAP Client's STA), Authenticator (associated with the AP's STA), and the AS. It also shows the relationship of EAP to EAPoL (and of EAP to RADIUS), which is one example of a protocol that may be used to implement a secure channel between the Authenticator and the AS). The Supplicant and the AS exchange messages encoded in the EAP, and these EAP messages are encapsulated in EAPoL frames as they are transmitted between Supplicant and the Authenticator across their common LAN segment. Figure 7-19. Authentication and key management protocol peer relationships
At the EAP layer, the EAP peers are unaware of the presence of the Authenticator, which simply serves as a relay between the EAPoL and EAP-over-Secure-Channel domains. The EAPoL Authenticator[44] simply acts as a relay for these EAP packets by extracting the EAP packets from within the EAPoL frames and sending those EAP packets to the Authentication Server over the secure channel that is required to exist between the EAPoL Authenticator and the EAP AS. EAPoL employs a small number of frame types to carry the various EAP messages between the Supplicant and the Authenticator across their common LAN segment.
The IEEE 802.11i draft will neither specify nor mandate the protocol(s) to be used to secure the Authenticator-to-AS channel. A typical implementation of IEEE 802.11i, for example, might be based on RADIUS.[45] Even though RADIUS is not mandated by the IEEE 802.11i or IEEE 802.1X standards, it is a convenient protocol that many early implementations of IEEE 802.11i will use for securely exchanging EAP messages between the Authenticator and AS, as well as a secure out-of-band channel for Pairwise Master Key (PMK)[46] distribution from the AS to the Authenticator.
RADIUS, or any protocol with similar attributes that can provide a secure channel over which the EAP packets can flow, is logically equivalent to EAPoL, in that it is used to encapsulate the EAP packets between the Authenticator and the AS, after the EAP packets have been extracted from the EAPoL frame. RADIUS has messages to augment EAP; for example, special RADIUS packet types have been defined that may be used to transmit the PMK from the Authentication Server to the Authenticator, over the secure channel[47] between the AS and the Authenticator. Any other protocol used to implement the Authenticator-to-AS secure channel would also need to support additional message types such as this, to support the proper operation of EAP. The transmission of the PMK to the Authenticator is not accomplished using EAP messages, since EAP is an end-to-end protocol between the Supplicant (EAP Client) and the AS (EAP Server).
EAP Packets and EAPoL FramesAll EAPoL frames are normal IEEE 802.11 data frames, thus they follow the format of IEEE 802.11 MSDUs and MPDUs. With reference to the IEEE 802.11 frame format defined in IEEE 802.11-1999 Clause 7.1.2, an MPDU may be up to 2346 octets in length, which encapsulates an MSDU payload that is up to 2312 octets in length. The remaining 34 octets in the MPDU comprise the IEEE 802.11 header (24 or 30 octets) and the four-octet Frame Check Sequence that concludes the frame. For practical reasons, it is safer to presume that the long form of the MPDU header will be used, so that the MSDU will not need to be fragmented. EAPoL messages, like other data packets (MSDUs) that are transmitted over IEEE 802.11 LANs, are de-multiplexed using information contained in the LLC (or LLC/SNAP) header, which comprises the first three (or eight) octets of the MSDU. In the particular case of EAPoL frames, LLC/SNAP encapsulation is used. Figure 7-20 illustrates an MPDU that contains an EAP packet, encapsulated in an EAPoL (IEEE 802.1X) header. Figure 7-20. Format of an IEEE 802.11 MPDU with an embedded EAPoL packet
Referring to Figure 7-20, the IEEE 802.2 LLC header's DS (Destination Service Access Point, or DSAP) and SS (Source Service Access Point, or SSAP) fields are both set to a value of 0xAA, indicating that an IEEE 802.2 SNAP header follows the LLC header. The IEEE 802.2 LLC header's Control field is set to 0x03, indicating that this is an unnumbered information frame. To indicate that a standard Ethernet type is being used in the IEEE 802.2 SNAP header's Type field, the IEEE 802.2 SNAP OUI field is set to a value of 0x000000. A value of 0x888E in the SNAP header's Type field indicates that an IEEE 802.1X frame header is next. The IEEE 802.1X header begins immediately after SNAP's Type field, starting with the Protocol Version (PV) field, the value of which is defined in the current IEEE 802.1X specification. The version specified in the IEEE 802.1X-2001 specification is 0x01. The next field is the one-octet IEEE 802.1X Packet Type (PT), the five values of which were listed previously, in Table 7-2. The IEEE 802.1X Packet Body Length (PBL) follows the Packet Type. Because the LLC/SNAP header is eight octets long, and the IEEE 802.1X header is an additional four octets, a total of 12 octets of the available MPDU payload is consumed, leaving 12 octets less for the MSDU, so the IEEE 802.1X PBL value can be at most 2300 octets (based on the fact that the MSDU can be at most 2312 octets). The limit of 2300 is for unencrypted EAPoL-Key messages. Note that in cases where the EAPoL-Key message is encrypted using CCMP or TKIP additional octets will be consumed, which will have the effect of further reducing the MPDU's payload capacity; hence the maximum PBL will not be able to be as large as if encryption were not performed. In the case of EAP, the need to transmit large-sized frames that would bump up against this restriction is dependent on the authentication method being used. When the Packet Type field in an EAPoL packet is set to a value of 0x00 (meaning EAP-Packet), an EAP header follows the IEEE 802.1X (EAPoL) header. The EAP packet header begins with a one-octet Code field that defines the function of the EAP packet. The EAP packet format is shown in Figure 7-21:[48]
Figure 7-21. EAP packet format
There are four EAP Codes: 0x01 (Request), 0x02 (Response), 0x03 (Success), and 0x04 (Failure). For EAP-Request or -Response packets, the one-octet Identifier field contains a value that is used to match Responses to Requests. An EAP packet need not have a Data field, but a Data field will be present if the Code is set to Request or Response. For such EAP-Request and EAP-Response packets, the first octet of the Data field is a Type field that indicates which authentication algorithm is in use (e.g., EAP-TLS, EAP-PEAP, EAP-TTLS, etc.). The remainder of the Data field will be algorithm-specific data. The STA initiates the association process. Once the STA and AP have completed setting up their association, the AP and STA will indicate success via one of the following APIs:
If the AP is RSN-capable and configured such that RSN is enabled, the Authenticator sends an EAPoL EAP-Packet message to the Supplicant, which contains an EAP-Request (Identity) packet. The entire packet exchange is shown in Figure 7-26. Before we examine that entire exchange, we will see how the peers prepare for this exchange. Figure 7-26. Complete RSN negotiation procedure
The EAPoL-Start message is triggered once the STA and the AP have completed their association, a condition that is detected by one of the APIs listed previously. The Supplicant's STA includes the RSN Information Element (RSN IE) in the management frames that are used to facilitate association, which lets the Authenticator's STA (in the AP) know that this particular STA desires to join the RSN. The AP constructs its RSN IE based on whatever subset of its RSN capabilities are enabled, and the AP then includes the RSN IE in its Beacon and Probe Response frames. After the association has been established, only IEEE 802.1X protocol messages (i.e., EAP and its associated authentication method) flow across the link until authentication completes; the IEEE 802.1X Port Access Entity (PAE) in the Supplicant filters all non-EAP traffic during this period. The AP also has a per-association PAE and all traffic to and from this STA will also be filtered at the AP. Until upper-layer authentication completes, the PAE ensures that only EAP packets are sent or received between this STA and the WM. The IEEE 802.1X-based Authentication and Key Management protocols and selected EAP method allows the Authenticator and the Supplicant to prove to each other that they both know the PMK. It is essential that this be done without divulging the PMK to eavesdroppers. Even though the EAP-Client (EAPoL Supplicant) has been successfully authenticated by the Authentication Server, it cannot use the link until it has successfully derived the necessary encryption and authentication keys, which depend on the ciphersuite chosen in the RSN IE in the AP's Beacon and Probe Response frames. The format of the RSN IE is depicted in Figure 7-22. Figure 7-22. Format of the RSN IE
The ciphersuites and the Authenticated Key Management Protocol suite selectors all have the same format. They consist of a three-octet OUI field, which allows for vendor extensions (the value 0x000000 is reserved for ciphersuites described in the forthcoming IEEE 802.11i standard, which will eventually be integrated into a future version of IEEE 802.11, presuming that IEEE 802.11i succeeds in producing a ratified standard). Figure 7-23 shows the format of a generic suite selector. Figure 7-23. RSN IE ciphersuite selector format
Vendors that have their own OUI may define up to 256 suite types per OUI using this structure. Figure 7-24 shows some of the currently defined suite selectors (taken from the IEEE 802.11i draft, version 5.0). Note that there is no defined Authentication Suite selector for either Open System or Shared Key authentication, since these selectors are only usable in the context of pre-RSN devices. Only an RSN-related authentication method would need to be specified within an RSN IE. Figure 7-24. IEEE 802.11i ciphersuite selectors
An alert reader may wonder why, if there is no authentication suite selector for Open System or Shared Key authentication, are there not one but two ciphersuite selectors for WEP? The answer is that WEP encryption can be used as a group ciphersuite, while at the same time CCMP or TKIP is used as a unicast ciphersuite. The rule for unicast versus multicast ciphersuite selection is that the unicast cipher must always be stronger than the group ciphersuite. It is, therefore, not possible to use WEP as a unicast ciphersuite in the context of RSN, because there is no weaker ciphersuite that one might choose as the group ciphersuite. Note that the protocol specification related ciphersuite number 0x03 (WRAP) has been removed from the IEEE 802.11i draft specification. WRAP was an AES-128-based encryption algorithm based on Offset Codebook (OCB) mode, and the acronym WRAP stood for "Wireless Robust Authenticated Protocol." WRAP last appeared in the 3.0 version of the IEEE 802.11i draft. WRAP's ciphersuite selector ID value assignment will be preserved so that vendors who had already implemented WRAP still have a legal way to identify that ciphersuite within the RSN IE. EAP Negotiation ProcedureAn EAP authentication method is negotiated as follows. One peer proposes an EAP authentication method to the other by sending an EAP-Request packet with the Type field's value set to the assigned number of the desired authentication method. If the receiving peer supports that authentication method, it will respond with an EAP-Response using the same Type as was proposed by the first peer. If the receiving peer does not support this authentication method, its EAP-Response packet will have the Type set to "NAK", and the original peer may then attempt to authenticate using a different method by proposing a different Type. A successful EAP authentication message flow is documented in the upper portion of Figure 7-26. In the case of IEEE 802.11i's usage of IEEE 802.1X messages, the Authenticator initiates the EAP exchange by sending an EAP-Request to the Supplicant, which then responds. The Authenticator passes the response to the AS, which then begins to send messages to implement its preferred EAP method; for example, EAP-TLS (the de facto EAP method in early implementations of IEEE 802.11i). The Authenticator is triggered to begin the exchange by noticing that the association has completed properly. At the completion of a successful EAP authentication exchange, the AS informs the EAP Supplicant that the authentication has succeeded by sending an EAP-Success packet (Code = 0x03). The Authenticator is able to detect the EAP-Success code, and registers the fact that this EAPoL Supplicant now represents an authenticated station. Using the secure channel between the AS and the Authenticator, the AS also sends one other essential piece of information to the Authenticator, the PMK that has been generated by both the EAP-Client (EAPoL Supplicant) and the AS. By virtue of the EAP-Client's authentication exchange with the AS, the EAP-Client already knows the PMK. Neither the Supplicant nor the Authenticator can trust the channel for communication until they have securely determined that each party knows the PMK, because neither has authenticated the other (only the AS and EAP-Client have mutually authenticated). Hence, the AP (Authenticator) does not yet know it is communicating with the party that the AS authenticated, and the STA (Supplicant) does not yet know it is communicating directly with a legitimate AP. In order to establish a secure channel, the Authenticator and Supplicant use a "four-way handshake," in which each peer can convince itself that it is communicating with the intended peer for this association, and to use the PMK to derive the operational cryptographic keys that will protect this session. The four-way handshake demonstrates to each peer that the other peer knows the PMK, without leaking any useful information to a computationally bound attacker, active or passive. The four-way handshake provides each peer with proof that the other peer knows the PMK, and therefore that they both are whom they claim to be. The bottom portion of Figure 7-26 includes the steps involved in the four-way handshake, which is comprised entirely of EAPoL-Key messages. A replay counter is part of each EAPoL-Key message, which enables detection (and thus prevention) of replay attacks. The replay counter is incremented by 1 for each successive message in the four-way handshake. Each retransmission of a given message uses the same replay counter value as was used when the message was first transmitted. Filtering (from the STA's Perspective)Until the four-way handshake is complete, the only unicast frames that are permitted to be sent by the STA are IEEE 802.1X (EAPoL) frames. The IEEE 802.1X Port Access Entity enforces this constraint. Once the four-way handshake is complete, the STA has unicast pairwise keys and can receive encrypted unicast frames; for example, the frames involved in the group key handshake, which follows the four-way handshake. Once the group key handshake (which is only two messages) has completed successfully, the STA is now able to decrypt multicast traffic encrypted with the group temporal key by the AP. (In infrastructure mode, the only device that sends encrypted multicast traffic is the AP.) Before delving into the four-way handshake, it might be a good idea to review how we got here. Figure 7-25 shows the sequence of messages that leads from a STA joining a WLAN up to when it needs to begin the four-way IEEE 802.1X authentication phase. Remember that the messages related to Open System authentication only exist to retain backward compatibility with the IEEE 802.11-1999 state machine that governed the ordering of initial events; in other words, the original standard dictated that Authentication preceded Association. Figure 7-25. Prerequisite messages to the four-way handshake
The complete four-way handshake is depicted in Figure 7-26. The figure shows the four-way handshake in the context of the entire access process, picking up where Figure 7-25 left off. The EAPoL exchange is the authentication exchange, and the four-way handshake is the key management exchange. The First Message of the Four-Way HandshakeThe first EAPoL-Key message of the four-way handshake is sent from the Authenticator to the Supplicant. The main purpose of the first message is to carry the randomly generated Authenticator Nonce (ANonce). Any observer could eavesdrop on this message and learn the Authenticator's chosen ANonce. Upon receiving the first message, the Supplicant has learned the ANonce. Subsequent messages in the four-way handshake ensure that only the legitimate Authenticator is in communication with the Supplicant. Any eavesdropper could also have attempted to impersonate the Authenticator by forging an EAPoL-Key message after it saw the EAP-Success packet. However, such an impostor would not know the PMK; thus it will not be able to successfully forge future EAPoL-Key messages, so the only exposure at this point is possibly to denial-of-service (DoS) attacks.
The Second Message of the Four-Way HandshakeThis message acknowledges receipt of the first message, flowing back from the Supplicant to the Authenticator. Of course, the act of sending this message does not serve as an acknowledgment until after the Supplicant can tell that the Authenticator has received this message. Using MAC-layer ACK procedures, the Supplicant may be able to tell that the Authenticator has received the second message, but the MAC-layer ACK could be forged, so the only real proof that the Authenticator has received the second message is for the Supplicant to receive the third message. If the Supplicant does not hear the third message within a reasonable amount of time, it will re-transmit the second message (up to three times). Because of the cryptographic protections on which the four-way handshake is built, the second through fourth messages of the four-way handshake can only be forged if the PMK has been compromised. The second message carries the RSN IE (see Figure 7-22) that the Supplicant's STA has constructed based on the ciphersuites it supports, and is the same RSN IE that the Supplicant's STA used during the association process with the AP. The EAPoL-Key Descriptor's Data field is used to transport the RSN IE. To be specific, the STA indicates the authentication suite and key management suite, as well as the unicast and group ciphersuites that it supports, in the Association Request message that it sent to the AP well before the four-way handshake ever started. When the Authenticator receives the second message of the four-way handshake, it knows that there is no man-in-the-middle. The contents of the second message are sufficient to prove (in a cryptographically sound sense) that this is the case. After receiving the second message, the Authenticator also knows that the Supplicant has computed the PTK, and now the Authenticator has the necessary information to do the same. The AP has created its own RSN IE that defines which ciphersuites are allowed to be used within this ESS. By sending its RSN IE to the Authenticator's STA in the second message, the Supplicant's STA informs the Authenticator's STA of which ciphersuites it supports, which controls how the keys are derived, and it is confirming that it is the same STA that associated with the AP. The STA's choice of valid cryptographic algorithms is made from the intersection of the set of ciphersuites that are supported by the STA and the set that is supported by the AP (which the STA learned from either a Beacon or Probe Response that was generated by the AP). The Supplicant randomly chooses[50] its own nonce, known as the SNonce after it received the first message. At this point, the Supplicant has sufficient information to generate the temporal keys used for directed packet transmission and reception. Moreover, derived cryptographic keys protecting [51] the remainder of the key exchange are derived from the ANonce contained in this first message, as well as being based on the SNonce and the STA's RSN IE.
A message digest of the second message is included as part of the second message. This message digest protects (i.e., is computed over) this entire EAPoL-Key Descriptor and uses one of the keys that the Supplicant has derived from the PMK and the two nonces, among other inputs. Specifically, the Supplicant has derived the EAPoL-Key MIC Key (MK). This key is more generically known as a Key Confirmation Key, or KCK. The next subsection describes the key derivation procedure in more detail. The message digest of the second message is included in the MIC field of the EAPoL-Key Descriptor, which is illustrated in Figure 7-27. Figure 7-27. EAPoL-Key Descriptor format with the MIC field highlighted
The Authenticator will be able to verify this message digest once it has received the second message from the Supplicant, and will be able to derive the EAPoL-Key MK for itself once it has received the second message (the Authenticator cannot calculate the MK until after it has received the SNonce from the Supplicant). Only a Supplicant that knew both of the nonces and the PMK could have sent this message, since it contains a message digest that could only have been computed if the PMK were known. To summarize, the second message of the four-way handshake serves to transmit the SNonce to the Authenticator, and this message also includes a cryptographic message digest that allows the Authenticator to verify that it is communicating with the same STA that had associated with it earlier. This message confirms to the Authenticator that the Supplicant is legitimate and that there is no "man-in-the-middle" attack under way. Like the first message, the second message is also sent in the clear (but as noted previously, it is protected by the message digest that is computed over the EAPoL-Key Descriptor and which is included as part of the EAPoL-Key Descriptor, in the MIC field of the Descriptor). The second message can also be observed by third parties, who would now have seen the ANonce in the first message and the SNonce and second message, as well as the Supplicant's RSN IE, but who nonetheless cannot forge the message digest (MIC) in the EAPoL-Key message without knowledge of the PMK.
The key derivation procedure establishes a chain of trust, which is based on the user's credentials and the configuration of the network. The configuration of the network ensures that the Authenticator and the Supplicant share a common LAN segment, and that the Authenticator and the AS are connected by a secure channel (which probably crosses multiple router hops, but is logically a direct link between the two of them). The EAP method is used to establish the cre dentials and validate the user, to form the basis for the network access control that is performed by the Authenticator. The key derivation process alluded to previously, which is performed in parallel by both the Supplicant and the Authenticator, is known as the "Pairwise Key Hierarchy." The Pairwise Key Hierarchy defines how to combine the ANonce, SNonce, the Authenticator's MAC address (AA), the Supplicant's MAC address (SA), a specific ASCII string, and the PMK as input to a pseudo-random function (PRF). The PRF outputs a large enough number of bits sufficient to define the EAPoL-Key Encryption Key (EK), the EAPoL-Key Message Integrity Check (MIC) Key (MK), and the necessary Pairwise Temporal Key(s) for protecting unicast data traffic (the PTK material is used for both authentication and encryption). The length of the output of the PRF depends on the ciphersuite that was determined based on comparing the RSN IEs during the association process. Specifically, the PRF output is separated into the following components: the MK (used to create a keyed message digest of certain of the EAPoL-Key Descriptor messages, to bind the Supplicant and Authenticator to the PMK), the EK (used to encrypt the EAPoL-Key Descriptor's Key Material field during the Group Key Exchange, but it is not used in the four-way handshake that implements the pairwise key exchange), and the temporal key(s) for the ciphersuite defined in the RSN IE. The Pairwise Key Hierarchy is illustrated in Figure 7-28. Figure 7-28. The Pairwise Key Hierarchy
The complete output of the pseudo-random function (PRF) is known as the Pairwise Transient Key (PTK), of which bits 0 127 are the MK, bits 128 255 are the EK, and bits 256 383 represent temporal key number 1 (TK1). Temporal key number 2 (TK2), if present (which depends on the needs of the ciphersuite defined in the RSN IE), is found in bits 384 511. Note again that the Authenticator cannot perform the PTK derivation until it has received the SNonce from the Supplicant, since the SNonce is part of the input in the PTK derivation. In other words, the Authenticator cannot derive the EAPoL-Key MK, EAPoL-Key EK, and the Temporal Key(s) until after it has received the second message of the four-way handshake. The Authenticator and the Supplicant both derive identical temporal keys because they both compute the Pairwise Key Hierarchy using the same inputs. Because only this Supplicant and this Authenticator (and the Authentication Server) are presumed to know the PMK, no eavesdropper can learn enough information from simply observing the four-way handshake to impersonate the Supplicant or the Authenticator. The Third Message of the Four-Way HandshakeThis message is sent by the Authenticator to the Supplicant, and its most basic function is to acknowledge receipt of the second message by the Authenticator, and to direct the Supplicant to install the derived temporal key(s) in the Supplicant's STA. The Authenticator need not tell the Supplicant what those keys are…it knows that the Supplicant knows the keys. When the Supplicant receives the third message of the four-way handshake, it also knows that there is no man-in-the-middle; in other words, it knows that the Authenticator is a component of the same AP that it has associated with prior to beginning the four-way handshake. Similar to the second message, the contents of the third message are sufficient to prove to the Supplicant (in a cryptographically sound sense) that this is the case.[52] After receiving the third message, the Supplicant also knows that the Authenticator has computed the PTK. All that remains is to transition from the phase where the two parties know the keys to the phase where the two parties are using the keys.
This message contains the ANonce (again), which is the same randomly chosen value that was sent in the first message. The third message also includes the Authenticator's RSN IE (must be identical to the RSN IE that was sent in the AP's Beacons and/or Probe Responses), and a message digest computed over the third message's EAPoL-Key Descriptor by the Authenticator using the EAPoL-Key MK that has now been derived by the Authenticator. Finally, the EAPoL-Key Descriptor's "Install" bit is set for the first time in the third message of the four-way handshake. As in the second message, the Authenticator's RSN IE is transported within the EAPoL-Key Descriptor's Data field. When it is set, the EAPoL-Key Descriptor's Install bit directs the receiver to configure its local STA with the derived temporal key(s). Since the Supplicant is the receiver of the third message, it is being told to prepare to receive encrypted unicast traffic. The third message is similar to the first message, but conveys much more information, built on what has been learned through the exchange of the first and second messages. The Fourth Message of the Four-Way HandshakeAs with all other messages after the first message, the final message serves to acknowledge receipt of the previous message. This message of the four-way handshake may appear superficially similar to the second message, but its role is much more important, in that it confirms that both sides can now send encrypted unicast traffic. The fourth message implicitly tells the Authenticator that the keys are installed on the Supplicant's STA (since the fourth message acknowledges the third message), and that the Authenticator's STA (in the AP) should now install the temporal keys for this security association into its STA. The fourth message is also stating that the Supplicant has installed the temporal key(s) in its STA, as directed by the third message, and is ready to receive unicast data encrypted using the ciphersuite specified in the RSN IE. As with the second and third messages, the fourth message contains a message digest that is computed over the EAPoL-Key Descriptor using the EAPoL-Key MK. At this point in the four-way handshake, both parties have derived the temporal keys and both know the ciphersuite that has been negotiated. Therefore, (in contrast to the previous messages) the entire fourth message is encrypted using the derived unicast temporal key(s) using whatever unicast ciphersuite was defined in the RSN IE; thus, the fourth message will be encrypted using CCMP or TKIP. The fourth message is not explicitly acknowledged, but the exchange can be judged a success when bi-directional encrypted traffic begins to flow. The "Install" bit in the third and fourth messages directs the IEEE 802.1X entity in the Supplicant or the Authenticator, respectively,[53] to configure its local STA with the keying information derived from the Pairwise Key Hierarchy. By virtue of the Install bit being set in the fourth message, the Supplicant is directing the Authenticator to install the temporal keys for this security association into its STA (i.e., in the AP's STA). The IEEE 802.1X software uses the MLME-SETKEYS.request API to convey this information to either the Supplicant's or the Authenticator's STA, respectively. In the event that an Authenticator or Supplicant decides to terminate an association, the MLME-DELETEKEYS.request API is used.
What Can Go Wrong?An issue can arise when the fourth message is lost, since the third message indicated that the Authenticator's STA has had the PTK installed (and thus, all unicast traffic will be encrypted using the PTK). Therefore, if the third message needs to be re-transmitted, the frame will be encrypted using the PTK with the encapsulation depending on the rules of the selected ciphersuite. The Supplicant's STA, then, might receive an encrypted frame before it thinks it should be able to do so. There is, unfortunately, no way out of this situation (this is the "Two Armies" problem, described in detail in the context of Transport layer protocols in Dr. Andrew S. Tanenbaum's Computer Networks, 4th Edition). At some point, each STA has to be committed to sending and receiving encrypted traffic, and if something goes wrong, the only recourse would be to restart the process and derive a new PTK. If the third message is received, but the fourth message is lost in transit, there is really not any impact, since after transmitting the fourth message, the Supplicant's STA's MAC will have the PTK installed. If the fourth message does not reach the Authenticator, the Supplicant's STA must still be prepared to accept unencrypted traffic from the Authenticator (which would most probably be a re-transmission of the third message, since the Authenticator will not have received the fourth message from the Supplicant, which, among other functions, serves to acknowledge the third message from the Authenticator). Provided the fourth message has been properly received and interpreted by the Authenticator, the per-association keys are installed on the Authenticator's STA, and future unicast data is encrypted using TK1 and/or TK2, as required by the RSN IE. Once the four-way handshake is complete, the Authenticator's and Supplicant's IEEE 802.1X PAE permits unicast traffic to flow through their respective STAs, which encapsulates the packets according to the ciphersuite(s) indicated in the RSN IE. We're Not Done YetNow that the unicast Pairwise Key Hierarchy calculations have been completed, unicast traffic must be sent in encrypted form, using the derived unicast temporal key(s). However, multicast and broadcast traffic would still need to be sent in the clear, which is why there is a small additional handshake (just two further messages) in which the Authenticator transmits the Group Transient Key (GTK) to the Supplicant. Even though the IEEE 802.11i draft defines a "Group Key Hierarchy," the GTK that the Authenticator sends to its associated Supplicants is indistinguishable from a random number. Moreover, contrary to the case with the Pairwise Key Hierarchy, the Supplicant does not need to do anything to "co-compute" the GTK; each Supplicant simply receives it (securely) from the Authenticator. All the STAs in the BSS use the same GTK to decrypt the multicast and broadcast transmissions that they receive from the AP. Multicasts and broadcasts that are sent by the STAs are actually sent as unicast messages to the AP (the MAC-RA set so that the AP consumes that frame), and the MAC-DA of the frame is the desired multicast or broadcast address. The STA encrypts the unicast frame with the unicast temporal key(s) as it would any other unicast frame. When the AP receives the frame, it can tell that it is a non-unicast frame based on the address in the MAC-DA field. If the AP can successfully decrypt the frame using the unicast temporal key(s), it can then create a new output frame that is encrypted with the GTK. The Group Transient Key is derived from the Group Master Key, the Authenticator's [MAC] Address (AA), and a nonce (the GNonce, chosen by the Authenticator), as shown in Figure 7-29. Figure 7-29. The Group Key hierarchy
The difference between the GTK derivation and the PTK derivation is that the GTK is only derived inside the Authenticator, whereas the PTK is derived in parallel in both the Supplicant as well as the Authenticator. The critical issue with the group key is that all the STAs know the same group key, so that they can decrypt multicast and broadcast traffic from the AP. There is never a need for a STA to encrypt its own multicast or broadcast frames with the GTK. As noted in Figure 7-29, when TKIP is the ciphersuite indicated in the RSN IE, the PRF is set to output 256 bits of GTK, so that the GTK 2 will also be derived, which is the second 128 bits of the output of the PRF. Otherwise (i.e., in the case of CCMP), the GTK is only 128 bits long. In CCMP, the PRF's output is just 128 bits long, and those 128 bits are directly mapped into the GTK 1. Both of the EAPoL-Key messages in the Group Key Exchange are digitally signed by the MK, after the EAPoL-Key EK has been used to encrypt the Key Material field of the EAPoL-Key Descriptor, which holds the [encrypted] GTK. The Group TK1 (and possibly also TK2), are subsequently configured into the Supplicant's STA and the Authenticator's STA via the MLME-SETKEYS.request API. When this procedure is complete, the Supplicant's STA can now send encrypted broadcast and multicast traffic, in addition to the prior ability to send encrypted unicast traffic. When the Group Key exchange is complete, the Supplicant's STA can now decrypt encrypted broadcast and multicast traffic from the AP, in addition to the prior ability to encrypt and decrypt unicast traffic. The EAPoL-Key messages of the GTK exchange are encrypted using unicast key(s) derived from the PTK.
What If You Want Better Security than WEP, but You Don't Have a RADIUS Server?By separating the functions of the AP and the AS, the designers of IEEE 802.1X (and by extension, IEEE 802.11i) have enabled the system to scale up into really huge deployments. Centralizing the user credentials is the key to scalability. However, there are many users who have WLANs at home who would like to have security superior to WEP. It is highly unlikely that many users have a RADIUS server at home (unless they have a very large family!). The IEEE 802.11i draft defines a way to use a "pre-shared key" (PSK[54]) instead of a RADIUS server. (Once again, note that RADIUS is the de facto standard for the back-end user credentials database protocol, but it is not endorsed or required by the IEEE 802.11i standard, nor is it likely to be the de facto standard for this function forever. Better protocols (e.g., Diameter) are in the works, and while they are not perfect either, they offer many improvements and are likely to be supported in the not-too-distant future.) The PSK offers a way to effectively integrate the AS and Authenticator functions into the same device (the AP). In general, PSKs are not secure, but if a separate PSK is assigned on a per-STA basis, that is secure.
The PSK is a 256-bit (i.e., 16-octet) number, and is probably derived from a pass phrase. The Authenticator and Supplicant are both configured with the PSK (hence, the reason it is described as being pre-shared), and when the time comes for the four-way handshake, the Supplicant and the Authenticator both use the PSK as their PMK. The PTK is derived as usual, mixing in the ANonce and SNonce to derive fresh temporal keys to protect the session. The PMK is taken directly from the PSK since there is no end-to-end EAP method that can generate the PMK. Again, the use of PSKs is adequately secure only if the PSK is used on a per-STA basis. Sharing the same PSK among multiple STAs would have the same effect as if an attacker managed to discover the PMK for a given association. Once a PMK is known, the attacker can masquerade as either party in the association. PSKs are likely to be the preferred method of RSN usage, if the current trends of WLAN deployments at home continue. PSK usage is likely to scale up to the level of dozens of separate PSKs, before the administrative overhead of managing a large database of users and their PSKs makes a RADIUS server look like a good investment. From a usability standpoint, RSN security is likely to be far more user friendly than WEP was. It is much easier to enter a pass phrase (to generate the PSK) than it was to enter four 40-bit numbers (or one or more 104-bit numbers). It will be much easier for managers of small networks to keep track of the PSK allocations…it is likely that network management tools for APs will provide the ability to configure PSK-generating pass phrases on a per-MAC-address basis. The STA/Supplicant configuration is just absolutely simple in IBSS mode. Simply enter the SSID of the ESS within which the pass phrase is valid, and you're done. An encrypted frame may be identified by the receiver because it has a bit set in the Frame Control field indicating that it is encrypted. The bit is known as the "Protected Frame" bit in IEEE 802.11i parlance, but in IEEE 802.11-1999, it was known as the "WEP" bit. The newer nomenclature is generic enough to apply to WEP, TKIP, and CCMP, and whatever new ciphersuites are invented in the future. This one bit is sufficient to indicate the presence of the IV field (between the MPDU header and the MPDU payload). Those frames encrypted with either TKIP or CCMP have an additional "Extended IV" bit, just prior to the Key ID field in the IV header. However, beyond this point, there is nothing in the frame to distinguish between TKIP and CCMP…the receiver must look up the MAC-SA of the frame in its table of security associations and see what type of encryption was negotiated with that peer. This lookup has virtually zero cost, since the receiver already would have had to look up the MAC-SA in its table of security associations in order to retrieve the appropriate keying material with which to decrypt the frame. Given that RSN encryption and decryption will probably be implemented in hardware,[55] this "extra" lookup (i.e., to determine which encryption protocol was used to encrypt the frame) will have no performance impact at all.
RSN CiphersuitesAt the moment, the draft IEEE 802.11i specification describes two ciphersuites, namely TKIP (an RC4-based encryption algorithm) and CCMP (an AES-based encryption algorithm). The two algorithms have advantages and disadvantages, but their operation is driven by the key management protocols that have already been described. Without a source of secure keys, it does not matter how good your encryption algorithm is. Temporal Key Integrity ProtocolBy some accounts, the Temporal Key Integrity Protocol (TKIP) is the perfect protocol, since no one is happy with it. The purpose of TKIP is to provide a wrapper around WEP, so that hardware that supports WEP could be upgraded to have better security than WEP, which is effectively the same as no security. TKIP can be added as a software layer that pre-processes MSDUs such that the WEP hardware can do a halfway effective job of providing some level of security. TKIP provides a greatly expanded IV space, as well as a cryptographically almost-strong-enough Message Integrity Code (MIC), called Michael (cute, huh?). Michael is actually quite weak. The MIC had to be designed to be implementable on computationally bound older hardware (which typically has few CPU cycles lying around unused), which meant that it could not be very strong. The designer of Michael was able to find a compromise that works (or doesn't, depending on your point of view) under very constrained circumstances. Michael protects the MSDU plus the MAC-SA and MAC-DA addresses that get passed down via LLC's MA-UNITDATA.request API, as well as the rest of the frame's contents, from the LLC header onward. Because it protects the MSDU, Michael can be implemented in software, independent of the underlying WEP hardware. The MA-UNITDATA.request LLC primitive is the means by which the LLC entity within a STA requests that a MAC sublayer entity transfer an MSDU from the local LLC sublayer entity to a single peer LLC sublayer entity. If the destination address parameter indicates a multicast or broadcast address, then the MSDU is intended for multiple peer LLC sublayer entities. The parameters of the MA-UNITDATA.request primitive are as follows:
Michael has been estimated to have a cryptographic strength on the order of 2 20. This means that if an attacker modified a frame and modified the ICV, the attacker would have an approximately million-to-one shot at getting the ICV correct, just by guessing. Given the weakness of Michael, TKIP has certain "countermeasures" built into it. As the countermeasures are currently defined (in draft 3.2 of the IEEE 802.11i specification), attackers cannot be allowed to repeatedly send modified frames until they find one that works. If TKIP detects that it is under attack which is defined as two MIC failures in any 60-second period it will shut down the WLAN for 60 seconds, and then re-key everyone. This limits the rate at which an attacker can forge frames. The reason why the WEP ICV is not changed is that the expectation is that the WEP support is in hardware, and the opportunity for a software or firmware upgrade means that the WEP hardware is a given. If an end user is replacing his or her hardware platform, that user is probably going to want to get one with more serious encryption, such as CCMP, which is based on a mode of the Advanced Encryption Standard (AES). The RC4 encryption that is ultimately applied to the frame protects the entire payload of the MPDU, including the eight-octet Michael MIC (that protects the MSDU) has been appended to the MSDU, and the four-octet WEP ICV that is computed exactly as it was in legacy WEP…it is still a CRC-32 over the MSDU (however, in this case, the WEP ICV sees the TKIP MIC as part of the MSDU). Figure 7-30 shows the construction of a TKIP-enhanced WEP frame. Note that TKIP adds four additional octets to what is now the Extended IV field, and the Michael MIC adds an additional eight octets over and above the WEP ICV. Thus, the available MPDU payload for TKIP is, at best, 2292 octets (WEP was 2304, and TKIP takes away 12 additional octets from the available MPDU payload). Figure 7-30. Encapsulation of an MSDU using TKIP
It is trivial to modify a set of bits in a WEP-protected MPDU such that the WEP ICV will not be able to detect the change, but the Michael MIC is stronger, and it will detect the change. However, Michael is not invulnerable, and it is still important to protect the BSS from active attackers; hence the countermeasures. If a TKIP device detects a Michael failure, it will start a clock, and if there is a second Michael failure within 60 seconds, then the BSS shuts itself down to limit the damage that an attacker can do. TKIP was designed as a "wrapper" for WEP, to enhance it so that it was not so easily breakable. TKIP extended the size of the initialization vector, and provided an extra MIC (Michael) to protect the MSDU, as can be seen in Figure 7-31. There is some debate within the IEEE 802.11 TGi community regarding TKIP's "countermeasures"; in other words, whether they are too draconian. The Michael MIC was designed to be "just strong enough" to give an acceptable level of security given the expected low-end platforms on which it would be deployed, and the countermeasures were designed to limit the rate of attack to an acceptable level, given the generally accepted strength of Michael. Figure 7-31. CCMP encapsulation of MPDUs
The countermeasures are designed to keep TKIP from being undermined by a clever attacker. If there are two MIC failures in a "short enough" period of time, the AP will shut the BSS down, temporarily, to limit the rate at which it can be attacked. To quote the IEEE 802.11i (draft 5.0):
Much has been made of the fact that the countermeasures are effectively a built-in DoS attack against TKIP, since two packets in a one-minute period can shut down the BSS for a minute or more. It would be difficult to track down the source of an attacker who was sending malformed frames at a rate slow enough to trigger the countermeasures. Such an attacker may not even care about breaking in to the BSS. This would be a purely DoS-style attack. This is a genuinely good point, but if the alternative is having weaker countermeasures, and thinking you are more secure than you actually are, and not being able to detect an attack when it happens, which would you choose? The issue boils down to this question: How strong is Michael? If it is stronger than generally accepted, as some have suggested, then shutting down a WLAN for 60 seconds seems to be erring on the side of caution in an overly aggressive manner. Efforts are under way to quantify the strength of Michael, so that the countermeasures can be tuned to a level that is commensurate with the threat. Some have suggested that Michael is strong enough that the countermeasures will only need to shut the BSS down for on the order of one second, or even less. If Michael is stronger than had been presumed and the countermeasures can be tuned to the actual strength of Michael, such that they would be less of a penalty to the BSS, everyone would be happy. However, the important thing is that TKIP should actually offer some enhanced level of security, and if the countermeasures need to be draconian to do that, then that's what needs to be in the standard. If end users want high security and they do not want to deal with the TKIP countermeasures (that only exist to bolster the presumably weak Michael MIC), then they should be investing in products that support stronger encryption and message integrity check algorithms, specifically products based on CCMP. AES Counter Mode with CBC-MAC (CCM) Protocol (CCMP)TKIP is limited by the fact that it is designed to be a firmware or software upgrade to a device that did, and will, support WEP in hardware. The IEEE 802.11i group has defined an AES-based algorithm that offers considerably more strength, but in order to implement CCMP in a real BSS, a customer needs STAs and APs that support AES, and that means hardware upgrades. The author contends that anyone who wants a secure WLAN will be willing to pay the small incremental cost to have AES-enabled devices, especially since catering to the installed base is overlooking the large pool of people who would love to invest in WLAN technology but who have been waiting for (and will be willing to pay a slight premium for) seriously strong security. CCMP operates at the MPDU level, as depicted in Figure 7-31, and incurs a four-octet smaller penalty than TKIP against the MPDU payload since the baggage of the WEP ICV is no longer required. Figure 7-31 looks really complicated, but it really isn't as bad as it may appear. The first two rows of the diagram are the expansion of the Extended Initialization Vector (Ext. IV) field of the CCMP-protected MPDU, which is depicted on the third and fourth rows of the diagram. The third row shows the ultimate structure of the CCMP-protected MPDU, whereas the fourth row gives the details of the MPDU header that are used to build the "Additional Authenticated Data" that drives the AES CBC-MAC calculation (CCMP's Message Integrity Check). The AAD field is comprised of parts of the MPDU header, but the FC and SC fields must be transformed before computing the MIC. Only certain of the fields of the MPDU header need to be included in the MIC calculation. The QC header, if present, is also transformed and is included in the AAD so that it is protected by the MIC. Finally, all the pieces come together, as shown in Figure 7-32. Figure 7-32. Construction of CCMP-protected MPDU
CCMP, as it is based on AES, is efficient to implement in software, provided adequate CPU horsepower is available. For example, a PC running Windows should be able to implement CCMP in software, since it is running on a CPU that is 2+ GHz. CCMP is also efficient in hardware, and as enhanced security products start coming to market, providing AES will be a significant value-add, we can expect to see AES emerging as a standard feature in new hardware over the next 18 months or so. Wi-Fi Protected AccessTo get more-secure products to market in a timely fashion, the Wi-Fi Alliance decided to take excerpts of the IEEE 802.11i draft 3.0 specification and create Wi-Fi Protected Access (WPA). WPA-logoed products will start appearing in late 2003. There are some who question the wisdom of basing products on a draft of a standard that is still very much in flux, but the vendors in the Wi-Fi Alliance seem to think that is a risk worth taking (i.e., the risk is that the WPA spec will be rooted in the past, based on IEEE 802.11i-draft 3.0, while the IEEE 802.11i group will move forward and possibly diverge from the feature set of WPA). In practice, now that WPA exists, TGi is very sensitive about touching any part of their draft that might have implications on WPA. WPA is a simple idea, really. Take the parts of IEEE 802.11i that seem fairly solid and build products based on those parts while the IEEE is finishing the rest of the document. The pieces that WPA has selected are the TKIP ciphersuite (which is optional in IEEE 802.11i, but mandatory in WPA) and the IEEE 802.1X-based authentication and key management (i.e., the four-way handshake and such). WPA even supports CCMP as an option (the IEEE 802.11i draft mandates CCMP for devices claiming to support RSN, but requiring CCMP in WPA was a non-starter, since that would have required hardware upgrades). It is the author's opinion that WPA will become the public face of RSN. It is unlikely that terms like RSN and IEEE 802.1X will be exposed in the market place, since the level of user education necessary would be too great. A WPA logo is a nice simple way to get the message across, without the user needing to know too much. At least it simplifies the purchasing decision. Installing WPA and getting it configured securely will probably be a challenge. There will be phases of deployment. Early products will use IEEE 802.1X for the four-way handshake, but may not be tied into a RADIUS infrastructure, which will mean that APs will need to support some kind of user interface for entering a per-STA "pass phrase" which is converted to a pre-shared key. The integration of RADIUS or Diameter as a back-end protocol will ease this management burden, but there will undoubtedly be deployment issues with getting the EAP exchanges and the Authenticator-to-Authentication_Server secure channels working properly. These types of issues will mainly occur when the new hardware and software system is being brought up to speed, and should cease to be issues once everything is installed and configured properly. The author does not mean to imply that getting real security (whether you call it WPA or RSN is irrelevant) to work on a WLAN will be too difficult…once it is up and running, it will be far more usable than WEP (from an end-user's perspective). From a network manager's perspective, the ability to have per-association keys that are securely exchanged to drive modern encryption protocols is certainly worth some effort to get working. There are likely to be two key deployment scenarios…home and corporate. In the home, managing per-STA pass-phrases won't be a big deal. It's unlikely that there will be many homes with RADIUS infrastructures, so the pre-shared key approach will be important to support. In corporate settings that already have RADIUS infrastructures, it should not be too difficult to integrate EAP and IEEE 802.1X into the mix. The corporate deployments will probably benefit from much more sophisticated management and configuration tools to aid deployment and troubleshooting. Another deployment scenario has the flavor of corporate, and is the potential for wireless ISPs (WISPs), which might provide secure access (for a price). These WISPs are likely to have access to all the necessary back-end software databases and systems to enable such services, even more readily than a corporation, which may need to install a RADIUS server to support user-based authentication for their WLAN. For a WISP (or ISP), user-based authentication is what their business depends on. If they don't have that, they can't do billing…. In a WISP scenario, users of various ISPs might be separated onto different VLANs, at least so that the unencrypted users (which will hopefully be on a declining trend) won't be able to interfere with the secure subnetworks that are overlaid in the same space, be it a coffee shop, a bookstore, or an airport lounge. By 2005, the default for wireless devices, as far as security is concerned, should be the opposite of what it is today. By then, the default will probably be secure mode. |
EAN: 2147483647
Pages: 60