Hi.
While I don't mind clarifying the server ID discussion, I don't see that
server ID has any relation to how the peer validates the name in the
server certificate.
Quoting section 7.6:
7.6. Server Certificate Validation
As part of the TLS negotiation, the server presents a certificate to
the peer. 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. When performing server certificate validation
implementations MUST provide support rules in [RFC5280] for
validating certificates against a known trust anchor. In addition,
implementations MUST support matching the realm portion of the peer's
NAI against a SubjectAltName of type dNSName within the server
certificate. However, in certain deployments, this might not be
turned on. 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 domain and
whether the authenticator can be authorized by a server in that
domain.
According to that text checking against a DNS name SAN is the
mandatory-to-implement naming check for server certificates.
That seems adequate to me.