I assume the question is about the "server" certificates used by PEAP, EAP-TLS, and EAP-TTLS to protect password authentication, as this wouldn't be a problem at all with client-certificate-based EAP-TLS.
I doubt the EAP standards documents would ever have this information, given the crazy inconsistency across implementations (which surely wouldn't be as bad otherwise). Also consider that EAP and 802.1X were used by Ethernet and PPP dial-up a long time before WiFi, so the standards likely wouldn't talk about SSIDs.
Update: RFC 7593 ("eduroam") was published recently and discusses this in more detail. eduroam is probably the largest service using 802.1X/EAP, with many federated realms worldwide. Its summary in RFC 7593, especially section 7.1, talks a bit about the situation of server verification among eduroam users.
What information does the certificate that the AP sends to the client, contain: is it the SSID, or something else?
The PEAPv0 draft does not talk about this at all.
The PEAPv1 draft says:
"The peer SHOULD verify the validity of the EAP server
certificate, and SHOULD also examine the EAP server name presented in
the certificate, in order to determine whether the EAP server can be
trusted."
It doesn't however describe how the server name should be verified, and in fact admits that the name could be wrong:
"Please note that in the case where the EAP authentication is
remoted, the EAP server will not reside on the same machine as the
authenticator, and therefore the name in the EAP server's certificate
cannot be expected to match that of the intended destination. In this
case, a more appropriate test might be whether the EAP server's
certificate is signed by a CA controlling the intended destination and
whether the EAP server exists within a target sub-domain."
RFC 5281, which specifies EAP-TTLS, requires verification against a known CA, plus checking that it has the "server authentication" extendedKeyUsage enabled.
(Note that even the CA checking isn't always implemented; for example, iOS and Windows 8.1 ask the user to verify the certificate fingerprint when connecting for the first time.
The EAP-TTLS specification doesn't require any common-name or subjectAltName value as far as I can see. Some clients (Windows, wpa_supplicant) have a configuration setting for what the expected "common name" should be, while others don't care at all.
Note that the certificate isn't always sent by the AP, but often by the RADIUS server handling the authentication. There are federations like eduroam, which use the same SSID everywhere (some places even offer eduroam-authenticated Ethernet ports), but all authentication requests are routed to home organizations based on the @domain in the login name, and each organization has its own EAP certificate. So in a better world, the @domain is what should be compared against the certificate.
For example, Microsoft KB 814394 documents the requirements the Windows PEAP client has.
How can the user know that it is connected to a trusted AP? Again, with HTTPS, my browser will give a warning. Will my PC or mobile device warn me if I'm connecting to an untrusted access point? Or is the only way to notice that there is something wrong the simple fact that one has to re-enter his/her credentials?
Depending on the client, you'll have some combination of the following checks:
- fingerprint remembered on first use (seen on iOS, Windows 8.1)
- common name checked against a configured value
- issuer checked against a whitelist, which usually contains only the organization's internal authority (using a public CA is secure only as long as the common name is checked)
From my experience, the mismatches are shown practically the same way as authentication errors; only wpa_supplicant can be made more verbose.
Since many clients have CA verification as the only option, the only possible secure mode is verifying the EAP certificate against a dedicated CA for the organization. (If your EAP certificate is from Thawte, and clients can be configured to require a Thawte-issued certificate but don't do any subject/CN checks, then literally anyone could buy a regular SSL certificate from Thawte and use it on a fake AP...)
Unfortunately, if the client has an option to accept everything, pretty much everyone will use it, since installing a new CA is painful. (Not to mention that it often also allows the organization to spoof HTTPS sites, which is not very desirable, and even causes a permanent warning icon on Android.)
The eduroam network has tried to make this simpler by providing a standard setup tool and iOS profiles, but only a small part actually uses it.
As a result, you might never notice that something is wrong.
