Hello and welcome to this video titled, Potential Problems with Hash to
Element. So as a review, in case you're coming into this video fresh and
you haven't seen any other videos on this particular topic, just as a
review, we know that WPA3SAE must first derive a number called a password
element before performing the SAE exchange.
So the password element is going to be a number that's plugged into the
various formulas that are used during the SAE commit process.
Now how is that password element created?
Well, it's done by finding a common element, which is a common point on
an elliptic curve.
And in previous videos, we talked about how points on elliptic curves
have to match certain formulas.
That the x value that you use, you have to plug into the formula, and
if it derives a valid y value, then you've got your two valid points.
So how is this done?
Well, there's two complex mathematical ways to derive these valid x and
y points by taking your passphrase and your SSID and a few other things
as inputs. So how do we take the passphrase, SSID, MAC addresses and other
things and come up with some value that we can test against the elliptic
curve formula to see if it is indeed a valid x coordinate?
Well, the two ways are hash to element and hunting and pecking.
Hash to element is newer.
It's more secure than hunting and pecking.
And if a wireless LAN access point advertises hash to element capabilities,
and if the client supports it, the clients will prefer hash to element.
All right, so you might be thinking, great, I'm just going to use hash
to element then.
It's newer, it's more secure.
I'm just going to use it.
So now I'm going to show you in the subsequent slides for this particular
video are some gotchas or bugs or caveats.
I actually noticed in the lab when I was using various hash to element
combinations in the creation of my wireless LAN.
I'll tell you right off the bat.
I cannot explain why this is happening.
I've wrapped my mind around all the mechanics of how the controller and
the access point communicate, who talks to the client when, what messages
are going on, and I just gave up and I couldn't figure out why what you're
about to see actually is happening.
So I can only show you what you might experience and advise you how to
avoid it. All right, so that being the case.
So some older access points that do support hunting and pecking do not
support hash to element.
So you might recall that when WPA3 first came out and they said, oh, you
can do a personal version of it called WPA3SAE.
All right, well, if you're doing WPA3SAE, that means you have to create
a password element.
You have to because that's ultimately going to help you create the secret
key, which is going to ultimately help you create your pairwise master
key. So we got start with the password element.
And so the original form was doing hunting and pecking.
So, and then hash to element came later.
So if you've got some older access points like your, for example, Cisco
3802i is an example because that's what I have here in my lab.
I found out much to my dismay that they don't support hash to element.
They only support hunting and pecking.
So here's sort of the thing that I discovered unpleasantly that the Cisco
9800 wireless LAN controller will still allow you when configuring or
editing a wireless LAN to select hash to element, even if the access points
it's managing don't support it.
Now you might think, well, wait a second, the controller knows all the
access points is controlling.
It's got all their information because they had to join it via capwap.
So should the controller be aware of what access points are older and
don't support H2E and what access points do support it?
And wouldn't you think it's logical that if you select H2E in your wireless
LAN that you get some sort of error message or pop up saying, unsupport
or something like that, nope, you won't see anything like that.
It will let you create the wireless LAN, selecting hash to element, even
if the downstream access points it's managing are old and don't even know
what hash to element actually is.
Now keep in mind that this capability of hash to element is supposed to
be advertised in beacons.
The access point every, you know, 10 milliseconds, actually every 100
milliseconds is supposed to when sending out its beacons include a little
information element in there, which I'll show you in just a minute that
says, I support hash to element.
So hey, clients, if you want to do that, I can do that too.
So here we have a situation where the wireless LAN controller has been
configured saying this wireless LAN, this WP3 wireless LAN is going to
use hash to element to create the password element.
And then it's pushed that down to the access point and the access point
is saying, huh, I don't know what that is.
What's H2E? So what's going to go on in that situation?
What happens in that case?
This is what I'm going to show you.
So in an ideal world, this is what you'd see coming out of your access
points every 100 milliseconds with those beacons.
So here's a beacon you can see here.
Here's the sort of the first part of it.
You can see the RSN information element.
And then right below that, there's the RSN extension.
I love how they capitalize the X there, the extension element.
And there's a bit in there called the SAE hash to element.
And if that bit is set to one, that means this is true.
So this is how the access point is telling all the clients and potential
clients out there, I support this capability.
If you wish to use it, you can because I know how to deal with it.
That's what you should see.
Okay. Now the remaining slides here are going to show you what I saw in
the lab when I was using older access points that don't support hash to
element. So we know that in your 9800, if I go back here just a little
bit. Right here.
It defaults to both H2E and HNP.
So if you don't click anything in this box right here, this SAE password
L, if you just leave it alone, the default is both H2E and HNP.
Now, what are you going to see if the actual access point doesn't support
H2E? What's going to happen then?
All right. So what you're going to see then is this.
Yes. So when a client tries to connect, you're going to see that it looks
like it's working.
Look at this. We see, let me just go ahead and do this up here.
We see the four SAE authentication messages, right?
The two commits, the two confirms, that all looks good.
So clearly the access point and the client came up with a password element.
That they were able to use that matched, but for some reason.
And then you go through the association messages, you start doing the
EAP over land keys.
So we say here, we see message one, message two, message three, and then
right there, right after EAP over land key message three, the client will
send to the access point a disassociation message.
Now, like I said, I cannot explain the mechanics of why this is happening
under the hood. I just want you to know that if you see this, that's what's
going on. What's going on is that your controller is using both H2E and
HNP, but the actual access point is not supporting H2E.
And so this weird behavior is what happens is the client almost gets all
the way through.
But then after the end of message three, it says, no, I'm done.
I'm leaving this wireless land.
So that's what you'll see there.
Now, you could also, if you see that, you might say, oh, man, I'm going
to start the radioactive trace on my 9800 controller and see what's going
on. And this is what you'll see.
So it says here, it says EAP key right there says, sent M3 successfully.
Now, normally the controller plays no part in the authentication message
exchange, the association messages exchanged, or the EAP over land key
message exchanges.
Normally, that's only done between the access point and the client.
It's very time sensitive.
And, you know, if you actually think about it, a controller could be managing
hundreds of access points and thousands and thousands of clients.
The controller just doesn't have enough bandwidth to be able to process
all those messages going back and forth with thousands of clients.
It doesn't see that.
But when you turn on the radio active trace and you start tracing, for
example, a particular client, it's kind of like the controller sends a
message downstream to the access point saying, hey, tell me what you're
doing. I want to have visibility into the messages that's going on.
So keep in mind that normally the controller wouldn't see these EAP messages.
He wouldn't take part in that.
But when you turn on radioactive trace, he's like getting a copy of them.
He's getting messages from the access point so he knows what's going on.
And so it shows you right here, just like we saw in the sniffer trace,
after the EAP over land message three is sent out, then all of a sudden
we get deleting the client and says client delete reason, EAP timeout
failure. So once again, can't explain what's going on underneath the hood
here and why this is happening.
But these are your two indicators here of what you would see if things
are failing with both hash to element and hunting and pecking.
Now, what if we switch in the controller to hash to element only?
What if we select that in the dropdown window?
Well, then the failure will actually happen much, much more quickly.
You'll see that the client will send his first commit message.
And then the access point will send a commit message back.
See right here, type commit.
But right there, the access point will send in his commit message back
a message saying unspecified failure.
And then the client will deauthenticate.
And then everything just starts all over again.
This just starts repeating.
So he won't even get as far as the EAP over land messages in this particular
case with hash to element only.
This is what you see.
And once again, what do we see in a radioactive trace in this case?
In this case, we see it actually is a little bit more explicit.
It says PWE mismatch expected hash to element status code.
Now, this, this, obviously, you will leave you sort of scratching your
head because you'll say, wait a second, when I can figure this wireless
LAN in that dropdown box here at the end, I selected H2E only.
I selected that.
So if I selected that, then the access point is sending out his beacons.
He should be with that hash to element equals true, meaning I support
this. And if clients see that, they're supposed to use hash, they're supposed
to select a diffi-helmin group that maps to hash to element.
And this is one thing as well.
So you might wonder when a client sends his commit message to the access
point, how does the access point know if that client derived his password
element using HNP or H2E?
There's not, if you actually look in the sniffer trace of a commit message,
there's no field in there that says, I used one or the other.
There's not. Well, how he knows that is that there's certain elliptic
curve diffi-helmin groups that are used for hash to element, and there's
other groups that are used for hunting and pecking.
And so in the commit message from the client, it will actually explicitly
say what diffi-helmin group it used.
So in this particular case here, when that commit message came in from
the client, the diffi-helmin group was not a hash to element group.
It was a hunting and pecking group.
And the controller, the access point is saying, I've been configured for
hash to element only.
Why is the client trying to connect to me using hunting and pecking?
That's a mismatch.
That won't work.
But what's funny here is the reason why the client's doing that is because
the access point is old.
And he actually didn't say he was capable of hash to element in his beacons
because he doesn't support it.
So once again, if we go a little bit deeper, why is this happening?
I can't really explain it to you, but this is what you'll see.
All right. So what's the takeaway from all of this?
How to avoid these problems?
Well, number one, if you're using Wi -Fi 6E or Wi-Fi 7, you got to do hash
to element. So obviously, if you're doing Wi-Fi 6E or Wi-Fi 7, you're
going to have a newer access point.
Only newer access points support that.
And so those will support hash to element.
You don't have to worry about that.
But if you're doing an older form of Wi-Fi, like Wi-Fi 6 or something
even lower than that, your access point might not support hash to element.
And you might end up having these types of problems when you're configuring
it with your 9800 controller or possibly any other controller as well.
So here's the moral of the story.
If you know in advance that none of your access points support Wi-Fi 6E
or greater, just configure your wireless LANs with hunting and pecking.
On your controller, don't stick with the default of both H2E and HNP.
We've already seen how that causes problems.
Just go in that drop down window and select HNP only, and you won't have
any issues. So that's it for this video.
Thank you so much for watching.
And I really hope it was helpful for you.