1 00:00:04,700 --> 00:00:09,180 Hello and welcome to this video titled WPA protected management frames 2 00:00:09,180 --> 00:00:11,320 also called PMF. 3 00:00:11,320 --> 00:00:17,320 So begin with it's a good idea just for us to quickly review the different 4 00:00:17,320 --> 00:00:20,040 types of 802.11 frame types. 5 00:00:20,040 --> 00:00:24,020 So we know that 802.11 defines three types of Wi-Fi frames. 6 00:00:24,020 --> 00:00:27,320 You've got your data, which is what most of the frames are when you're 7 00:00:27,320 --> 00:00:30,480 doing your town netting and your web browsing and everything else. 8 00:00:30,480 --> 00:00:34,260 You've got specific frames called control frames such as clear to send 9 00:00:34,260 --> 00:00:36,000 and ready to send. 10 00:00:36,000 --> 00:00:38,100 And then you've got a variety of management frames. 11 00:00:38,100 --> 00:00:41,740 Now within the management frames section, which is what we're really focused 12 00:00:41,740 --> 00:00:47,100 on here, we've got things like beacons, your probe requests and probe 13 00:00:47,100 --> 00:00:52,200 responses, authentication, association frames, action frames. 14 00:00:52,200 --> 00:00:54,820 So those are considered management frames. 15 00:00:54,820 --> 00:01:01,560 Now, when we think about those management frames, we do have some vulnerability. 16 00:01:01,560 --> 00:01:04,040 Now let's think about first of all, what are these management frames really 17 00:01:04,040 --> 00:01:07,820 used for? They're used to initiate and tear down sessions for network 18 00:01:07,820 --> 00:01:13,660 services. They also give wireless LAN clients a lot of information about 19 00:01:13,660 --> 00:01:18,060 the BSS, what its capabilities are, what it can do. 20 00:01:18,060 --> 00:01:21,960 It can also tell the clients who are currently associated to the BSS to 21 00:01:21,960 --> 00:01:24,760 take some action or to do something. 22 00:01:24,760 --> 00:01:29,640 Now, if those management frames are spoofed, for example, if a rogue access 23 00:01:29,640 --> 00:01:35,260 point starts advertising its own beacons and it makes itself look exactly 24 00:01:35,260 --> 00:01:40,560 like your legitimate access point, and we call this an evil twin and starts 25 00:01:40,560 --> 00:01:44,720 spoofing those management frames, it can tell the clients to do things 26 00:01:44,720 --> 00:01:49,360 which can result in denial of service, luring the clients to actually 27 00:01:49,360 --> 00:01:53,600 associate to the evil twin access points to the real access point, slowing 28 00:01:53,600 --> 00:01:56,560 down wifi traffic and all sorts of things. 29 00:01:56,560 --> 00:01:58,600 For example, here's an evil twin. 30 00:01:58,600 --> 00:02:02,940 It has been monitoring the beacons so we know what the BSSID, the MAC 31 00:02:02,940 --> 00:02:05,340 addresses of the legitimate access point. 32 00:02:05,340 --> 00:02:10,180 So using some various methods, we can make our evil twin simulate that 33 00:02:10,180 --> 00:02:14,180 exact same MAC address and that exact same SSID. 34 00:02:14,180 --> 00:02:18,420 And so one common attack is a D authentication attack where it now just 35 00:02:18,420 --> 00:02:22,500 sends a deauthentication message to that client saying, I need to kick 36 00:02:22,500 --> 00:02:25,960 you off so the client then becomes deassociated. 37 00:02:25,960 --> 00:02:29,420 It leaves the wireless land just for like a second. 38 00:02:29,420 --> 00:02:34,240 And then if the next beacon that it hears is coming from that particular 39 00:02:34,240 --> 00:02:39,500 access point, it might end up associating to the evil twin. 40 00:02:39,500 --> 00:02:42,280 And now it could send its information to the evil twin instead of the 41 00:02:42,280 --> 00:02:46,000 rogue access, instead of the real access point. 42 00:02:46,000 --> 00:02:50,220 Now, think about these management frames are is that when we get into 43 00:02:50,220 --> 00:02:52,840 protected management frames, I'm going to talk about that in a moment, 44 00:02:52,840 --> 00:02:55,420 we're not talking about encrypting them. 45 00:02:55,420 --> 00:02:57,760 You can't encrypt management traffic. 46 00:02:57,760 --> 00:03:02,760 And the reason why is because management frames are designed to be heard 47 00:03:02,760 --> 00:03:07,520 and understood by all clients, even clients that haven't associated to 48 00:03:07,520 --> 00:03:11,780 the BSS yet. After all, if you're doing roaming, you need to be able to 49 00:03:11,780 --> 00:03:16,540 see in plain text, for example, the beacons and the probe responses. 50 00:03:16,540 --> 00:03:19,800 So you can decide if you really want to roam to that wireless land or 51 00:03:19,800 --> 00:03:22,880 not. So we can't encrypt them. 52 00:03:22,880 --> 00:03:26,900 But what we can do is protect them in other ways. 53 00:03:26,900 --> 00:03:28,940 So let's talk about that. 54 00:03:28,940 --> 00:03:35,980 So 802.11w was actually the first IEEE specification in which protected 55 00:03:35,980 --> 00:03:39,220 management frames were first introduced. 56 00:03:39,220 --> 00:03:42,440 And management frames, when we think about them, like the list I just 57 00:03:42,440 --> 00:03:45,960 gave you, at a high level, we can categorize management frames into two 58 00:03:45,960 --> 00:03:50,400 types. There are those that are sent prior to the EAP over land handshake, 59 00:03:50,400 --> 00:03:55,180 such as probe responses, probe requests, beacons, and there are those 60 00:03:55,180 --> 00:03:57,480 that are sent after. 61 00:03:57,480 --> 00:04:03,260 So protected management frames, 802 .11w specified some of the management 62 00:04:03,260 --> 00:04:08,940 frames as being the special class or category called robust management 63 00:04:08,940 --> 00:04:15,300 frames. And these are what we can protect via protected management frames. 64 00:04:15,300 --> 00:04:19,280 Now, robust management frames, by definition, are those management frames 65 00:04:19,280 --> 00:04:23,900 are used after a client has gone through its EAP over land handshake. 66 00:04:23,900 --> 00:04:27,420 So what frames are we talking about? 67 00:04:27,420 --> 00:04:33,420 So robust management frames include disassociation, deauthentication, 68 00:04:33,420 --> 00:04:34,960 robust action frames. 69 00:04:34,960 --> 00:04:36,260 So those three right there. 70 00:04:36,260 --> 00:04:41,000 Now robust action frames, there's a lot of frame types that fall into 71 00:04:41,000 --> 00:04:46,040 this category of robust action frames, such as spectrum management, channel 72 00:04:46,040 --> 00:04:49,400 switch announcements, where the access point might say, oh, I've just 73 00:04:49,400 --> 00:04:50,660 detected some radar. 74 00:04:50,660 --> 00:04:54,400 We need to leave this channel and move over to channel 157 instead or 75 00:04:54,400 --> 00:04:55,380 something like that. 76 00:04:55,380 --> 00:04:58,180 That would be considered a channel switch announcement. 77 00:04:58,180 --> 00:05:04,860 QOS frames, block acknowledgments, fast BSS transition when you're doing 78 00:05:04,860 --> 00:05:07,800 fast roaming, and others. 79 00:05:07,800 --> 00:05:14,700 Now, there are a variety of ways that these frames could be misused by 80 00:05:14,700 --> 00:05:18,920 malicious hackers if they were able to spoof them and get your client 81 00:05:18,920 --> 00:05:22,240 to believe their spoofed management frame. 82 00:05:22,240 --> 00:05:25,940 For example, look at that second one there, the channel switch announcement. 83 00:05:25,940 --> 00:05:30,940 What if a rogue access point pretending to be the legitimate access point, 84 00:05:30,940 --> 00:05:35,800 let's say you're currently associated on channel one of a 2.4 gigahertz 85 00:05:35,800 --> 00:05:38,460 wireless LAN, and all of a sudden you get a channel switch announcement 86 00:05:38,460 --> 00:05:41,260 saying, hey, everybody needs to switch to channel 11. 87 00:05:41,260 --> 00:05:46,700 Well, if you follow that, you might be switching on to a channel that 88 00:05:46,700 --> 00:05:50,060 is actually in charge of by the rogue access point. 89 00:05:50,060 --> 00:05:51,820 And now you're really in trouble. 90 00:05:51,820 --> 00:05:55,760 And that's just one way that these frames could be spoofed and used for 91 00:05:55,760 --> 00:05:58,180 nefarious purposes. 92 00:05:58,180 --> 00:06:04,960 So let's talk about how PMF actually applies to protect these management 93 00:06:04,960 --> 00:06:09,420 frames. Since we can't encrypt them, what can we do? 94 00:06:09,420 --> 00:06:13,180 So PMF allows the addition of a cryptographic signature. 95 00:06:13,180 --> 00:06:15,900 So whenever you see that word signature, a little bell should go off in 96 00:06:15,900 --> 00:06:18,880 your head, bing, bing, bing, bing, bing, a signature means we're talking 97 00:06:18,880 --> 00:06:21,300 about a message integrity code. 98 00:06:21,300 --> 00:06:25,100 We're talking about protecting the integrity of the data so that when 99 00:06:25,100 --> 00:06:29,880 you receive it, you know the the bits haven't been changed in transit. 100 00:06:29,880 --> 00:06:32,660 And you know it's come from a legitimate source. 101 00:06:32,660 --> 00:06:34,160 That's what we're talking about. 102 00:06:34,160 --> 00:06:35,520 So that's what PMF does. 103 00:06:35,520 --> 00:06:41,580 It adds a message integrity code to these robust management frame types 104 00:06:41,580 --> 00:06:42,980 that we just talked about. 105 00:06:42,980 --> 00:06:47,460 So the mick actually allows the receiver, which is typically the client, 106 00:06:47,460 --> 00:06:48,880 to verify a bunch of things. 107 00:06:48,880 --> 00:06:51,760 Number one, it verifies that the frame hasn't been tampered with in transit. 108 00:06:51,760 --> 00:06:53,820 In other words, the bits haven't been modified. 109 00:06:53,820 --> 00:06:57,980 And more importantly, it allows the receiver to verify that this really 110 00:06:57,980 --> 00:07:01,720 came from my access point, my legitimate access point that I'm associated 111 00:07:01,720 --> 00:07:05,960 with, not some rogue access point that's trying to spoof my legitimate 112 00:07:05,960 --> 00:07:11,000 access point. So the frames that come from the access point, those robust 113 00:07:11,000 --> 00:07:14,340 management frames, some of them are unicast. 114 00:07:14,340 --> 00:07:18,500 For example, if the access point sends you a disassociation or deauthentication 115 00:07:18,500 --> 00:07:22,160 message or something, that's from the access point to you as a specific 116 00:07:22,160 --> 00:07:26,400 client. So to create the mick for those, we're just going to use the client's 117 00:07:26,400 --> 00:07:27,840 key confirmation key. 118 00:07:27,840 --> 00:07:30,800 Remember, when the client first associated went through the EPU overland 119 00:07:30,800 --> 00:07:34,320 handshake, it created a pairwise transient key. 120 00:07:34,320 --> 00:07:38,840 And then part of that pairwise transient key was sort of redefined as 121 00:07:38,840 --> 00:07:43,080 a key confirmation key, specifically for the purpose of creating these 122 00:07:43,080 --> 00:07:45,040 message integrity codes. 123 00:07:45,040 --> 00:07:46,060 That's what it's for. 124 00:07:46,060 --> 00:07:51,100 So that same key confirmation key can be used to create mix for these 125 00:07:51,100 --> 00:07:54,420 unicast, robust management frames. 126 00:07:54,420 --> 00:07:59,220 Now, sometimes the access point will send a robust management frame that 127 00:07:59,220 --> 00:08:03,180 is a broadcast that's spent for all the clients in the wireless LAN. 128 00:08:03,180 --> 00:08:07,500 And you can't use any one client's key confirmation key to create mix 129 00:08:07,500 --> 00:08:12,440 for those. In that case, the access point actually has its own special 130 00:08:12,440 --> 00:08:18,580 key called the integrity group temporal key that it uses to create and 131 00:08:18,580 --> 00:08:20,360 apply mix to those. 132 00:08:20,360 --> 00:08:23,560 And we'll talk about that more in just a moment. 133 00:08:23,560 --> 00:08:25,580 So here's a comparison. 134 00:08:25,580 --> 00:08:29,460 You can see on the sniffer trace on the top, this is a management frame. 135 00:08:29,460 --> 00:08:30,760 It's a deauthentication. 136 00:08:30,760 --> 00:08:33,480 So this would be considered a robust management frame, but there's no 137 00:08:33,480 --> 00:08:34,640 protection here. 138 00:08:34,640 --> 00:08:38,600 No indication whatsoever of any integrity protection via a mick or anything 139 00:08:38,600 --> 00:08:43,620 else. Whereas down below, if we see a deauthentication frame here, we 140 00:08:43,620 --> 00:08:46,680 can actually see it says data and it's got some data in it. 141 00:08:46,680 --> 00:08:52,240 And this, this actually is the mick that was added via protected management 142 00:08:52,240 --> 00:08:56,060 frame. Now, if we actually open this up a little bit more, we see even 143 00:08:56,060 --> 00:09:01,100 more information and more confirmation that this has been protected via 144 00:09:01,100 --> 00:09:03,840 PMF. And that's what we see right here. 145 00:09:03,840 --> 00:09:06,420 So if we open it up even more, first of all, we can see under the flags 146 00:09:06,420 --> 00:09:09,740 field, there is a flag called the protected flag. 147 00:09:09,740 --> 00:09:13,880 And if it's set to one, like it is here, it says this data is protected. 148 00:09:13,880 --> 00:09:17,440 So right there, that's your confirmation that PMF is in you. 149 00:09:17,440 --> 00:09:19,140 Now, a few more things down here. 150 00:09:19,140 --> 00:09:22,180 We already know that the data on the bottom here is the mick. 151 00:09:22,180 --> 00:09:24,200 That's the message integrity code. 152 00:09:24,200 --> 00:09:26,060 What about the CCNP parameters? 153 00:09:26,060 --> 00:09:28,260 What's that? Okay. 154 00:09:28,260 --> 00:09:34,800 So this is a unicast robust management frame, unicast from the access 155 00:09:34,800 --> 00:09:36,820 point to the client, right? 156 00:09:36,820 --> 00:09:38,900 From the Cisco access point to the client. 157 00:09:38,900 --> 00:09:45,760 As such, the CCNP protocol, now, normally when we think of CCNP, we think 158 00:09:45,760 --> 00:09:50,960 out as a formula or an algorithm for figuring out how to encrypt data 159 00:09:50,960 --> 00:09:53,120 and how to decrypt data. 160 00:09:53,120 --> 00:09:57,100 But CCNP, if you look at the spec for it, it also has a part in there 161 00:09:57,100 --> 00:10:01,720 about how do we create and apply message integrity codes. 162 00:10:01,720 --> 00:10:03,980 So CCNP does both. 163 00:10:03,980 --> 00:10:09,040 So in this particular case, we're just using the message integrity code 164 00:10:09,040 --> 00:10:14,120 part of CCNP. So this is saying CCNP was used to create the message integrity 165 00:10:14,120 --> 00:10:19,500 integrity code. And so it's saying, first of all, the key index being 166 00:10:19,500 --> 00:10:26,200 zero, what that's talking about is sometimes the, there can be a change 167 00:10:26,200 --> 00:10:31,460 in a key. And if there's a moment where the key is being rotated or changed, 168 00:10:31,460 --> 00:10:35,960 there might be at a certain moment in time more than one key that's possible. 169 00:10:35,960 --> 00:10:39,860 So the key index would give you indication about is that the older key 170 00:10:39,860 --> 00:10:44,180 we're using, like key zero, or we now protecting this with a newer key, 171 00:10:44,180 --> 00:10:48,460 like key one. Now, in the case of unicast frames, this would always be 172 00:10:48,460 --> 00:10:54,360 zero. This key index is going to be more applicable when we look at protecting 173 00:10:54,360 --> 00:10:58,160 broadcast frames, like a channel switch announcement or something like 174 00:10:58,160 --> 00:11:03,240 that. Because in that particular case, the access point could rotate its 175 00:11:03,240 --> 00:11:07,100 keys for protecting broadcast and multicast traffic. 176 00:11:07,100 --> 00:11:11,480 Not really going to see that though with unicast traffic. 177 00:11:11,480 --> 00:11:16,340 But the CCNP extension, the initialization vector, this is also kind of 178 00:11:16,340 --> 00:11:19,440 interesting. This is used to prevent replay. 179 00:11:19,440 --> 00:11:21,820 This is called an anti replay protection. 180 00:11:21,820 --> 00:11:26,140 You see, every time one of these frames goes out, these, these protected 181 00:11:26,140 --> 00:11:30,520 management frames is protected with PMF, this is like a counter. 182 00:11:30,520 --> 00:11:32,540 Notice how it says eight here at the end. 183 00:11:32,540 --> 00:11:34,480 So this, and this is coming from the access point. 184 00:11:34,480 --> 00:11:38,920 That means this is the eighth protected management frame. 185 00:11:38,920 --> 00:11:43,820 This access point has sent to this particular client during the duration 186 00:11:43,820 --> 00:11:45,540 of this association. 187 00:11:45,540 --> 00:11:49,480 And if he has any more to send, it will keep increasing. 188 00:11:49,480 --> 00:11:53,900 So how this could be used is if this client suddenly received a protected 189 00:11:53,900 --> 00:11:58,100 management frame that looked like it was coming from this access point, 190 00:11:58,100 --> 00:12:02,240 but let's say the initialization vector was the number seven or six at 191 00:12:02,240 --> 00:12:05,620 the end, the client would say, that's not valid. 192 00:12:05,620 --> 00:12:10,460 These numbers should only be increasing, not staying the same or decreasing. 193 00:12:10,460 --> 00:12:13,480 So that would be a potential replay attack. 194 00:12:13,480 --> 00:12:15,340 And so the client would just delete that. 195 00:12:15,340 --> 00:12:17,320 It would just ignore it. 196 00:12:17,320 --> 00:12:18,640 So that's how we're doing it here. 197 00:12:18,640 --> 00:12:21,240 So protected management frames are not only adding the message integrity 198 00:12:21,240 --> 00:12:25,460 code to verify that the frame came from a legitimate sender. 199 00:12:25,460 --> 00:12:31,100 It's also protecting against replay. 200 00:12:31,100 --> 00:12:35,040 And this shows you here in a beacon that's been caught. 201 00:12:35,040 --> 00:12:38,780 And within the beacon, it will actually advertise from the access point, 202 00:12:38,780 --> 00:12:43,960 if PMF is in use or not on the wireless LAN, you can see there's a couple 203 00:12:43,960 --> 00:12:46,560 of flags for it here. 204 00:12:46,560 --> 00:12:49,680 And this is because when you actually go into your, for example, your 205 00:12:49,680 --> 00:12:53,540 wireless LAN controller, and you're under the configurate or, you know, 206 00:12:53,540 --> 00:12:59,500 the edit wireless LAN setting, you'll see that for WPA3, first of all, 207 00:12:59,500 --> 00:13:03,380 WPA2, let me go back here. 208 00:13:03,380 --> 00:13:06,740 So protected management frames, and we're going to see this coming up 209 00:13:06,740 --> 00:13:10,280 in just a second, are optional for WPA2. 210 00:13:10,280 --> 00:13:11,900 You can have them or not have them. 211 00:13:11,900 --> 00:13:15,380 They are required for WPA3. 212 00:13:15,380 --> 00:13:18,720 And so that'll probably skip me right past that slide when I get to it. 213 00:13:18,720 --> 00:13:22,300 So if, and so that's what these flags are for. 214 00:13:22,300 --> 00:13:27,480 So in a WPA3 wireless LAN, we would expect both of these to be turned 215 00:13:27,480 --> 00:13:33,020 on. Not only is management frame protection capable, that's true, but 216 00:13:33,020 --> 00:13:35,400 management frame protection is required. 217 00:13:35,400 --> 00:13:36,580 That's also true. 218 00:13:36,580 --> 00:13:38,520 So it's capable and required. 219 00:13:38,520 --> 00:13:44,040 Whereas if we were seeing this beacon from a WPA2 wireless LAN, where 220 00:13:44,040 --> 00:13:47,840 you had set the management frame protection to optional, then you would 221 00:13:47,840 --> 00:13:51,900 see protection capable being true, but you would see protection required 222 00:13:51,900 --> 00:13:57,480 being false. But either way, if you see either one of these bits set, 223 00:13:57,480 --> 00:14:03,400 that means we can use protected management frames on this wireless LAN. 224 00:14:03,400 --> 00:14:09,360 All right. So you might, you might have noticed in some previous sniffer 225 00:14:09,360 --> 00:14:13,180 traces I had that there was some mention of in the robust security network, 226 00:14:13,180 --> 00:14:16,140 an element of the beacons. 227 00:14:16,140 --> 00:14:17,920 There was something called BIP. 228 00:14:17,920 --> 00:14:23,040 What is BIP? We've been talking about how some robust management frames 229 00:14:23,040 --> 00:14:25,960 are sent as broadcasts or multicasts. 230 00:14:25,960 --> 00:14:28,680 For example, a multicast deauthentication. 231 00:14:28,680 --> 00:14:31,920 If the access point is saying, I need to kick everybody off right now, 232 00:14:31,920 --> 00:14:37,780 or a channel switch announcement, or some group addressed action frames. 233 00:14:37,780 --> 00:14:42,020 Now, if we want to use protected management frames against those, we can't 234 00:14:42,020 --> 00:14:48,400 create the MIC using any particular client's temporal key, because only 235 00:14:48,400 --> 00:14:50,680 that client will be able to validate it. 236 00:14:50,680 --> 00:14:52,680 Other clients will not. 237 00:14:52,680 --> 00:14:58,980 So instead, there's something called the broadcast, multicast integrity 238 00:14:58,980 --> 00:15:00,820 protocol that's used. 239 00:15:00,820 --> 00:15:02,480 And that's what BIP is. 240 00:15:02,480 --> 00:15:04,520 And we've started playing around with this already. 241 00:15:04,520 --> 00:15:05,560 We talked about a little bit. 242 00:15:05,560 --> 00:15:11,940 So in 802.11w, remember that's the protected management frame specification. 243 00:15:11,940 --> 00:15:16,860 It introduced a new key for use with this broadcast, multicast integrity 244 00:15:16,860 --> 00:15:21,380 protocol, which is called the integrity group temporal key. 245 00:15:21,380 --> 00:15:24,940 It is the access points job to derive this. 246 00:15:24,940 --> 00:15:29,720 So remember that the access point when it boots up is going to come up 247 00:15:29,720 --> 00:15:32,740 with a group master key, a GMK. 248 00:15:32,740 --> 00:15:38,380 And then from that, it's going to derive a group temporal key for encrypting 249 00:15:38,380 --> 00:15:40,960 broadcast and multicast data. 250 00:15:40,960 --> 00:15:46,680 It's also going to derive this and the integrity group temporal key in 251 00:15:46,680 --> 00:15:52,060 IGTK. And just like the GTK, the group temporal key is given to clients 252 00:15:52,060 --> 00:16:02,080 in message three of the reason why we had to come up with this is because 253 00:16:02,080 --> 00:16:07,820 CCMP or GCMP, depending on which one you use, we talked about how those 254 00:16:07,820 --> 00:16:12,660 algorithms have a section devoted towards how do we encrypt and decrypt 255 00:16:12,660 --> 00:16:16,400 data. And then they also have another section in those protocols about 256 00:16:16,400 --> 00:16:20,240 how do we create message integrity codes and how do we validate them? 257 00:16:20,240 --> 00:16:24,280 Well, the message integrity code section, actually, all of that is for 258 00:16:24,280 --> 00:16:30,340 unicast stuff. So CCMP and GCMP were designed to do all of their security 259 00:16:30,340 --> 00:16:35,360 on unicast. They really can't deal with broadcast and multicast. 260 00:16:35,360 --> 00:16:38,360 And that is why BIP was created. 261 00:16:38,360 --> 00:16:40,020 And BIP had to create its own key. 262 00:16:40,020 --> 00:16:43,460 And that's why they developed the IGTK for BIP. 263 00:16:43,460 --> 00:16:46,520 And that's what creates the message integrity code. 264 00:16:46,520 --> 00:16:50,040 So we can see right here in message number three, that's when it's going 265 00:16:50,040 --> 00:16:53,900 to go out. So just a few final thoughts. 266 00:16:53,900 --> 00:16:59,620 In PMF protected management frames, once again, for unicast robust management 267 00:16:59,620 --> 00:17:03,740 frames, the MIC is created by taking the client's individual temporal 268 00:17:03,740 --> 00:17:09,980 key, running it through the CCMP or GCMP algorithm and outspits a message 269 00:17:09,980 --> 00:17:14,780 integrity code for that particular frame, that Wi-Fi frame. 270 00:17:14,780 --> 00:17:21,340 For broadcast or multicast frames, we take the IGTK, apply it with BIP 271 00:17:21,340 --> 00:17:22,800 against the data. 272 00:17:22,800 --> 00:17:25,900 And that creates a MIC for the broadcast frame. 273 00:17:25,900 --> 00:17:29,040 As I mentioned, WPA2 was first offered. 274 00:17:29,040 --> 00:17:31,300 PMF is an optional service. 275 00:17:31,300 --> 00:17:34,840 WPA3 requires protected management frames. 276 00:17:34,840 --> 00:17:37,200 And you can see a screenshot right here. 277 00:17:37,200 --> 00:17:43,400 If you try creating a WPA3 wireless LAN, and you leave PMF to disabled, 278 00:17:43,400 --> 00:17:44,840 you're going to get this error message. 279 00:17:44,840 --> 00:17:46,900 And it'll actually tell you it needs to be required. 280 00:17:46,900 --> 00:17:51,780 It's required. You got to turn it on for this particular wireless LAN. 281 00:17:51,780 --> 00:17:56,060 So that's it for this video on protected management frames. 282 00:17:56,060 --> 00:17:57,060 Thank you so much for watching.