This topic is to discuss the following lesson:
hi rene ,
just please i have a question about WEP you explained before that it can support two authentication methods 1-Open authentication 2-Shared key authentication , so how WEP can support authentication methods while itself has itâs own authentication method ?
Also what is the difference between pre-shared key and shared key ?
Hello Michael
I understand your confusion, and I believe it is an issue with terminology. WEP is actually defined as a security algorithm that is used in the IEEE 802.11 standard wireless networks. This algorithm has several configuration parameters, one of which is the type of supported authentication. This simply refers to how the WEP algorithm is applied to a wireless communication.
The first, which is Open authentication, doesnât require credentials, so anyone can connect to an Open Authentication WEP access point, so any client within range can freely connect. However, the actual data being transmitted is encrypted.
The second, shared key authentication, does require credentials, and so not âjust anybodyâ can connect to the access point. The actual data being transmitted is still encrypted.
As for the shared and pre-shared key, the difference is as follows:
WEP uses a shared key, which means that every client uses the same key. It is shared among multiple users. A pre-shared key is simply a key that has been shared before the time of the actual authentication. This is the general definition of these terms. Of course, this does not prevent you from âpre sharingâ a shared key, but in the framework of WEP (shared) and WPA2 (pre-shared), this is the meaning.
I hope this has been helpful!
Laz
1 Like
thanks lazaros i got it
Dear sir,
How to enable cert in my PC ? Unable to connect the WIFI network since authentication have failed.
Please help .
Thank you
Regards,
Mani
Hello Mani
After doing some research I have found that this error appears whenever a device attempts multiple failed authentications within a specified period of time. This makes the âClient suppression mechanismâ of the ISE kick in. This prevents DoS attacks. You can disable this feature in Administration > System > Settings > Radius, Suppress Anomalous Clients. You can also change the settings such as how long a client should be blocked.
More info about this can be found at this Cisco community thread:
Now this is the reason for the blocking. But why did your device have multiple failed attempts? The reason outlined in the output above shows 12511 Unexpectedly received TLS alert message. This seems to be the case when you use a wildcard certificate when the CN contains * as a wildcard. You can find out more about this at the following Cisco community thread:
Cisco also has official documentation about this here:
Hopefully this information will help you in your troubleshooting processâŚ
I hope this has been helpful!
Laz
Hi,
I am trying to find some reference that states EAP-FAST requires a radius server. Most resources that I have seen online state âauthentication serverâ and havenât explicitly stated radius.
Hello Shashank
EAP-FAST can indeed be used with RADIUS and you can see how this can be achieved in the following Cisco documentation:
In it, it refers specifically to RADIUS as the authentication server. This is a typical setup, although other documentation that talks about an overview of EAP-FAST as a technology, does not refer specifically to RADIUS, but it states âauthentication serverâ as you said, much like what you will find in the following document:
In section 2.1 of RFC 4851 which describes EAP-FAST, it speaks about the architectural model of the technology, and it references a RADIUS server as performing some of the authentication mechanisms in the event you use an external authenticator. Alternatively, you can use the AP itself as an authenticator.
So you see RADIUS is used, although it is not the only option to be used.
I hope this has been helpful!
Laz
Hello,
Sorry about the long question.
The wireless security section is easily the most difficult one to wrap my head around. There are so many ideas that just seem to float around without any apparent connection to each other. Or rather, they make sense when looked at on their own, but not quite when Iâm looking at how they all fit into a single picture.
Is it possible to summarize the ideas based on what needs all different components address? If I understood it correctly, this is how everything fits together when asking the question of what needs they address:
-
The user must prove that the computer they are using belongs to their company. The reason for that is to eliminate the possibility that a foreign (i.e. non-company owned) device is used. This is done
a) when using LEAP: there is no such check when using LEAP: even non-company owned computers can join the internetwork;
b) when using EAP-FAST: the PAC thatâs installed on every computer;
c) when using PEAP: the computer does not have or use a certificate of its own, so it must be authenticated within the TLS tunnel using either MSCHAPv2 or GTC (Generic Token Card);
d) when using EAP-TLS: the AS and the computer exchange certificates and can authenticate eachother. -
The user must prove that they are employees of the company. The reason for that is to eliminate the possibility that someone stole a company-owned computer and tries to log in with a userâs credentials. This is done
a) when using LEAP: username and password credentials;
b) when using EAP-FAST: as an optional feature, the end user can be authenticated through the TLS tunnel;
c) when using PEAP: if the end user computer is satisfied with the identity of the AS, the two will build a TLS tunnel to be used for the inner user authentication;
d) when using EAP-TLS: the AS and the computer exchange certificates and can authenticate eachother. -
The AP must prove that it belongs to correct company. The reason for that is to eliminate the possibility of a man-in-the-middle attack, where a foreign AP pretends to be the companyâs AP, thereby gaining unencrypted access to company information via the end user host. This is done
a) when using LEAP: both the authentication server and the computer exchange challenge messages that are then encrypted and returned. This provides mutual authentication; as long as the messages can be decrypted successfully, the computer and the AS have essentially authenticated each other (this works because only the company-owned APs know how to get to the companyâs AS);
b) when using EAP-FAST: the PAC thatâs installed on every company-owned computer;
c) when using PEAP: the AS presents a digital certificate to authenticate itself with the computer in the outer authentication (this works because only the company-owned APs know how to get to the companyâs AS);
d) when using EAP-TLS: the AS and the user exchange certificates and can authenticate each other (this works because only the company-owned APs know how to get to the companyâs AS). -
The data between the AP and the computer must be encrypted. The reason for that is to prevent eavesdroppers from gaining access to confidential information. This is done
a) when using LEAP: RC4, which has been deprecated because itâs easily hacked;
b) when using EAP-FAST: can be TKIP (=WPA; deprecated); or AES (=WPA2 or WPA3);
c) when using PEAP: if the end user host is satisfied with the identity of the AS, the two will build a TLS tunnel to be used for the encryption key exchange;
d) when using EAP-TLS: can be TKIP (=WPA; deprecated); or AES (=WPA2 or WPA3). -
The data between the AP and the end user host must undergo an integrity check. The reason for that is to make sure that it wasnât tampered with (otherwise it might be used in a replay attack). This is done
a) when using LEAP: no integrity check is used;
b) when using EAP-FAST: can be TKIP (=WPA; deprecated); or CCMP (=WPA2); or GCMP (=WPA3);
c) when using PEAP: can be TKIP (=WPA; deprecated); or CCMP (=WPA2); or GCMP (=WPA3);
d) when using EAP-TLS: can be TKIP (=WPA; deprecated); or CCMP (=WPA2); or GCMP (=WPA3).
Open authentication doesnât address any of these 5 needs.
Thank you for reading my very long post. Iâm trying hard to understand the material, and hopefully with some help I can master it fully.
Attila
Hello Attila
This is an interesting approach to the categorization of the components of each type of authentication. To me, it looks a bit cumbersome. However, if it works for you and helps you understand the various options more thoroughly, then thatâs great! Here are a few points of clarification:
For number 3a, LEAP does not provide a robust mechanism for authenticating the AP itself. The mutual authentication you mentioned is between the userâs device and the authentication server, not the AP. LEAP is vulnerable to man-in-the-middle attacks, which is one of the reasons it is considered less secure.
For number 3b, the PAC is used for establishing a secure tunnel between the userâs device and the authentication server. It does not directly authenticate the AP. However, by using a secure tunnel, EAP-FAST mitigates the risk of man-in-the-middle attacks.
For number 3c, the authentication server presents a digital certificate to the userâs device to authenticate itself. This certificate authentication takes place within a TLS tunnel, which helps prevent man-in-the-middle attacks. However, it is not directly related to the AP, as the AP is not authenticated in the process.
For number 3d, the mutual authentication in EAP-TLS is between the userâs device and the authentication server, not the AP. By exchanging certificates, EAP-TLS can prevent man-in-the-middle attacks, as the authentication serverâs certificate must be trusted by the userâs device. The AP is not authenticated in the process.
For numbers 4 and 5, keep in mind that LEAP, EAP-FAST, PEAP, and EAP-TLS are authentication methods and donât directly perform encryption or integrity checks. They cooperate with protocols and algorithms that supplement their operation with encryption and integrity checks. The protocols and algorithms that can be used with each authentication method are specific, and you have listed them correctly in your post.
I hope this has been helpful!
Laz
1 Like
Hello Laz,
Thank you very much for the thorough response.
Yes, I agree: it is a bit cumbersome, but as I was reading about this topic, I kept asking myself âBut whatâs the purpose?â when reading about the technology, and this way of thinking about it helped me put things in place, as you said. However, Iâm open to different perspectives as well (which is why I have the habit of looking up the same topic in different resources, such as this excellent website along with the equally excellent forum).
Can you please help me clarify the following?:
You said:
âFor number 3a, LEAP does not provide a robust mechanism for authenticating the AP itself. The mutual authentication you mentioned is between the userâs device and the authentication server, not the AP.â
So itâs possible for a foreign (non-company owned) AP to play the role of the Authenticator? Doesnât the Authentication server (which is the ISE for Cisco) realize that the messages arenât relayed by one of the companyâs APs?
You said:
âFor number 3b, the PAC is used for establishing a secure tunnel between the userâs device and the authentication server. It does not directly authenticate the AP.â
Wendell Odomâs OCG, Vol. 1, Chapter 28: âSecuring Wireless Networksâ says âThe PAC is a form of shared secret that is generated by the AS and used for mutual authentication.â, which he specifies as âPhase 1: After the supplicantâ (note: which Iâm calling the computer here) âand AS have authenticated each other, they negotiate a Transport Layer Security (TLS) tunnel.â So the computer should recognize the AP as well, right? Otherwise, how could this be a mutual authentication?
Have a great weekend. 
Attila
Hello Attila
Yes, it is possible for a foreign or rogue AP to act as the authenticator in a LEAP setup. LEAP is an older and less secure authentication protocol and is known to have several vulnerabilities, including not providing a robust mechanism for authenticating the AP itself. The mutual authentication you mentioned is indeed between the userâs device and the authentication server (AS), but it doesnât necessarily authenticate the AP.
An attacker could set up a rogue AP that impersonates a legitimate company AP. When a user tries to connect to this rogue AP, the attacker can then forward the authentication messages between the user and the legitimate AS, which could be a Cisco ISE or some other AS. The AS might not be able to differentiate between messages relayed by a legitimate AP and those relayed by a rogue AP, as it mainly authenticates the user credentials and not the AP itself.
This is a known weakness of LEAP, that it is susceptible to MITM attacks. Thatâs why protocols such as EAP-TLS, EAP-TTLS, or PEAP protocols, which support the authentication of the AP itself, reduce the risk of rogue APs and MITM attacks.
Note here that the mutual authentication takes place between the supplicant (client) and the AS, not the AP. The PAC is not used for directly authenticating the AP. It is used as a shared secret for establishing a secure tunnel between the supplicant and the AS.
Note however, that EAP-FAST does support the authentication of the AP iteslef, but itâs done through the use of server certificates, and is achieved between the AS and AP. The AS sends its certificate to the supplicant, which can then verify the serverâs authenticity.
So although the supplicant does not authenticate the AP (nor visa versa), the AP is indirectly authenticated by the authentication server, delivering a higher level of security and authentication than LEAP.
Does that make sense?
I hope this has been helpful!
Laz
1 Like