Hello and welcome to this video titled WPA protected management frames
also called PMF.
So begin with it's a good idea just for us to quickly review the different
types of 802.11 frame types.
So we know that 802.11 defines three types of Wi-Fi frames.
You've got your data, which is what most of the frames are when you're
doing your town netting and your web browsing and everything else.
You've got specific frames called control frames such as clear to send
and ready to send.
And then you've got a variety of management frames.
Now within the management frames section, which is what we're really focused
on here, we've got things like beacons, your probe requests and probe
responses, authentication, association frames, action frames.
So those are considered management frames.
Now, when we think about those management frames, we do have some vulnerability.
Now let's think about first of all, what are these management frames really
used for? They're used to initiate and tear down sessions for network
services. They also give wireless LAN clients a lot of information about
the BSS, what its capabilities are, what it can do.
It can also tell the clients who are currently associated to the BSS to
take some action or to do something.
Now, if those management frames are spoofed, for example, if a rogue access
point starts advertising its own beacons and it makes itself look exactly
like your legitimate access point, and we call this an evil twin and starts
spoofing those management frames, it can tell the clients to do things
which can result in denial of service, luring the clients to actually
associate to the evil twin access points to the real access point, slowing
down wifi traffic and all sorts of things.
For example, here's an evil twin.
It has been monitoring the beacons so we know what the BSSID, the MAC
addresses of the legitimate access point.
So using some various methods, we can make our evil twin simulate that
exact same MAC address and that exact same SSID.
And so one common attack is a D authentication attack where it now just
sends a deauthentication message to that client saying, I need to kick
you off so the client then becomes deassociated.
It leaves the wireless land just for like a second.
And then if the next beacon that it hears is coming from that particular
access point, it might end up associating to the evil twin.
And now it could send its information to the evil twin instead of the
rogue access, instead of the real access point.
Now, think about these management frames are is that when we get into
protected management frames, I'm going to talk about that in a moment,
we're not talking about encrypting them.
You can't encrypt management traffic.
And the reason why is because management frames are designed to be heard
and understood by all clients, even clients that haven't associated to
the BSS yet. After all, if you're doing roaming, you need to be able to
see in plain text, for example, the beacons and the probe responses.
So you can decide if you really want to roam to that wireless land or
not. So we can't encrypt them.
But what we can do is protect them in other ways.
So let's talk about that.
So 802.11w was actually the first IEEE specification in which protected
management frames were first introduced.
And management frames, when we think about them, like the list I just
gave you, at a high level, we can categorize management frames into two
types. There are those that are sent prior to the EAP over land handshake,
such as probe responses, probe requests, beacons, and there are those
that are sent after.
So protected management frames, 802 .11w specified some of the management
frames as being the special class or category called robust management
frames. And these are what we can protect via protected management frames.
Now, robust management frames, by definition, are those management frames
are used after a client has gone through its EAP over land handshake.
So what frames are we talking about?
So robust management frames include disassociation, deauthentication,
robust action frames.
So those three right there.
Now robust action frames, there's a lot of frame types that fall into
this category of robust action frames, such as spectrum management, channel
switch announcements, where the access point might say, oh, I've just
detected some radar.
We need to leave this channel and move over to channel 157 instead or
something like that.
That would be considered a channel switch announcement.
QOS frames, block acknowledgments, fast BSS transition when you're doing
fast roaming, and others.
Now, there are a variety of ways that these frames could be misused by
malicious hackers if they were able to spoof them and get your client
to believe their spoofed management frame.
For example, look at that second one there, the channel switch announcement.
What if a rogue access point pretending to be the legitimate access point,
let's say you're currently associated on channel one of a 2.4 gigahertz
wireless LAN, and all of a sudden you get a channel switch announcement
saying, hey, everybody needs to switch to channel 11.
Well, if you follow that, you might be switching on to a channel that
is actually in charge of by the rogue access point.
And now you're really in trouble.
And that's just one way that these frames could be spoofed and used for
nefarious purposes.
So let's talk about how PMF actually applies to protect these management
frames. Since we can't encrypt them, what can we do?
So PMF allows the addition of a cryptographic signature.
So whenever you see that word signature, a little bell should go off in
your head, bing, bing, bing, bing, bing, a signature means we're talking
about a message integrity code.
We're talking about protecting the integrity of the data so that when
you receive it, you know the the bits haven't been changed in transit.
And you know it's come from a legitimate source.
That's what we're talking about.
So that's what PMF does.
It adds a message integrity code to these robust management frame types
that we just talked about.
So the mick actually allows the receiver, which is typically the client,
to verify a bunch of things.
Number one, it verifies that the frame hasn't been tampered with in transit.
In other words, the bits haven't been modified.
And more importantly, it allows the receiver to verify that this really
came from my access point, my legitimate access point that I'm associated
with, not some rogue access point that's trying to spoof my legitimate
access point. So the frames that come from the access point, those robust
management frames, some of them are unicast.
For example, if the access point sends you a disassociation or deauthentication
message or something, that's from the access point to you as a specific
client. So to create the mick for those, we're just going to use the client's
key confirmation key.
Remember, when the client first associated went through the EPU overland
handshake, it created a pairwise transient key.
And then part of that pairwise transient key was sort of redefined as
a key confirmation key, specifically for the purpose of creating these
message integrity codes.
That's what it's for.
So that same key confirmation key can be used to create mix for these
unicast, robust management frames.
Now, sometimes the access point will send a robust management frame that
is a broadcast that's spent for all the clients in the wireless LAN.
And you can't use any one client's key confirmation key to create mix
for those. In that case, the access point actually has its own special
key called the integrity group temporal key that it uses to create and
apply mix to those.
And we'll talk about that more in just a moment.
So here's a comparison.
You can see on the sniffer trace on the top, this is a management frame.
It's a deauthentication.
So this would be considered a robust management frame, but there's no
protection here.
No indication whatsoever of any integrity protection via a mick or anything
else. Whereas down below, if we see a deauthentication frame here, we
can actually see it says data and it's got some data in it.
And this, this actually is the mick that was added via protected management
frame. Now, if we actually open this up a little bit more, we see even
more information and more confirmation that this has been protected via
PMF. And that's what we see right here.
So if we open it up even more, first of all, we can see under the flags
field, there is a flag called the protected flag.
And if it's set to one, like it is here, it says this data is protected.
So right there, that's your confirmation that PMF is in you.
Now, a few more things down here.
We already know that the data on the bottom here is the mick.
That's the message integrity code.
What about the CCNP parameters?
What's that? Okay.
So this is a unicast robust management frame, unicast from the access
point to the client, right?
From the Cisco access point to the client.
As such, the CCNP protocol, now, normally when we think of CCNP, we think
out as a formula or an algorithm for figuring out how to encrypt data
and how to decrypt data.
But CCNP, if you look at the spec for it, it also has a part in there
about how do we create and apply message integrity codes.
So CCNP does both.
So in this particular case, we're just using the message integrity code
part of CCNP. So this is saying CCNP was used to create the message integrity
integrity code. And so it's saying, first of all, the key index being
zero, what that's talking about is sometimes the, there can be a change
in a key. And if there's a moment where the key is being rotated or changed,
there might be at a certain moment in time more than one key that's possible.
So the key index would give you indication about is that the older key
we're using, like key zero, or we now protecting this with a newer key,
like key one. Now, in the case of unicast frames, this would always be
zero. This key index is going to be more applicable when we look at protecting
broadcast frames, like a channel switch announcement or something like
that. Because in that particular case, the access point could rotate its
keys for protecting broadcast and multicast traffic.
Not really going to see that though with unicast traffic.
But the CCNP extension, the initialization vector, this is also kind of
interesting. This is used to prevent replay.
This is called an anti replay protection.
You see, every time one of these frames goes out, these, these protected
management frames is protected with PMF, this is like a counter.
Notice how it says eight here at the end.
So this, and this is coming from the access point.
That means this is the eighth protected management frame.
This access point has sent to this particular client during the duration
of this association.
And if he has any more to send, it will keep increasing.
So how this could be used is if this client suddenly received a protected
management frame that looked like it was coming from this access point,
but let's say the initialization vector was the number seven or six at
the end, the client would say, that's not valid.
These numbers should only be increasing, not staying the same or decreasing.
So that would be a potential replay attack.
And so the client would just delete that.
It would just ignore it.
So that's how we're doing it here.
So protected management frames are not only adding the message integrity
code to verify that the frame came from a legitimate sender.
It's also protecting against replay.
And this shows you here in a beacon that's been caught.
And within the beacon, it will actually advertise from the access point,
if PMF is in use or not on the wireless LAN, you can see there's a couple
of flags for it here.
And this is because when you actually go into your, for example, your
wireless LAN controller, and you're under the configurate or, you know,
the edit wireless LAN setting, you'll see that for WPA3, first of all,
WPA2, let me go back here.
So protected management frames, and we're going to see this coming up
in just a second, are optional for WPA2.
You can have them or not have them.
They are required for WPA3.
And so that'll probably skip me right past that slide when I get to it.
So if, and so that's what these flags are for.
So in a WPA3 wireless LAN, we would expect both of these to be turned
on. Not only is management frame protection capable, that's true, but
management frame protection is required.
That's also true.
So it's capable and required.
Whereas if we were seeing this beacon from a WPA2 wireless LAN, where
you had set the management frame protection to optional, then you would
see protection capable being true, but you would see protection required
being false. But either way, if you see either one of these bits set,
that means we can use protected management frames on this wireless LAN.
All right. So you might, you might have noticed in some previous sniffer
traces I had that there was some mention of in the robust security network,
an element of the beacons.
There was something called BIP.
What is BIP? We've been talking about how some robust management frames
are sent as broadcasts or multicasts.
For example, a multicast deauthentication.
If the access point is saying, I need to kick everybody off right now,
or a channel switch announcement, or some group addressed action frames.
Now, if we want to use protected management frames against those, we can't
create the MIC using any particular client's temporal key, because only
that client will be able to validate it.
Other clients will not.
So instead, there's something called the broadcast, multicast integrity
protocol that's used.
And that's what BIP is.
And we've started playing around with this already.
We talked about a little bit.
So in 802.11w, remember that's the protected management frame specification.
It introduced a new key for use with this broadcast, multicast integrity
protocol, which is called the integrity group temporal key.
It is the access points job to derive this.
So remember that the access point when it boots up is going to come up
with a group master key, a GMK.
And then from that, it's going to derive a group temporal key for encrypting
broadcast and multicast data.
It's also going to derive this and the integrity group temporal key in
IGTK. And just like the GTK, the group temporal key is given to clients
in message three of the reason why we had to come up with this is because
CCMP or GCMP, depending on which one you use, we talked about how those
algorithms have a section devoted towards how do we encrypt and decrypt
data. And then they also have another section in those protocols about
how do we create message integrity codes and how do we validate them?
Well, the message integrity code section, actually, all of that is for
unicast stuff. So CCMP and GCMP were designed to do all of their security
on unicast. They really can't deal with broadcast and multicast.
And that is why BIP was created.
And BIP had to create its own key.
And that's why they developed the IGTK for BIP.
And that's what creates the message integrity code.
So we can see right here in message number three, that's when it's going
to go out. So just a few final thoughts.
In PMF protected management frames, once again, for unicast robust management
frames, the MIC is created by taking the client's individual temporal
key, running it through the CCMP or GCMP algorithm and outspits a message
integrity code for that particular frame, that Wi-Fi frame.
For broadcast or multicast frames, we take the IGTK, apply it with BIP
against the data.
And that creates a MIC for the broadcast frame.
As I mentioned, WPA2 was first offered.
PMF is an optional service.
WPA3 requires protected management frames.
And you can see a screenshot right here.
If you try creating a WPA3 wireless LAN, and you leave PMF to disabled,
you're going to get this error message.
And it'll actually tell you it needs to be required.
It's required. You got to turn it on for this particular wireless LAN.
So that's it for this video on protected management frames.
Thank you so much for watching.