CWNP CWSP – Module 04 – 802.11 Authentication Methods Part 5
Well what I wanted to do is kind of show you a generic display and in reality this is actually probably a little bit more extensive than what I wanted you to see. But we got a couple of steps. One of the first things is even before the EEP Paul start, the step one is that this Supplicant is trying to do an association with the access point, which means let’s say this is the only access point. So it’s what we would call a basic service set. But it’s still going to go through this authentication, whether it’s a controlled or uncontrolled ports. It’s kind of up to the authenticator, but we’re just trying to start that. And then the next part, second step, and by the way, we learn, and this is outside of the eat process, but these two guys are going to exchange what we call management frames.
And a part of these management frames is for the access point and the client to be able to talk to each other to tell them what type of security they support. So we’re going to assume that the access point and the Supplicant have both said they support EAP of some flavor. Remember this is kind of a generic. And so the second step is the Epul start. Again the authentication process. We’re going to send the ebull start frame to the authenticator and it can be an optional frame. Like I said, it depends on the version of EEP. But anyway, so we’ll consider that sort of stewing. And then step three, what we’re going to do is get the challenge. The Authenticator is going to send an EP request frame asking for the identity of the Supplicant and that is a required frame. Obviously another required frame would be a response if you’re asking me. So that’s step four if I got that in there right.
So step four is the response of the identity, again done in an EAP frame and it’s going to be done with the Supplicants identity and clear text, which is usually the username that’s in clear text as a part of the EAP response identity frame. And then at this point the uncontrolled port opens to allow the EAP traffic and all other ports would basically be stopped from that point. All right. Now what I haven’t put in here is the process with the Radius server. So you think about what’s happened. I’ve responded with my identity and so now the authenticator is going to encapsulate that information inside of an EAP response frame, step five and send that to the authentication server.
And that’s where again, where you’re using probably username and password, whatever is being sent, remember, I’m keeping it generic and that’s where the authentication server will look it up to see if they are legitimate. Now at some point, and it’s not really clearly written here in my little picture, the authentication server, step six is going to send a response.
It’s basically well, I can almost put number six right on the server itself, but it’s going to check the Supplicant’s name and check the database of users and then it’s going to send a password challenge to the Supplicant encapsulated in a Radius packet, the authenticator’s job. And that’s what all these requests are. So I’m just going to write them in. So then the authenticator is going to forward that challenge response.
And again, that’s my step seven. I know it sounds like a lot of work, but you know, this happens in just practically milliseconds really. So forwards a challenge response in a Radius packet to the authenticator and then the as is going to run. So step ten. Anyway, let’s see if I’m still on target here. So I’m going to forward the challenge and we get over here to the Supplicant. And then this guy, step eight, as I’m trying to put this through, is going to take the password and hashes and hashes it with its hash algorithm. Might be something like MD Five or it could be Chap or Ms.
Chap or whatever the case may be. And the Supplicant then is going to send the hash response in an EP from back to the authenticator. So that’s going to come back, that response is sent back. That step eight and then it’s kind of like eight being continued. Well, let’s not continue. Let’s make it number nine. And it’s going to send that response back to the authentication server. So it’s kind of forwarding the challenge response again in a Radius packet. Now from there, step ten, the authentication server is going to run again, the identical hash check to see if the response looks right. And we’ll either send a success meaning you got it right, or a failure message back to the authenticator.
It’s hard to keep them all in the same process, right? And with that then we’re going to see step eleven, assuming that it was a success, we’re going to see an EEP success message being sent back to the Supplicant and now the Supplicant has been authenticated. And then the last part of this step twelve and step 13, and I’m just going to write 1213 because we haven’t got to this point yet, is that the final step is what we call the four way handshake between the Authenticator and the Supplicant to be able to create dynamic encryption keys. The reason I’m not going to go into more detail on that is that we do go into more detail in a later part of this course about exactly how that four way handshake works. Bye.
So there are some legacy EAPs. When I first started seeing EP come out, it was believe it or not, it was around for a while. But Microsoft started really pumping out this product called Windows 2000 back in 1999 and they started telling us how now Windows is a network operating system supported EEP. So what does that mean? Does that mean they invented it? No means that. That’s when it started getting popular, I guess, because up into that point, if we were using the extensible authentication protocol, we had to buy specific hardware, like a card reader or whatever the case was, have specific software that could do all of that. So Windows was supporting it in the operating system, but like I said, it could be in the firmware. Now it can actually be built into the ASIC chips, the actual hardware itself. So there’s lots of ways of doing it.
So when I do talk about legacy though, as we know with any type of security that over time, processing power makes it easier to crack things and they just become old, they become antiquated. So one of the first ones is this thing called EAP MD Five. Now, remember, MD five is the message digest five. And it was a hashing protocol. Now, it was fairly simple as a type conceptually, the same as what I just went through with that generic EAP description used for a very long time. And this because it was a way to be able to get us to a point where we were using authentication servers. But it was a one way authentication, so we weren’t authenticating both directions. Like I said, it was more important that we could verify the authentication server than it was to verify the client. The username was sent in clear text. And MD Five, well, we still use MD Five a lot, but it is considered a broken hashing algorithm only because people have been able to prove that they can find two objects that have the same hash.
Think of it this way they call it a collision, some people call it a birthday attack, and then there’s a bunch of mathematical parts to it. But we’ve always told our kids in school, you probably heard this in school, that no one in the world has the same fingerprint or now what is it? It’s DNA. But if you watch all those shows where they’re checking to see if you’re the father, whatever the case is, I shouldn’t probably tell people I watch that kind of TV anyway. You always hear that there’s a 99. 9% chance that you’re the father. Why? Because we can’t say with certainty that over the entire history of time, people population that there might not be two people with the same DNA.
So they’re leaving there to be a little bit of doubt. Well, with MD Five, there’s a lot of doubt that we have enough objects that might have identical hashes. Trust me, I still think it’s fine. But anyway, so that’s one of the weaknesses of EP MD Five. Probably more stories than you wanted to hear. The next one, like I said, leap. The lightweight authentication protocol we just called it Leap. Very successful for many years. Was easy to deploy again, used pseudo. Mutual authentication. That’s a fun word to say, isn’t it? Pseudo means it kind of looks like mutual authentication. If both sides had a certificate, that wouldn’t be pseudo. That’d be real end to end authentication. So it might be using things like weak keys, that might be even pre shared keys, which means it’s not TLS, as TLS would be a non pseudo. Again, clear text password week ms chat version two. Hash that was being sent.
All right, let’s take a look at some strong EP protocols. One of the strong ones is EEP peep. Isn’t that sound great? Sounds like what was that? Like a chicken noise? Anyway. It’s called the protected extensible authentication protocol. So we just call it Peep. And one of the things it does is it uses that transport layer security tunnel. And remember, the TLS tunnel was designed for both sides to authenticate with each other and to be able to send everything through an encrypted session rather than just a clear text username followed by a hash. So we often call it as doing EEP inside of EAP. And so we’ll talk about that. As you can see, kind of a very busy picture here that’s going to try to show you the two phases that we go through to be able to use Peep. So let’s take a look at what happens to Peep. And remember, with Peep, what we’re saying is that both sides at some point are going to exchange certificates that transport layer security. It goes through four phases, but let’s face it, we first have to what did I say?
Have those management frames so that the Supplicant and the authenticator client access point, whatever you want to call them, know what their abilities are and what they require. And so we see the clients do the Epaul start identity request identity response, and then we have the TLS start. That was one of those messages that I just wrote over the top of. So it goes through two phases, and I think you’ll better understand these two phases and why they call it EEP inside of EEP. So phase one, EEP is basically where the authenticator and the server, whichever one starts, we’ll just call those both step one. Actually, step one was up here requesting identities, right?
And so we get the clear text and then we open up that virtual port. And then basically what we’re seeing here is that the client and the server are sending hellos. And so you can see the client certificate or the server certificate being sent. And then the server’s hello is complete. Then the client sends a certificate and then that one’s complete. And then at that point, both sides have been able to authenticate with each other. They also remember and these certificates have their public keys so that they can basically begin to create a cipher or to be able to basically start having secure communications. Now when we get into the keys, which comes up later in the course, we’ll come back and talk about this master key stuff and what these different keys are. So I’m just kind of ignoring that particular part at this point.
Now we have a protected payload. So what do we do? Well, now we’re doing EEP again in phase two. And in phase two, because we already have an encrypted tunnel, let me just kind of make it look like this, right? Like a little tunnels between them, then it doesn’t matter what how we send the username and password, because there is no more clear text. It’s all encrypted within this session. So we did EAP to help set up the encrypted session, and then we’re doing EEP again in phase two. So that’s where we then have what’s called the inner identity. Almost sounds kind of philosophical, doesn’t it? My inner self, my inner identity, which is the legitimate information.
And then that’s where we again, we’ll go through the password challenge response usernames. So the whole point of phase two is to validate the Supplicant. This is where we’re doing the actual authentication of who the Supplicant is. All right? So the advantages you see here is that it provides a very strong and secure authentication. It is supported ever since. Like I said, Windows 2000 supported it back in 99, works with Cisco, works with all the other vendors. Now, TLS doesn’t have to be involved, so client side certificates are not required.
But here we’re kind of showing it to you in the TLS side of things. And you can also support Token based, we can do chat, we can do Windows based, and we can do it inside of this phase two. Now, weakness, depending on the software and the operating system and the hardware, does take a lot of over because there’s a lot of messages, there’s a lot of encryption, and you need to have that third party trust, which I don’t think is a weakness. It just could be a weakness. And then it might cost you more money or a little harder to set up.
Popular posts
Recent Posts