5

Is it possible for an 802.1x network (PEAP/MSCHAPv2) to have no certificate (CA, user, or otherwise)?

If so, what are the security implications?

The reason I ask is: I'm regularly connecting to a particular organization's WLAN and I'm under the impression that there is no certificate in use. I don't recall accepting one, and the client configuration looks like this:

enter image description here

voices
  • 1,649
  • 7
  • 22
  • 36

2 Answers2

8

Is it possible for an 802.1x network (PEAP/MSCHAPv2) to have no certificate (CA, user, or otherwise)?

PEAP/MSCHAPv2 doesn't typically use client certificates, nor does it directly use any CA certificates in establishing a TLS connection (*see below). However it certainly requires the use of a server certificate (PEAP is a TLS tunneled EAP protocol).

If so, what are the security implications?

The image you provided indicates you are likely using some form of *nix which is giving you two certificate options.

Addressing the second option (client certificate) first, the vast majority of users connecting to wireless with a network using PEAP/MSCHAPv2 will never need this field (I have configured/deployed thousands of APs in numerous environments and have never seen this used personally).

The important option is the first one, the CA certificate field. Why? Because this helps to significantly reduce the possibility of connecting to a fake or rogue wireless network trying to impersonate the one to which you intend to connect.

This begs the question of how the CA certificate helps. Keep in mind that before successful authentication to the network, your client has no access to the network or the resources on it. The AP or wireless controller acting as the NAS (network access server) is proxying the connection from your client devices EAP supplicant to the RADIUS authentication server. The CA certificate is being used to help validate the identity of the RADIUS authentication server to which your EAP supplicant is authenticating.

Generally speaking, the EAP supplicant must make a decision on whether it will send your username/password to the authentication server without being connected to the network. This means it is only able to work with information it has and information it is given by the authentication server, it can't go out on the Internet to check another source until after it has authenticated and it is too late to withhold your username/password.

The EAP supplicant does this primarily by checking two things (with a couple options present in many EAP supplicants like Windows and OSX, but often not on mobile devices like tablets and phones):

  1. Is the certificate provided by the authentication server a valid certificate issued from a CA trusted by the client device?
  2. (Optional) Is the certificate issued from the designated CA(s) in the EAP supplicant?
  3. Does the hostname listed on the certificate match the hostname given by the authentication server?
  4. (Optional) Is the hostname given by the authentication server one of the hostnames allowed in the configuration of the EAP supplicant?

The other options for the EAP supplicant are to either have the OS prompt the user to "check and approve" the certificate (bad idea) or to not validate the certificate at all (worse idea) before sending your username/password.

So providing the CA certificate in your EAP supplicant configuration will help by allowing it to use #2 above to validate the identity of the RADIUS server in addition to #1 and #3. You should be able to get the correct CA information and/or certificate from your IT department.

Note: portions of this answer were copied from another of my answers.

YLearn
  • 3,967
  • 1
  • 17
  • 34
  • @tjt263, the EAP supplicant is the software that performs the 802.1X authentictaion to the RADIUS server. Is it not a service as it doesn't run in the background, rather it is called when an 802.1X authentication is needed. Once the authentication is done, it is no longer needed, so there is no reason for it to continue running. – YLearn Mar 31 '18 at 07:48
  • Thanks for the details on the handshake. If the client can't reach out to the Root CA to validate the server certificate, what prevents a malicious AP from presenting a falsified certificate? This may be naive, as I I don't understand certificates well, so I'm just hoping for someone to point me to a resource – retriever123 Jan 05 '22 at 18:04
  • The supplicant can still check the validity of the certificate, which is why providing as much of the configuration for the certificate is important if the device supports it. If you have configured the specific hostname and the CA that signed the certificate, it can be difficult to provide a falsified certificate. If you configure the supplicant to not validate the certificate at all, then it doesn't even need to be a falsified certificate (as any will do). – YLearn Apr 27 '22 at 17:20
-1

From cisco wesite you can read (link):

PEAP is based on server side EAP-TLS authentication. With PEAP many organizations can avoid the issues associated with installing digital certificates on every client device as required by EAP-TLS; instead, they can select the methods of client authentication, such as logon passwords or OTPs that best suit their corporate needs. Also PEAP is an enhancement of EAP-TLS authentication, PEAP encapsulates a second-phase authentication transaction within the TLS framework

So it is possible, but note that not checking the server certificate on the client makes the system vulnerable MITM that can lead to eavesdropping.

hawk78
  • 1
  • 1
  • 2
    This quote is from a user posting on the Cisco support forums and is not official documentation. It is also flawed. While EAP-PEAP does use a TLS tunnel, it doesn't use EAP-TLS. EAP-PEAP is also not an enhancement of EAP-TLS (which also uses a TLS tunnel). Further, not checking the server certificate just means that the supplicant doesn't try to validate the certificate it is presented with in any way. This doesn't mean the certificate isn't used. With EAP-PEAP, a server certificate is always required. – YLearn Mar 31 '18 at 03:18