I would like to draw attention to an intrinsic security flaw with NetworkManager's 802.1X handling and configurability.

Where an EAP method is used that relies on a public key infrastructure, such as PEAP, it is absolutely essential that a chain of trust be established between the supplicant and the authentication server in order to guarantee the privacy of the connection between the two endpoints before authentication is attempted.

To verify a digital certificate, a chain of trust must be established. The trust anchor for a digital certificate is the root certificate authority (CA).

Without first establishing a chain of trust, any PKI based encryption becomes meaningless as it becomes intrinsically vulnerable to MITM attacks. These are a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.

For example, where the commonly deployed PEAP-MS-CHAP v2 is used in an organisation, it is essential to protect the inner EAP type as it is not cryptographically secure alone.[1][2]

NetworkManager will prompt where the root certificate authority has not been constrained but has no ability for constraints on permissible server FQDNs to be defined. It also allows easy repeated dismissal with a 'Don't warn me again' for the CA constraint with a tickbox. This should not be so easily configurable, if at all.

The ‘Achilles Heel’ here lies in the fact that:

1) Without constraining the server name, the supplicant trusts all and any server names from permitted CAs.
2) Without constraining the root certification authority, the supplicant trusts permitted server names from any CA.
3) Without constraining either (the default), the supplicant trusts all and any server names from any CA.

Where an organisation has constrained the acceptable roots and a public certification authority is being used, an outside attacker can merely purchase a certificate of any name from the same authority and use it for MITM purposes.

Where an organisation has constrained the acceptable roots and a private, self-signed certification authority is being used, an inside attacker can use any certificate from that root that they have access to for MITM purposes.

Where the chain of trust has not been validated, the integrity of PKI based EAP methods is none existent. Furthermore, because it easily gives the illusion of security, it can be considered in many cases to be more harmful than good.

It is absolutely essential before attempting authentication via 802.1X, to:

1) Require the acceptable CAs to be defined.
2) Require the acceptable server FQDNs to be defined. (It's arguable that this should be configurable on a CA basis.)

Appropriate warnings should be given where the chain of trust cannot be established and specific instruction should be required to override. It should not succeed silently, as happens presently, where the supplicant has not been properly configured.

Users should be given appropriate feedback about the risks that are implicit where a chain of trust has not been established by the supplicant before any private information is passed. This is exactly the same way that Web browsers presently operate.
 
[1] http://www.schneier.com/paper-pptpv2.pdf - Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)
[2] http://penguin-breeder.org/pptp/download/pptp_mschapv2.pdf - Exploiting known security holes in Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)